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 makes 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 module new APIs.
6/ That eventually meant Carbon just went away which is where we are today. But still the Mac running Cocoa 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 require emulation to run. Emulation was used in the PPC transition and was awful—apps you want most are the worst. Emulation never works.
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 app to iOS 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.
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.
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 KLOCs 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 Cocoa in the first place.
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.
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.”
This thread is annotated and unrolled on medium.
Apple Macintosh and ARM Processors medium.learningbyshipping.com/apple-macintos…
Apple Macintosh and ARM Processors medium.learningbyshipping.com/apple-macintos…
