Last week, I described what the Mac's future might look like from the perspective of developers and consumers. I got a few things right -- like the perfect iPad compatibility and the use of containerization for security and app isolation -- but there were a few things I missed.
What did I get wrong? Well, for starters, I was not expecting the development path of this new generation of Macs to be as open or as flexible as the company appears to have pursued. Apple Silicon is a complete port, in the "Option 1: Re-engine" sense -- but there are some "Re-imagine" aspects as well.
The route Apple decided upon is to re-engine and partially revamp the entire Mac platform. It's a bold, aggressive move that will transform the entire technology industry.
For the future Mac -- the transition that is expected to take about two years -- Apple has decided to switch from Intel x86 chips to its own Apple Silicon, which has been powering its iPhone and iPad mobile products for the last 13 years. These will be 64-bit chips that use the Arm processor architecture of Apple's design.
For the developer transition, the company will be supplying a limited number of special Mac mini systems powered by the Apple A12Z Bionic chip. That's the very same chip used in the 2020 version of the iPad Pro, a 4X4 (asymmetric) system on a chip, boosted with 16GB of RAM from the standard 6GB of RAM that ships on the iPad Pro.
But it is unlikely that the initial shipping Apple Silicon Macs, expected in 2021, will use the same chips powering the next generation of iPhones and iPads. Apple will almost certainly design much more powerful processors, which can address much larger amounts of RAM, with higher numbers of high-performance p-cores (as well as lower-power e-cores), and possibly even discrete GPUs.
Apple decided, for this transition, to provide developers with as many options as possible for moving to the new Mac platform -- with what can only be called a "no app left behind" strategy. In order of development effort required -- from easiest to most difficult -- these options are:
Run traditional apps unmodified from x86 using "Rosetta 2," a 64-bit Intel emulator that presumably uses Just In Time compilation, similar to how Microsoft runs Intel apps on its Arm-based Surface Pro X laptop. How well legacy apps will run in this platform will be very difficult to say. Apple showed a few 3D games and large professional photo editing applications running smoothly, but we all know that demos are tightly controlled, and we don't know which apps may misbehave. There's a big difference between apps designed for multi-core and multi-threaded use on an Intel chip, and those running on an Arm processor, and then having to handle instruction translation on the fly. I was not expecting Apple to provide this as a method for running apps. In fact, I'm stunned. With the removal of the 32-bit app and Carbon support in Catalina, many legacy apps were already thrown out with the bathwater. I have to think that this is mostly to appease large developers like Microsoft and Adobe while they port their most significant projects over to the new platform. It should be added that these traditional apps running in emulation can be user-installed; they won't need to be distributed on the Mac App Store.
Run iPad and iPhone apps unmodified provided the developer allows the apps to be listed on the App Store for Mac -- the least effort solution with the best performance. This is one wild prediction from my previous piece I got correct, but quite frankly, it wasn't much of a prediction. It's precisely the same system architecture as the iPad. No emulation is necessary; Apple simply moved all the correct software parts over so the apps would run, at native speeds, and adding some software magic that creates the needed Mac UX on the fly to support menus, dialogs, and windowing. The big question: How well will touch-optimized apps written for iPad run on Mac systems that may not have touch support when these systems ship in 2021? As with Catalyst apps, and also with the Rosetta 2 environment, Apple is going to make use of containerization technology (so far, the company has not detailed how this is accomplished) to isolate the iPad apps from each other, using a new security model.
Port iPad and iPhone applications using Xcode and Catalyst, which is the iOS 14 APIs implemented in Mac OS 11. This is where I think most of the native apps will come from. The API set for Catalyst on Big Sur is much more complete than it was on Catalina, allowing for a much smoother transition between iPad APIs and the Mac. As they are iPadOS applications, they will exclusively appear on the App Store, and use the same containerization technology running the iPad emulation environment and, Rosetta 2.
To provide support for the most critical professional and business apps -- such as Apple's Final Cut Pro and Logic Pro X, and applications like Microsoft Office and Adobe Creative Cloud -- developers will also be able to port traditional apps from x86-64 running Cocoa APIs using Xcode, Objective-C, Swift, and supported libraries and frameworks. This includes a vast collection of open source software libraries that Apple has already ported for developer use. Again, I am astounded that Apple took this approach, as these applications can be sideloaded, rather than requiring deployment on the App Store. Whether this will always be the case and is going to be locked down in the shipping versions of systems running Apple Silicon has yet to be determined. It could be argued that if Apple had to do this for big players like Microsoft and Adobe, it would have been a potential legal quagmire if it didn't provide the same APIs to all software developers.
Still, we don't know how hard it will be to port some of the most complex apps, and what sort of optimizations are going to be needed to make the apps run well on the new Apple Silicon until the rubber hits the actual road. While the new containerization technology (and virtualization) is welcome, there may be architectural changes required for certain types of applications to take advantage of every aspect of the new OS and chip architecture. We also don't know how long it will take for Apple's Silicon to perform as well as the fastest Intel chips used on the beefiest Mac Pro Xeon workstations, with dozens of cores and terabytes of RAM, and high-speed bus architecture. There's a big difference between the capabilities of an iPad's system on a chip (SoC) and a professional creative content workstation with discrete GPUs and flash-based storage arrays.
In the long term, this architectural shift represents the future of personal computing. Both Cupertino and Redmond have now made significant investments in leaving x86 -- Apple with Apple Silicon, and Microsoft with Surface Pro X and Qualcomm. There's no turning back.
Also: The slow death of the Mac as we know it
We will see the fruit of these efforts early with Big Sur shipping on Intel, with many quickly ported iPad apps being put on the Mac App Store over the next year. There's no real sense of buyer's remorse with buying a current-generation Intel Mac because Big Sur is where everyone is going to be accommodated to the re-imagined version of the OS, as it contains so many user interface elements ported from iPadOS. By the time all of us land on Apple Silicon Macs, we will already have the "muscle memory" from using lots of ported Catalyst applications under our belts.
The real issue will be how quickly over the next few years Apple looks to seize total control of its ecosystem to integrate all the components better vertically as it does with iPhone and iPad, Watch, and Apple TV. It's doing this first with the hardware by moving to their chip architecture. Big Sur is not locked down, but future versions of Mac OS could very well have requirements for all new apps to be distributed on the App Store -- potential antitrust issues coming down the pike from the US Justice Department and the European Union notwithstanding.
Are you excited to run your apps on Apple Silicon? Talk Back and Let Me Know.