Watching for Arm-based Macs at WWDC 2020: Will Apple re-engine or re-imagine?
Exactly a year ago, I described the future of Arm-based Macs with "Forget Mac OS: The iPad is now Apple's Mobile Computing Future."
ZDNET Recommends
I still believe this to be true, as the iPad platform continues to get significant enhancements that make it more acceptable as a desktop OS replacement with every release.
Even though the Mac only represents between 9% and 11% of Apple's revenue, and its overall growth is still relatively flat when compared to the iPhone and iPad, it remains important for Apple because it is used as the development platform for iOS, iPadOS, Apple TV, and Apple Watch.
Also, a significant number of creative content professionals continue to rely on video and audio editing applications that are either exclusive to or run best on the Mac platform. It's estimated that creative professionals, while a minority, may make up as much as 80% of the Mac division's revenue -- the Pareto Principle at work.
Consequently, while iPadOS keeps improving as a personal computer replacement for many kinds of end-users, MacOS isn't going anywhere. And although iPadOS works well for tablets and mobile computing, it's not optimized for large-screen, desktop applications where multiple monitors may be needed.
Next week, at its World Wide Developer Conference (WWDC), Apple is expected to announce the migration of the Mac to the Arm processor architecture.
This migration has been expected for as much as a decade, as many (including myself) have posited that, for Apple to have full control over its hardware and software ecosystem, it needs to be able to create its CPU DNA for the Mac, as it has done for the iPhone and iPad. In 2012, I called them "Brave New Macs."
But what does a "Brave New Mac" actually look like in the year 2021 -- when these devices are expected to debut -- from the perspective of a software developer or an end-user? This depends on what kind of migration approach Apple takes to the MacOS port itself.
Approach 1: Re-engine
Apple has "re-engined" the Mac twice in its history -- in the mid-1990s, when it moved from the Motorola 68000-series to the IBM/Motorola PowerPC, and then in 2006 when, as a result of the highly secretive "Marklar" project, it moved to Intel.
The 68000 migration to PowerPC involved a direct port of System 7.1.2. The first systems shipped in 1994, just before Steve Jobs' triumphant return to the company. This system, which came with a 68000 emulator, persisted until 2000 when the early betas of "Rhapsody" -- the OS officially released as Mac OS X and the forerunner of today's MacOS -- were released exclusively on the PowerPC platform.
Rhapsody was a "re-imagine" of the Mac, using assets purchased from the NeXT acquisition and its OpenStep operating system. It could run original Mac apps, but it was truly a different animal in all respects compared to the original Mac.
However, to support legacy applications from the previous generations, Apple had to not only create an emulation layer and runtime environment that mimicked the operation of System 8 and 9 on a PowerPC -- but it also had to develop native implementations of the older APIs. Software developers could then port their applications written for the older operating system to OS X without undergoing complete rewrites to the OS's native APIs, also known as "Cocoa," which is the native API that is still in use.
This system to support legacy applications, known as Carbon, existed from 2001 in the initial Mac OS X 10.0 Cheetah release -- until 2019, with the introduction of MacOS Catalina, when all of Carbon and all support for 32-bit code was deprecated. The API support for Carbon was not perfect initially, and numerous compatibility and performance issues took several years to work themselves out. And initial versions of Mac OS X were sluggish compared to Classic Mac.
Classic Mac to Rhapsody was a difficult transition for both end-users and developers, to put it mildly.
The second migration in 2006 involved the port from PowerPC to Intel. This was undertaken because X86 chips were much more powerful than comparable PowerPCs at the time, and there were production scale and supply chain reasons to move to the architecture as well.
Compared to the Mac OS 9 ("Classic Mac") to Mac OS X transition, this one was relatively simple -- Apple underwent a complete port of Mac OS X to Intel and included a PowerPC emulator -- named "Rosetta" and built by Silicon Valley startup Transitive -- that was able to run all Mac OS X applications for PowerPC on an Intel system. That emulation was removed in August 2009 with the release of Snow Leopard.
So, could Apple approach a port of the current MacOS to Arm the same way it moved to PowerPC or Intel? Brendan Shanks, an iOS and Mac developer, believes this is a likely scenario and has outlined much of what would be required to undertake it.
Approach 2: Re-Imagine
For its migration to Arm, Apple certainly could "re-engine" it the way it did for Intel, with a complete port, but it's unlikely. It's much more likely to resemble the Classic Mac to Rhapsody migration, including all the developer and end-user agony that went along with it.
Much has changed in the 20 years since Rhapsody made its first appearance. Apple now controls its developer ecosystem through the use of its app store, where it gets a 30% cut on all software purchases. It doesn't make any money from third-party software that is "sideloaded" on the Mac. Its applications, such as Final Cut Pro, Mainstage, Motion, Logic Pro X, and Compressor, are also exclusively sold and installed through the app store, as is its developer software and XCode.
The Apple of 2020 will not want the Arm-based Mac to continue the tradition of developer sideloaded apps when the company is now used to getting its way on iOS and iPadOS, which are wholly locked down appliance computers. Apple also has already made strong indications that it wants a fresh start. As mentioned earlier, in 2019, Apple removed support for all 32-bit code in Catalina, in addition to its support for the Carbon APIs. So, for the most part, the company has already removed all of the legacy subsystems that developers might still need to port those straggler apps relying on older code. Elimination of 32-bit APIs and libraries and all the Carbon APIs also pretty much removes most of the need for an Intel 64-bit emulator on Arm.
Another reason to keep apps locked to the app store is just based on the fact that tens of thousands of iPad apps are already there and written to the Arm architecture. This gets us to the crux of the entire migration issue; What does this platform look like for developers and end-users?
For the transition, developers will likely continue to use existing x86 systems to build and cross-compile Arm Mac apps, as they do for iOS and iPad OS now. There's very little reason at this time for Apple to make the platform self-hosting, and it's unlikely that the very first Arm Macs are going to be suitable for building code for the most resource-intensive apps anyway. You would need an x86 Mac to do this, at least for now -- although Apple could invest in cloud-based development systems, using hosted, virtualized Macs. However, the company has not made the sort of investments in the cloud that companies like Microsoft, Amazon, and Google have, and I don't think Apple wants to be in that business. It would also have to do this with a partner -- which I have long advocated.
And let's face it -- the first generation of these systems are not going to be powerful enough to replace the professional Mac workstations for chewing up 4K video and performing other CPU and GPU-intensive tasks, even if Apple does complete ports of its professional apps. These machines will be suitable for light editing if that. And Adobe might very well port Creative Cloud as an exercise, but Arm will not be its customers' leading platform of choice, either.
So, who is the Arm Mac for, exactly, if you can't run professional workloads on it?
As I mentioned earlier, while it still is a highly profitable business for Apple, the growth of the Mac platform is effectively flat. Arm would represent an expansion play, a way to increase market share to consumers and business users.
Addressing the dreaded 'app gap'
The easiest way to get consumers and businesses onboard is iPad apps. And Apple introduced a way to port iPad apps to the Mac via Catalyst.
Arguably, Catalyst has not been widely adopted by Mac and iPadOS developers because there hasn't been a compelling reason to use it. But it's likely that to streamline the development processes for this device, Apple could require developers to use Catalyst as the main programmatic API for the Arm architecture and Swift as the predominant programming language. This is what Steven Sinofsky, formerly the head of the Windows division at Microsoft, believes to be the case. I agree with most of his assessments.
This is not to say the most important apps have to be implemented in Catalyst by Apple without using Cocoa. To port its desktop apps like Final Cut Pro, Keynote, Pages, Numbers, Garageband, Logic Pro X, etc., Apple might reserve the entire Cocoa API set for its internal use, even though third-party developers might not be allowed to use the complete API set on Arm. Due to architectural and hardware limitations alone, there inevitably will be other restrictions imposed as to what developers can and cannot use on the new platform.
Frankly, for a lot of MacOS system components and UX elements to work at all on Arm, Apple absolutely will have to use the Cocoa APIs until those components can be rewritten using Catalyst. That is if Apple is inclined to eventually streamline the entire OS with their dog food, much in the way Microsoft has done over time by rewriting user interface elements from older versions of Windows (control panels, etc.) in Modern APIs for Windows 10. Microsoft's efforts to rip and replace those legacy elements have taken years to accomplish fully. Still, many vestigial things exist in Windows that have nothing to do with basic app compatibility. I expect that Apple will face similar challenges.
But to get adoption off the ground, at the same time, while all this porting effort using Catalyst takes place -- and to minimize the dreaded "app gap" -- I believe it is likely these systems will ship with a perfect iPad emulator. This would allow iPad apps to run unmodified and windowed (as opposed to full screen) on an Arm Mac, direct from the existing iPadOS App Store.
Apple will likely release toolsets to reduce the level of effort to close the app gap, but let's face it, many developers are lazy. They don't want to maintain code for multiple platforms, even with the best of rapid coding and streamlining tools available. If they've already got an iPad app in the wild, why go through the trouble of making it a full-blown Catalyst port? Sure, someone like Microsoft might port Outlook and the rest of Office to Catalyst, but a one-person developer shop? Maybe not, at least not right away.
Featured
What it means for end-users
How Mac-like the Arm Mac will be in practice for a business or consumer end-user is challenging to say. Will it look like a Mac? In terms of the primary user experience, it will resemble it, at least the launcher and the file manager, superficially. However, I don't know if the end-user will have the same low-level access to the platform in the same way X86 users enjoy now.
If all the apps come from the app store, the Applications folder might not be accessible. If a Terminal app is available, it might not be able to interact with the local kernel-level processes and configuration files in the root level system folders. It's possible only the user level directories might be accessible.
Other aspects of MacOS might also have to be re-implemented or rewritten, such as the Control Panel, and there might be utilities and other things that may not exist or make sense to port in initial versions of the Arm implementation of the OS. In addition to various API restrictions that Apple might impose on developers, we might also find that things like third-party browser engines, such as Chrome and Microsoft Edge, might also be prohibited from running on Arm, for security reasons, as they are on iPadOS. We might be stuck with Safari or running the iPadOS implementations of Chrome and Edge, which are just wrappers for Safari's web rendering engine.
Arm is the platform where Apple will almost certainly experiment with certain technologies that might not make their way immediately to x86 Mac, such as containerization of Catalyst applications, to make it more secure.
On the surface, it sounds like an awful lot of restrictions for a typical Mac user -- but I don't see the initial crop of Arm Mac users as regular Mac users. These aren't heavy creative content professionals. If Apple intends these to be used primarily by consumers and business executives, it likely wants a largely tamper-proof experience. These users are fine with running an office suite, a browser, and cloud-deployed applications running as SaaS. And all the iPad apps. More freedom than a Chromebook or an iPad, but less than a full-blown Mac.
This has significant implications for large Mac developers like Microsoft. Currently, Microsoft ships Office 365 for Windows and Mac, but it might not make sense going forward for it to do that. Microsoft could just invest its efforts improving its Web UX (like Google does for G Suite) or providing remotely-hosted Office desktops, as it does with Windows Virtual Desktop running on Azure today.
It also would not be difficult for Microsoft to seamlessly display Office on a Mac, running on Azure in a VM as a containerized process, as application windows using a launcher written in Catalyst. It already owns all the technology to do it. And as a way to control its software licensing, all Microsoft needs to do is put a launcher in the form of a tightly integrated Remote Desktop Client on the app store -- which will require the use of an existing Office 365 login to run.
This software distribution methodology could be extended to all sorts of application developers, who would want to end-run the app store's 30% cut -- such as Adobe. It could all run its apps as web-based SaaS, as PWAs, or remotely executed. The appearance of an ARM Mac platform could even force Microsoft (and other enterprise software developers) to re-think its entire software development strategy and accelerate movement toward hybridized cloud applications that mix PWA with Win32 APIs.
In this scenario, the balance of the application code lives and executes on Azure (and other commercial clouds like AWS and Google Cloud), not the local machine. And while this has negative implications for offline use (even with various caching technologies), we could be entering an age where it is becoming not only impractical to run the software in a disconnected manner but may very well be impossible.
These are all thought experiments, and there are different permutations and many more details of how these systems will be implemented. But regardless of exactly where we land in these predictions next week, the world will soon know the future of Brave New Macs.
Are you excited for Mac on Arm? Or loathing the transition? Talk Back and Let Me Know.