Apple Macintosh and ARM Processors
For a while we’ve been hearing rumors of Mac moving to ARM, or something like that. What could this mean? What are the issues such a move faces? An annotated twitter thread.
Postmortem: Many of the comments on this thread affirmed that there’s a preconceived notion or expectation of what a device combining ARM and macOS might be. The discussion here is not a prediction but a discussion of the issues we faced in moving Windows to ARM and how to deal with an existing ecosystem of devices, apps, and “expectations.”
History does not repeat itself and Apple historically has very much taken a “Think Different” approach and that is likely what will happen again. Certainly no matter what happens someone would have predicted it, but what is certain is that any choice is one involving trade-offs, frustrations, or even disappointment.
The biggest “if” at all is whether such a device is or would be called Macintosh and the implications of that path. Of course when we named Windows RT there was no debate about using “Windows” in the name as everything had Windows in it for us (Windows NT, Windows Embedded, Windows Media Center, Windows Tablet PC, Windows Server, Windows CE, Windows Phone) and they rarely shared more than the name Windows. But is Macintosh a brand, a set of specific capabilities, a form factor, or what? I’m excited to see as Apple holds all the cards and can choose as they wish.
1/ Newsflash: Apple going to bring ARM to chips to Mac. // What could this mean? Seems this must mean the best of all worlds. Is that how tech transitions happen? Thoughts, scars… tl;dr not so simple or obvious. Reminder: Think Different. bloomberg.com/news/articles/…
2/ First, I have no knowledge of any specific plans of course. I only know what I’ve read and much seems confusing and/or simplistic. While the transition from PPC to i86 seemed to go smoothly there’s much more that went on. History won’t repeat itself. This is a tech discussion.
Note/ For a long version of this logic, see the vintage, lengthy, post I wrote years ago when moving Windows to ARM. Some will say we made a huge mistake in disallowing Win32, but if you read the post you can see why that made little sense then and now. docs.microsoft.com/en-us/archive/…
3/ Ages ago, in moving to x86, the big “ask” for developers was not to change instruction sets but to also move their applications from Carbon to Cocoa. It took a very long time for the big important apps (eg photoshop) to do this.
4/ In the meantime, everything new on the Mac was in Cocoa and so there was a bit of a “forcing function” to make things work. But that only mattered if new things were important enough. Big apps tend to be universes on their own and so what seems like leverage really isnt.
5/ The other big thing was that the kind of app built with Carbon and Cocoa were mostly the same, which is why the transition both was and could be slow. Basically these APIs were keyboard+mouse and had access to an entire Operating System. So side by side worked modulo new APIs.
6/ That eventually meant Carbon just went away which is where we are today. But still the Mac running Cocoa/AppKit apps while better, is fundamentally a 90’s era notion of a PC when it comes to security, reliability, how devices are supported, and so on. FWIW, Carbon is ~ the Win32 API.
7/ Along comes the amazing innovations from Apple in building mobile ARM processors. Of course this is Apple and the innovations are not *only* the hardware but the OS and importantly the APIs and overall app model are entirely different.
8/ This is true even though the “OS” shares a ton of code with Mac. That’s what makes this confusing. The code can be shared because the underpinnings of an OS — networking, files, processes, etc — are “settled” art these days. The big difference/differentiator is how apps are built.
9/ Everyone knows that iOS/iPadOS apps are “different”. Everyone experiences the positive attributes of security, power management, safety, privacy, apps that can’t break each other, {no DLL hell}, etc. These come from the app model and APIs, not magical properties of ARM.
10/ While ARM chips are inherently designed w/different set of trade offs for power, devices, die size, etc, those surface (a pun) when OS chooses to architect itself around tradeoffs. Example, no random device drivers or kernel mode access. Or limited windowing/bkg processing.
11/ This all in addition to having different instructions. An aside, different instructions preclude virtualization like we know it and would require emulation to run i86. Emulation was used in the PPC transition and was awful — apps you want most are the worst. Emulation never works.
The PowerPC 601 was about 4X the speed of the Motorola 68040. That gave it plenty of room to emulate (eg run 4 instructions for every 68k instruction). Plus most of the Mac OS was in native PowerPC code when it came to emulation so that made for even more room. It still did not work for the apps that people cared about.
We see this today with emulation of x86 on Qualcomm chips. It works super well in terms of functionality, but the performance for apps that you need/want like Chrome, Photoshop, or Acrobat Reader make it a non-usable solution.
Note/ Sandboxing and API level virtualization don’t bring the attributes of a mobile-ARM OS to a desktop OS either, no matter how much techies assert. These can kind of work for one app, but the desktop is about many apps — working together in a sandbox. That’s not a safe sandbox.
12/ So the question is really what app model/APIs will run on an ARM mac. Many believe Apple will simply release a new compiler that will take existing i86 apps and compile them to ARM. Boom. Magic. Apple has a new Mac with their own chips.
13/ This is “trivial” but the key is it assumes the APIs invoked on MacOS/i86 are available on Mac ARM. In other words, this assumes Cocoa is on ARM Macs. The question is why would Apple do this? To what advantage does this bring? What’s the customer value proposition?
Note/ Intel for Mac was a huge proposition. It brought a much needed power boost to the Mac as PPC had fallen behind. Plus the ecosystems of storage, networking, etc.
14/ Many believe this is “classic Apple” looking to vertically integrate the supply chain and stop using Intel as a chip supplier. I think this is simplistic (and certainly not what I thought about Windows on ARM). This assigns the entire value in the move to chipset freedom.
15/ If that’s the problem to be solved, then an easy answer is to just move to AMD and use their chips. Or at least offer both and see how the “market” votes. This would be a complex offering and would just add complexity to engineering with only small %age of difference.
16/ IMO the real problem is that the Cocoa APIs themselves have reached end of life. Any vendor with Cocoa apps is already focused on some combination of iOS and the cloud and is essentially “milking” their existing Mac apps as part of a larger service. Same as Win32 8 years ago.
17/ The cost to a big ISV to move an existing Cocoa/AppKit app to iOS/UiKit is well known. Now Cocoa and iOS are close but then there’s all those pesky things like the interaction model, background processing, overall design of the app, and of course the keyboard and mouse.
From another twitter thread by @_inside, this excellent slide from the WWDC keynote articulating the transition Apple made from PowerPC to Intel.
18/ But wait, if you’re like me (and many others) using the new iPadOS and new iPad then you’re experiencing an iPad with a keyboard and a mouse just like a desktop computer. So there is a future OS staring at me every day. Except it still doesn’t run Photoshop (or Office).
19/ Some are quick to say that until an OS runs the development tools then it is not a real OS. Or I can have 10 open windows, then it is not a real OS. Hogwash. There’s no bootstrapping required. It’s nice. It does not prove anything. i86 can be the dev platform for years.
20/ The only reason this comes up so often is that most people commenting or thinking about this topic are in the software industry. Most people using a Mac given a new device want to know about Office, Photoshop, Premier, or some hardware device controlled with MacOS software.
21/ The problem is those apps are big. Will take years to move to iOS/iPadOS and the investment required is one that ISVs will benefit little from in an economic sense unless the addressable market increases.
22/ Along came Catalyst (and also SwiftUI). Catalyst is the “macOS” API bridge between iOS and macOS. Apple is converting 1st party Mac apps to Catalyst, which makes it much easier to support alternate UX models touch + plays well with underlying OS, while being “native”.
23/ So my question is why would a new Mac on ARM do anything more than support Catalyst apps? In other words, big apps will have to follow Apple’s lead and just “suck it up” and do the work to express themselves in Catalyst.
By Catalyst I mean Catalyst and iPadOS apps. If the new Mac doesn’t support iOS apps then it is a bridge product where there will be little life in the ecosystem (in a relative sense) as the active development on Mac is very small.
24/ This was basically what we tried to do with Windows — the only difference was we lacked an already enormous base of developers, apps, and devices that apple has. In other words, moving to Catalyst *also* makes the app “native” to phones/pads/etc.
25/ ISVs can choose to ignore this move. Or Apple might try some long drawn out move as they did in the Carbon to Cocoa path. In the short term there is a cross compiler and in the medium term the APIs just go away. There are two challenges.
26/ First, there are really a small number of ISVs that matter and there has been dialog for years already about moving to iOS. Did Catalyst provide enough capability and ease of “porting” that an ISV with millions of LOCs would make the move? Tricky.
27/ Second, a lot depends on the user interaction model. Right now Catalyst has a lot of controls and capability but it is not the full control of a windowing system that these legacy apps were designed for. That’s why these apps did not move to iOS in the first place. It certainly is a lot of work to move a legacy app to Catalyst.
28/ There’s a “non-goal” (as MBAs like to say) which is some notion of abstracting out the API from the hardware to “write once/run everywhere”. Not only is that not a goal, that is the opposite of successful. Yes it worked for HTML and Games, but those have been the exceptions.
29/ And that leaves the biggest variable not being discussed, which is what is the user interaction model of a hyopthetical ARM Mac.
30/ Many assume or believe or say the evidence in header files and code imply it would obviously be the Mac that we know and love already, just faster more secure and cheaper because of ARM. Again, those attributes don’t come for free. Neither does touch v keyboard and mouse.
31/ So more than anything what I am curious to see is ifMac on ARM also represents an interaction model that is closer to iPad w/keyb/mouse. If not, then I believe the Mac, new w/ARM, is still a transition device/OS combination there to support legacy just a bit better.
It wasn’t that long ago that people were questioning the absence of touch from the Mac. Not just Surface/Windows fans but Apple fans as well. A modern device without touch doesn’t feel all that modern, even if touch is just used by accident occasionally. I’ve written lots about the challenges of mixing legacy desktop apps and touch and how that doesn’t really work.
32/ I still want a clamshell iPad. I still want the confusing windowing model to be fixed, but I don’t want to go back to a world of constantly futzing with windows, sizes, and writing apps that have to work at completely arbitrary sizes (versus dozens of fixed sizes :-)) // END
PS/ The least important measure in moving from Intel to ARM is the performance of the processor. Executing instructions per second is the commodity. What matters is the software and device ecosystem on top, no matter how few/many threads/processes are used.
Typo/ 27 should read “That’s why these apps did not move to *iOS* in the first place.”
