I speculated about Apple developing Macs based on ARM processors over a year ago, and showed some controversial performance comparisons here. I’m therefore completely unsurprised at the strong rumours that Apple is preparing to announce them in ten days time at the start of WWDC 2020. This article looks at some of the issues which we might face if this turns out to be true – and I stress that, no matter how strong or ‘reliable’, until Apple announces anything these are no more than rumours.

Some have taken the opportunity to make all sorts of wild claims, such as ARM Macs being little more than iPad Pros, only running software supplied from the App Store, and worse. Before going any further remind yourself that Apple is commercially very successful, and what it wants of any new product is for it to sell, without wiping out other major products.

Selling a Mac directly aimed at the iPad Pro market, or one which couldn’t run most Mac software, would be a very big mistake, and I’m sure that Apple realises that. If it does launch a new range of ARM-powered Macs, it will want them to be first and foremost a success, and very popular with both new and existing users. Otherwise, what’s the point?

Macs have changed processor architectures twice now: from Motorola 68K to PowerPC in 1994, and from PowerPC to Intel x86 in 2005-06. Although few current Apple staff are likely to have been working for the company during either of those, there’s still corporate knowledge of how to make such changes. WWDC is an ideal time and place for this to occur, as it allows Apple to seed its developers with early systems so they can get testing, and porting their products to the new architecture. Then, probably in early 2021, Apple can release its first new models to the public. Trying to do this any more quickly puts their success in jeopardy, particularly during this pandemic.

Using ARM processors isn’t as radical a move as many claim, and they’re not only suitable for low-power system as is often thought. They originated as processors for desktop computers, with a lean instruction set (RISC) which enabled them to run relatively fast and deliver high performance at modest cost. But the processor is only part of the package: just as critical are the supporting chips in the chipset, including graphics and GPU, and those handling interfaces such as Thunderbolt. For performance, efficiency and economy Apple will most probably be building these into a System on a Chip (SoC), and graphics SoC, just as in iPhones and iPads. Freeing its designs from Intel chipsets is probably even more important to Apple’s future than just changing CPU.

ARM processors not only consume less power, but as a result they also generate less heat, properties which make them ideal for use in laptops. The first Intel-powered Mac was an iMac, which made it simpler to design and engineer, but my suspicion is that any first ARM-based Mac will be a laptop model. My favourite candidate is the MacBook, which was discontinued a year ago.

Before going any further, Apple and its engineers need a development environment which supports production of both Intel and ARM executable code. Here they have a head start, as thanks to its iOS and iPadOS support, Xcode already fits the bill. macOS has just been prepared to make porting it to ARM processors more easily, with the removal of support for 32-bit software in Catalina. Expect OpenGL and OpenCL to vanish shortly too.

Another important step is the expected loss of support for third-party kernel extensions in macOS 10.16. This has major impact on those using existing Intel Macs: kernel extensions are still the most popular way of implementing some low-level features, including support for many third-party peripherals. Apple hasn’t yet provided mature replacement options either, and developers have been protesting that their apps still have to rely on kernel extensions. But removing support for them in the first release of macOS 10.16 for ARM is clearly important to Apple.

For ARM Macs to succeed, they need to run as much of today’s software as possible. There’s little point in Apple launching new Macs which can only run ten or twenty percent of modern apps. Developers need to build versions of their apps which run natively on both Intel and ARM models, so-called ‘fat’ apps or ‘universal binaries’, just as has been done in the past. For apps developed in Xcode which use supported calls in macOS, that should just be a matter of the developer opting to build a fat release of the app (in a new version of Xcode).

This is because – apart from in some of the deeper parts of firmware, drivers and macOS itself – very few developers now use processor-specific assembler code, but write in high-level compiled languages like Objective-C and Swift. Xcode can cross-compile those to efficient ARM processor code, as it already does when building apps for iOS and iPadOS.

Not all developers write their software in languages which are compiled by Xcode and its command line tools, though. Some languages, such as Python, have already been ported to run well on ARM. However, there are still many apps which use bespoke development systems, and third-party compilers which don’t support ARM yet.

One way you can tell which products might run into this problem is to check them using my free app Taccy. This reveals which SDK that app has been built with: if it’s Apple’s internal one, or that for Catalina or Mojave, then the developer shouldn’t have too many problems porting it to use the 10.16 SDK and create a fat build. If none of the SDK checkboxes are ticked, then the app may be built using an older SDK or bespoke development system, and could be more of a problem to get running native on ARM systems.

Another potential solution for ARM-based Macs to run a lot of older software is for them to have system support for some form of virtualisation of Intel Mac systems. Apple did this before with Rosetta, which actually translated PowerPC instructions to Intel x86 ones on the fly to enable existing software to run on its new Intel Macs.

There are inevitably performance hits with that approach, and it requires considerable engineering investment on Apple’s part. However, ARM processors provide support for virtualisation, currently available in two Open Source hypervisors, KVM and Xen. In theory, Apple could provide a complete virtualisation layer which let users run most Intel Mac apps, and could even install and run Windows. Whether it will is another matter.

You’ll notice that I haven’t yet mentioned Catalyst, Apple’s SDK for development on iPadOS and macOS. That’s because Catalyst isn’t particularly relevant here: it hasn’t proved popular with either Mac or iPad developers, and clearly has a way to go before it stands any chance at competing with Apple’s long-proven AppKit and its relatives. Because Catalyst apps will still have to be ‘fat’ in order to run on Macs, putting ARM processors in Macs poses the same problems to them as it does to any Mac app. ARM-powered Macs are unlikely, for the foreseeable future, to run iPadOS, and frankly I don’t think anyone would want them to.

If Apple does announce ARM-powered Macs at WWDC – and that’s still a very big if – it’s another milestone on a road which started in 1990 when Apple co-founded what was then Advanced RISC Machines Ltd, now ARM, thanks largely to the vision of the late Larry Tesler and the need for a processor for Apple’s Newton. This isn’t some hare-brained scheme that cropped up in the last year or two. Apple’s hardware engineers have been working on this project for much longer.

I expect its first products will be the more obvious and straightforward, like the MacBook, MacBook Air, and possibly other lower-end models. Delivering the sort of performance you’d expect in a high-end desktop system, or MacBook Pro, may take another year or two yet, and matching the higher end of the iMac Pro and Mac Pro ranges is an even tougher challenge, and given their smaller sales volumes and more specialist markets, Apple may not be in any hurry to try switching them to ARM processors.

But ARM-based Macs have a lot to offer. Apple is but one of Intel’s volume customers, and doesn’t dictate its product development. As it has shown with iPhones and iPads, Apple can drive its hardware development where it chooses, and has closer control of its costs. Intel chipsets are one of the largest costs of every Mac currently on sale. Although Apple isn’t doing this for charity, if it works out as Apple hopes, it could enable Apple to reduce the price of low-end models and significantly extend capabilities at the upper end.

My pre-release developer Intel iMac was one of the most exciting Macs that I’ve used. I hope that this summer I’ll be testing out something even better.

Thanks to Ivan for pointing out my error, which I have now corrected, over when the MacBook was discontinued.