Thoughts on Apple Silicon Mac SoCs' 64-bit-only nature

[Yebubbleman]

Something that I've only recently been made aware of: Apple Silicon SoCs dating back to the A11 iPhones (iPhone 8, iPhone 8 Plus, and the original iPhone X) lack 32-bit instruction sets. The A11 devices (said iPhones) were the first devices to ship with iOS 11. iOS 11 was the first release of iOS to drop support for 32-bit apps.

Putting this into context, it seems like this wasn't a coincidence. Apple knew they wanted to remove 32-bit instruction sets from their SoCs (making them leaner and meaner) and that was very likely why they dropped support for 32-bit apps, even for iOS devices that sport an A10 Fusion, A10X Fusion or earlier Apple SoC. It was much easier (and better for marketing) to just disallow 32-bit apps from the OS altogether.

Now, flash forward to the release of macOS Catalina, Apple decided to give the Mac this treatment too. At the time, there's no real clear idea as to why this is. All Intel CPUs employed in all Intel Macs have 32-bit instruction sets. Hell, even the T2 chip is based on the A10, which ought to have 32-bit instruction sets. In short, there is no technological reason as to why an Intel Mac can't run a 32-bit app, other than that Apple intentionally removed the functionality from the x86-64 version of macOS in Catalina.

However, putting two and two together: Apple knew, as far back as when they first announced that macOS Mojave would be Apple's last Intel-based macOS release to support 32-bit x86 Mac apps, that they'd be transitioning the Mac to their own SoCs. Said SoCs since A11, haven't changed in their lack of 32-bit instruction sets. Apple would be able to translate 64-bit x86 to 64-bit ARM via Rosetta 2, but not 32-bit x86 to 64-bit ARM (and translating 32-bit x86 to 32-bit ARM to run under 64-bit ARM is out of the question because, again, the 32-bit ARM instruction sets aren't there on anything A11 or newer). So, in short, Apple killed support for 32-bit Intel apps in Catalina to prepare for Apple Silicon not being able to run 32-bit Mac apps of any kind. This is not dissimilar to A10/X Fusion devices losing their 32-bit app support despite the hardware still supporting it. This was just a preparatory move for the Apple Silicon Mac transition. It sucks for those buying an Intel Mac whose minimum OS version is Catalina. But there you have it.

Now, where this becomes hairy is with Windows 10 for ARM64. If what I've said above is correct, then Apple Silicon Macs may have yet another hurdle to be able to run the ARM64 version of Windows 10. I'm not sure whether or not Microsoft's 32-bit x86 app translation technology merely translates 32-bit x86 to 32-bit ARM which runs natively in the ARM64 CPUs that Microsoft has, so far, supported their OS on - or whether the translation is directly from 32-bit x86 to 64-bit ARM. Furthermore, I'm not sure if Microsoft doesn't have underlying components in Windows 10 for ARM64 that are actually 32-bit (much like they sometimes have in the "x64" 64-bit x86 version of Windows) or whether the OS is 64-bit ARM from top to bottom save for emulation technologies (and even then I'm unsure if any ability on Microsoft's part to support 32-bit ARM code would cause issues when running on an Apple Silicon Mac, virtualized or not). I would imagine this complicates the prospect of Windows 10 for ARM64 on Apple Silicon Macs whether natively booting on them or running via virtualization (as I would imagine that it's hard to virtualize 32-bit ARM instruction sets that don't exist on the main CPU).

Anyway, this is the first time I've connected these dots together. Apple isn't verbose about these things and it will pretty much be left up to tech historians to make some kind of sense out of these sequence of events. But there you have it.

 

[leman]

However, putting two and two together: Apple knew, as far back as when they first announced that macOS Mojave would be Apple's last Intel-based macOS release to support 32-bit x86 Mac apps, that they'd be transitioning the Mac to their own SoCs. Said SoCs since A11, haven't changed in their lack of 32-bit instruction sets.

Pretty much this. There were a lot of signs actually, even before the 32-bit deprecation. Like the fact that the 64-bit iOS data types are an exact binary match to x86-64 binary datatypes... Apple has been preparing its ecosystem for this migration for years now, trying to make sure that it will go down as smoothly as possible.

