Are you kidding me? You believe that these developers should make native M1 Mac ports their #1 priority when these Macs are like 0.5% of the market at best?
Priority list: iOS apps (2 billion devices) Windows apps (1 billion devices) Intel macOS apps (hundreds of millions of devices) Android apps (3 billion devices) ChromeOS platform support (according to the latest Statcounter have 2% market share, Google claims that they are almost 5%) M1 macOS apps (maybe 5 million devices)
M1 Macs were only available less than half that time, plus people and especially enterprises didn't stop buying Intel Macs either. Add in 1Q 2021 and that is 5-6 million people that have bought M1 MacBook Air, Mac Mini and 13' MBPs. And as these machines are limited to 16 GB of RAM, 2 displays and - the point of this article - has software compatibility/availability issues the early adopters are either people using the M1 Mac as a secondary machine (to their Intel Mac or their iPad Pro) or were entry level device types who relied mostly on first party software and web/browser stuff anyway.
Honestly, what do you believe the job of a software company should be anyway? To make a platform offered by a $2 trillion company look good by shrinking their "not available on M1" list? Or to make money to pay their employees, pay the bills and stay in business by creating software that people will buy? If you realize that the LATTER is the case then it is in the interests of these companies to prioritize development projects that will actually make enough money to justify the coding effort. Right now the tiny subset of the 5 million M1 Mac users won't do it.
Next year? Sure. Apple will have transitioned all of their lineup except maybe the 26 core Xeon Mac Pro to M1 by then, and the M1 Mac user base will be 20-25 million. Also, despite your "they had the developer kit and 5 months to buy an M1 Mac!" ... er, no. Large outfits with tens of thousands of programmers like Dropbox, Google, Amazon, Adobe etc. didn't get the developer kit, OK? Those went out to small developers. The bigger software companies are probably still in the process of acquiring M1 Macs to armies of developers that need to port huge software packages with millions of lines of code over. Who knows if they've added these devices to their enterprise acquisitions yet. (I bet most companies haven't.)
Yes, Apple got this done ... but Apple makes several hundred bucks on each M1 Mac sold. They've probably cleared $1 billion in revenue from the M1 Mac line already assuming a margin of $200 per device. But this does not mean that there is much revenue in this yet for the companies that make the software.
As usual a factually correct but contextually irrelevant comment. What have sweeping industry stats got to to with App-specific target markets? The article is about why some developers who’ve already committed to producing a Mac App haven’t seen fit to update it when others have. There are many reasons why but market share rhetoric isn’t one of them. Also, given most code is processor architecture agnostic your “millions of lines” comment is also irrelevant.
The DTK Macs were complete utter unusable garbage, and Apple’s developer support sucked as usual. So it’s no surprise that developers are bypassing porting apps to M1.
Moreover, it makes little sense to spend time developing a Mac-only app when a web app can be used on any device. QuickBooks is a perfect example of this. Their web app works just as well as the Mac app, so why spend time and money porting to M1.
This makes sense - for developers who put their interests ahead of their customers’. If a developer fails to leverage OS native advantages they should exit the platform and let those with most commitment take their market share. Anyone using Web Apps for business should periodically look at native alternatives so as not to incur the Web App productivity hit and lose market to their competition.
The issue isn’t purely technical. What Apple are asking for is that cross-platform product managers/owners rethink their product architecture, specifically the forking/segmentation and this is no minor decision. The product pie can be sliced many ways; mobile vs desktop, ARM vs x86, Windows vs macOS. Apple are asking for a separate AppleOS fork which will take time to sink in, let alone implement.
ADOBE WAS NEVER GOING TO BE THERE, THE SAME APPLIES TO QUARK, MICROSOFT, GOOGLE AND FACEBOOK, ALL THESE COMPANIES WILL ANNOUNCE UNFINISHED BETA PLACEHOLDERS.
The small to medium sized companies, aside from Apple, are the companies that were going to carry the torch as they did during the last transition.
The issue isn’t purely technical. What Apple are asking for is that cross-platform product managers/owners rethink their product architecture, specifically the forking/segmentation and this is no minor decision. The product pie can be sliced many ways; mobile vs desktop, ARM vs x86, Windows vs macOS. Apple are asking for a separate AppleOS fork which will take time to sink in, let alone implement.
Yes it is purely technical. There is no 'product architecture' to rethink and no 'fork'. For a well written Cocoa Mac app it's a case of ticking a box in Xcode and recompiling and that's it. Any product manager trying to treat x86 Mac and ARM Mac as separate things deserves for their product to fail.
For almost every thing which does not have a Native M1 port on the list in this article I can point to a technical reason why. For example:
MS Teams - It's based on an ancient out of support version of ElectronJS which doesn't have ARM macOS support. Practically the only thing they need to do is move from Electron 8 to Electron 11. Skype - Same Electron issues as Teams. Acrobat - This has an entire JavaScript JIT of adobe's own invention in side it so that needs porting which isn't trivial before the rest of it can be ported. Spotify - Based on the 'Chrome Embedded Framework'. This only gained initial support for ARM macOS in late December 2020 and it's half baked so far as it can't produce universal binaries. Various bits of creative cloud - Also using Chrome Embedded Framework thus needs proper support there before it can progress.
This is why: Transitioning most software to Apple Silicon is trivial. You just recompile it and fix a few warnings. However, if your software uses the GPU to do work, you are going to face some issues. Apple has eschewed GPU compute standards. CUDA, OpenCL and Vulkan have been deprecated and are not supported on Apple Silicon. This is a big deal since GPU compute is vastly faster than CPU compute. If your software does transcoding of video or voice recognition or 3D rendering or, heaven forbid, is a game then you have a really big hill to climb in order to support Metal on the Mac and some standard GPU compute on Windows. It is up to Apple to fix this problem.
The issue isn’t purely technical. What Apple are asking for is that cross-platform product managers/owners rethink their product architecture, specifically the forking/segmentation and this is no minor decision. The product pie can be sliced many ways; mobile vs desktop, ARM vs x86, Windows vs macOS. Apple are asking for a separate AppleOS fork which will take time to sink in, let alone implement.
Yes it is purely technical. There is no 'product architecture' to rethink and no 'fork'. For a well written Cocoa Mac app it's a case of ticking a box in Xcode and recompiling and that's it. Any product manager trying to treat x86 Mac and ARM Mac as separate things deserves for their product to fail.
For almost every thing which does not have a Native M1 port on the list in this article I can point to a technical reason why. For example:
MS Teams - It's based on an ancient out of support version of ElectronJS which doesn't have ARM macOS support. Practically the only thing they need to do is move from Electron 8 to Electron 11. Skype - Same Electron issues as Teams. Acrobat - This has an entire JavaScript JIT of adobe's own invention in side it so that needs porting which isn't trivial before the rest of it can be ported. Spotify - Based on the 'Chrome Embedded Framework'. This only gained initial support for ARM macOS in late December 2020 and it's half baked so far as it can't produce universal binaries. Various bits of creative cloud - Also using Chrome Embedded Framework thus needs proper support there before it can progress.
The list goes on but I'm bored now.
I said cross-platform products, they won’t be fully invested in Xcode, they will use 3rd-party libraries either not ported to or not optimised for ARM & many will abstain from 1st-party frameworks to keep portability. This is why so many plugins are causing an issue.
Comments
Anyone using Web Apps for business should periodically look at native alternatives so as not to incur the Web App productivity hit and lose market to their competition.
The product pie can be sliced many ways; mobile vs desktop, ARM vs x86, Windows vs macOS. Apple are asking for a separate AppleOS fork which will take time to sink in, let alone implement.
The small to medium sized companies, aside from Apple, are the companies that were going to carry the torch as they did during the last transition.
For almost every thing which does not have a Native M1 port on the list in this article I can point to a technical reason why. For example:
MS Teams - It's based on an ancient out of support version of ElectronJS which doesn't have ARM macOS support. Practically the only thing they need to do is move from Electron 8 to Electron 11.
Skype - Same Electron issues as Teams.
Acrobat - This has an entire JavaScript JIT of adobe's own invention in side it so that needs porting which isn't trivial before the rest of it can be ported.
Spotify - Based on the 'Chrome Embedded Framework'. This only gained initial support for ARM macOS in late December 2020 and it's half baked so far as it can't produce universal binaries.
Various bits of creative cloud - Also using Chrome Embedded Framework thus needs proper support there before it can progress.
The list goes on but I'm bored now.