Now, where this becomes hairy is with Windows 10 for ARM64. If what I've said above is correct, then Apple Silicon Macs may have yet another hurdle to be able to run the ARM64 version of Windows 10. I'm not sure whether or not Microsoft's 32-bit x86 app translation technology merely translates 32-bit x86 to 32-bit ARM which runs natively in the ARM64 CPUs that Microsoft has, so far, supported their OS on - or whether the translation is directly from 32-bit x86 to 64-bit ARM. Furthermore, I'm not sure if Microsoft doesn't have underlying components in Windows 10 for ARM64 that are actually 32-bit (much like they sometimes have in the "x64" 64-bit x86 version of Windows) or whether the OS is 64-bit ARM from top to bottom save for emulation technologies (and even then I'm unsure if any ability on Microsoft's part to support 32-bit ARM code would cause issues when running on an Apple Silicon Mac, virtualized or not).

User @Gerdi, who seems to have good knowledge of Windows on ARM said the following. According to them, Windows only use Aarch64 to run any kind of x86 code, and that most if not all native Windows on ARM apps are 64-bit only. I have no reason to doubt this. Microsoft also wouldn't want to design themselves into the corner, given the fact that ARM is dropping 32-bit support in their upcoming high-performance CPU IP.

 

[mr_roboto]

Apple would be able to translate 64-bit x86 to 64-bit ARM via Rosetta 2, but not 32-bit x86 to 64-bit ARM (and translating 32-bit x86 to 32-bit ARM to run under 64-bit ARM is out of the question because, again, the 32-bit ARM instruction sets aren't there on anything A11 or newer). So, in short, Apple killed support for 32-bit Intel apps in Catalina to prepare for Apple Silicon not being able to run 32-bit Mac apps of any kind.

There is no rule saying you cannot emulate a 32-bit CPU on a 64-bit CPU. On ARM64, it's quite simple; ARM64 integer instructions all support operating on either 64-bit or 32-bit values. Since this might be confusing to some, I want to preemptively clarify that this isn't the same as support for ARM32 code. These are ARM64 instruction encodings which specify 32-bit operations, but are only legal when the processor is in ARM64 mode. So, cancellation of 32-bit x86 support wasn't a required step prior to transitioning the Mac to ARM64.

The real reason to cancel 32-bit x86 (imo of course, it's not like Apple has issued any statements on this, this is just me reading between the lines) was mostly a desire to get out of an unpleasant maintenance burden, one which was a problem for Apple even before switching to ARM. The 32-bit x86 ABI and Objective-C runtime were 1990s technology, inherited from NeXT. The 64-bit ABI and ObjC runtime were designed over a decade later by Apple, and Apple took the opportunity to modernize and fix some old pain points with the 32-bit environment.

The most important one was the Obj-C fragile ivar problem. You can read about it in this 2009 blog post by an Apple engineer:

Hamster Emporium: [objc explain]: Non-fragile ivars

The consequence of fragility is that 32-bit Cocoa was a huge pain to maintain. Any time Apple attempted to extend a base class by adding or moving ivars, that could break apps. There were things Apple could (and did) do to mitigate fragility, but not perfectly, and they came at a high cost in labor and flexibility.

64-bit Obj-C and Cocoa solved the fragility problem. This makes it much easier for Apple to make changes and upgrades to system libraries without breaking old software.

So, the ARM decision may have moved the EOL date for x86-32 up a bit, but mainly out of a desire to avoid committing to support that mess at the same time as increasing support burden in another way.

 

[mr_roboto]

I forgot to mention... the other support burden they got to ditch in Catalina by throwing x86-32 out was all of Carbon. 64-bit Carbon was infamously available in beta versions of Mac OS X Leopard (10.5.0), but Apple cut it a few releases before GM. By 2019, it was still 32-bit only, had been deprecated status for a very long time, and could be cut along with all the other 32-bit stuff.

Carbon was a huge chunk of very stagnant library code that must've been increasingly difficult to keep in sync with the rest of the OS. Every time Apple made UI look and feel changes in the primary Cocoa UI frameworks, they would've had to replicate that work in Carbon.

 

[Yebubbleman]

Microsoft also wouldn't want to design themselves into the corner, given the fact that ARM is dropping 32-bit support in their upcoming high-performance CPU IP.

I think that's the key point. It wouldn't make sense for Microsoft to encourage ARM32 code, especially since their Windows RT effort died (and only allowed for Windows Store apps even when it was alive and kicking).

My main concern is 32-bit ARM code within the OS itself. However, if Microsoft was smart (and they likely were in this case), that may not be a show-stopping issue in Windows 10 for ARM64.

There is no rule saying you cannot emulate a 32-bit CPU on a 64-bit CPU. On ARM64, it's quite simple; ARM64 integer instructions all support operating on either 64-bit or 32-bit values. Since this might be confusing to some, I want to preemptively clarify that this isn't the same as support for ARM32 code. These are ARM64 instruction encodings which specify 32-bit operations, but are only legal when the processor is in ARM64 mode. So, cancellation of 32-bit x86 support wasn't a required step prior to transitioning the Mac to ARM64.

The real reason to cancel 32-bit x86 (imo of course, it's not like Apple has issued any statements on this, this is just me reading between the lines) was mostly a desire to get out of an unpleasant maintenance burden, one which was a problem for Apple even before switching to ARM. The 32-bit x86 ABI and Objective-C runtime were 1990s technology, inherited from NeXT. The 64-bit ABI and ObjC runtime were designed over a decade later by Apple, and Apple took the opportunity to modernize and fix some old pain points with the 32-bit environment.

The most important one was the Obj-C fragile ivar problem. You can read about it in this 2009 blog post by an Apple engineer:

Hamster Emporium: [objc explain]: Non-fragile ivars

The consequence of fragility is that 32-bit Cocoa was a huge pain to maintain. Any time Apple attempted to extend a base class by adding or moving ivars, that could break apps. There were things Apple could (and did) do to mitigate fragility, but not perfectly, and they came at a high cost in labor and flexibility.

64-bit Obj-C and Cocoa solved the fragility problem. This makes it much easier for Apple to make changes and upgrades to system libraries without breaking old software.

So, the ARM decision may have moved the EOL date for x86-32 up a bit, but mainly out of a desire to avoid committing to support that mess at the same time as increasing support burden in another way.

I forgot to mention... the other support burden they got to ditch in Catalina by throwing x86-32 out was all of Carbon. 64-bit Carbon was infamously available in beta versions of Mac OS X Leopard (10.5.0), but Apple cut it a few releases before GM. By 2019, it was still 32-bit only, had been deprecated status for a very long time, and could be cut along with all the other 32-bit stuff.

Carbon was a huge chunk of very stagnant library code that must've been increasingly difficult to keep in sync with the rest of the OS. Every time Apple made UI look and feel changes in the primary Cocoa UI frameworks, they would've had to replicate that work in Carbon.

I'll buy all of that for AT LEAST a dollar, but with one exception. If Apple could've supported 32-bit Intel apps as part of Rosetta 2, then why not just wait it out for Intel macOS to die out? Hell, they could've easily pushed their "you can't run 32-bit code" mandate to this release to give some parity with the Apple Silicon release if they merely wanted to deprecate those old libraries. It seems as though merely waiting until the amount of active Intel Mac users started to wane heavily (which won't be much longer) would've been the easier route. Hell, they could've eschewed 32-bit Intel support from Rosetta 2 under a similar pretense that they did in not including PowerPC G4 and G5 specific Alti-Vec support in the original PowerPC-to-Intel version of Rosetta. It seems highly coincidental that they deprecated support for 32-bit when they did, when earlier or later would've been just as, if not more sensible.

 

[Nermal]

they could've easily pushed their "you can't run 32-bit code" mandate to this release to give some parity with the Apple Silicon release if they merely wanted to deprecate those old libraries.

Don't forget the marketing benefit of Arm Macs being able to run virtually all of the same apps as existing Intel Macs. Cutting off support for 32-bit alongside new hardware makes the hardware look less attractive.

 

[Waragainstsleep]

Microsoft must know that ARM is also planning to ditch 32-bit sooner rather than later though. I'm sure they have planned for that.

 

[dlewis23]

Not having 32 bit support is a good thing. We have to get rid of all of this old legacy garage and move on.

Now, flash forward to the release of macOS Catalina, Apple decided to give the Mac this treatment too. At the time, there's no real clear idea as to why this is. All Intel CPUs employed in all Intel Macs have 32-bit instruction sets. Hell, even the T2 chip is based on the A10, which ought to have 32-bit instruction sets. In short, there is no technological reason as to why an Intel Mac can't run a 32-bit app, other than that Apple intentionally removed the functionality from the x86-64 version of macOS in Catalina.

I believe it was removed to aid with the transition to arm. It appears that forcing everyone to update there apps to modern 64 bit API's its going to make building apps for ARM Mac's super easy. Open the app in the latest Xcode check a box and click build, you will likely get a perfect Universal 2 binary with no issues.

It's time to move on.

 

[fokmik]

and water is wet....arm architecture is the future for at least 15-20 years
Even the big servers are going arm because of the waste on cooling inside the buildings that store only big servers, arm reduce the heat drastically
So, not just for the devices is the future, but also for the small and big servers
UK, especially in London, all the companies that have servers already started to place arm, and by the end of 2030 , all of them need to be under arm architecture. Some big evaluating companies already seeing and predicting a lot lot less power consuming because of so much overall less cooling needed and so much weight also being reduce floor by floor

 

[Yebubbleman]

Don't forget the marketing benefit of Arm Macs being able to run virtually all of the same apps as existing Intel Macs. Cutting off support for 32-bit alongside new hardware makes the hardware look less attractive.

It does and it doesn't. Intel Macs effectively killed support for any non-Carbon Mac OS 9 classic apps. I didn't own many of those at the time that I bought the first Intel iMac, but I did own a few. Back when they were warning of 32-bit app support deprication, Apple could've simply warned that "Starting in 2021, Macs will no longer be able to launch 32-bit applications" without directly alluding to the Intel to Apple Silicon transition. That would've sent the message that it was coming soon and then when they reveal Rosetta 2, they could say that it will translate 64-bit Intel but not 32-bit Intel.

It's still a hairy line, but it would seem to be less developer hostile than making developers basically scramble to update their binaries twice in the same span of two years. (Though, I suppose, 64-bit Intel updates will still work in Intel Big Sur and newer Intel releases of macOS, of which there ought to still be quite a few down the road.)

Microsoft must know that ARM is also planning to ditch 32-bit sooner rather than later though. I'm sure they have planned for that.

That would certainly make logical and rational sense. Plus, given them wanting to distance Windows 10 for ARM64 from Windows RT, I can't imagine they supported third party non-metro 32-bit ARM software in Windows, let alone made it easy to develop for.

Not having 32 bit support is a good thing. We have to get rid of all of this old legacy garage and move on.

Certainly if ARM itself is removing 32-bit instruction sets from the architecture, it's good that Apple and Microsoft be prepared for that kind of deprecation for the architecture and their respective platforms under it.

However, I dismiss the notion that dropping support for legacy technology for the sake of doing it is good. Some apps are unfortunately frozen in time with the developer having either gone out of business or otherwise disbanded. The ability to run those apps is important and compatibility ought to be maintained as best as possible while still allowing the platform to move forward. Microsoft may not appear to be good at this, but they're actually the best at this in the industry.

It's looking more and more like Apple didn't need to remove 32-bit Intel support in Intel versions of macOS (I could see how Apple Silicon versions of macOS and Rosetta 2 would be a different story altogether), especially since there's a larger hardware architecture change already in motion. Similarly, Apple could've probably kept 32-bit iOS apps around for anything that had an A10 or older; though I could see how that might be more problematic from a marketing standpoint (seeing as those devices aren't otherwise transitioning to a different architecture).

I believe it was removed to aid with the transition to arm. It appears that forcing everyone to update there apps to modern 64 bit API's its going to make building apps for ARM Mac's super easy. Open the app in the latest Xcode check a box and click build, you will likely get a perfect Universal 2 binary with no issues.

It's time to move on.

That assumes that every developer was already on board with supporting the latest Apple technologies in their apps. Most of the big name developers have done this. But the smaller, more independent developers definitely have not and, for them, this won't be as simple as clicking a checkbox and recompiling.

It's easy to say that it's time to move on when you don't have apps that haven't made the jump (and are in danger of not making the jump). It's for reasons like this that people switch to Windows. Hell, I'm more than one foot out the door on the Mac platform for all of the 32-bit software I use that won't work in Catalina or newer. I can't imagine how much worse it will be for Apple Silicon versions of Big Sur and beyond.

 

[hans1972]

It's still a hairy line, but it would seem to be less developer hostile than making developers basically scramble to update their binaries twice in the same span of two years. (Though, I suppose, 64-bit Intel updates will still work in Intel Big Sur and newer Intel releases of macOS, of which there ought to still be quite a few down the road.)

Killing 32-bit early certainly will help with the transition to arm. It forced users to:

1) Pestering the developer to upgrade to 64-bit
2) Looking for alternatives if software for any reason wouldn't be upgraded to 64-bit
3) Dropping the software
4) Running pre-Catalina in a virtual machine
5) Staying with pre-Catalina

Most of the people running 32-bit software probably chose 1-3 and is now ready for ARM Macs unless they need Windows compability.

If Apple had chosen to remove 32-bit now, quite a lot of people would have issues moving to an ARM Mac immediately.

 

[Krevnik]

Killing 32-bit early certainly will help with the transition to arm.

In addition to that:

From Apple’s perspective, it also means that the Big Sur dev cycle could be focused on ARM related work, rather than ARM and 32-bit.

Apple has to consider how to spend engineering time if they are sticking to the yearly dev cycles.

I’ll also add a bit of texture that by the time the 64-bit requirement happened, a certain majority of apps had already made the transition over the last decade. If a developer had to scramble, it’s only after sitting on their thumbs for years. So I’m not sure I buy the “make developers scramble twice” argument in this case.