5 ms·

Can someone explain to me what Apple gains by dropping 32-bit app support?

by xmichael999 7y ago

scarface74 7y ago
That’s less of a surface area to support, maintain, or to have to worry about security vulnerabilities.
whynotminot 7y ago
Security.
xenadu02 7y ago
32-bit macOS uses the older fragile ObjC runtime. Meaning no macOS frameworks present on 32-bit macOS could adopt newer features. In fact they couldn’t even add new ivars because that changes the class layout and would be ABI-breaking. That’s beside the increased disk space and memory used having two copies of everything.
msbarnett 7y ago
32 bit code is stuck with the older ObjC runtime, which can’t support a bunch of new language features and suffers from from fragile ABI issues which make changing the internals of classes extremely problematic. It’s not simple to fix (“just upgrade the runtime to support the new features”) because the newer runtime trades on the fact that a bunch of unused space in 64 bit pointers can be exploited for tagging, pointerless classes and a bunch of other things. And if they did fix the fragile ivar problem on the 32bit runtime, you’d need to recompile to use the new way of dynamically calculating strict offsets to member fields — and these apps are mostly dying with 32bit precisely because no one is recompiling them. It’s basically dead-end code that is difficult to maintain and which increasingly requires the rest of the OS to stagnate just to keep it running.
- mrpippy 7y ago
  Also: the Carbon API set is only supported on 32-bit, and removing 32-bit means all of Carbon can go away. Carbon is a massive API set, with one or sometimes two full legacy APIs (often dating back to the 90s) for everything. Drawing (QuickDraw), multimedia (QuickTime), open/save dialogs (NavServices), fonts/text rendering (Font Manager, ATSUI), windows/menus/dialogs (both HIToolbox and the classic Managers), file I/O, printing, and on and on. Keeping all this stuff functional (to support old apps) while evolving the system underneath is a huge burden which will be lifted from 10.15 on.
agloeregrets 7y ago
Another factor is if they eventually move to their ARM chips in Macs they need to deal with the fact that The Ax CPUs lack 32Bit support and are 64Bit only.

Can someone explain to me what Apple gains by dropping 32-bit app support?

scarface74 7y ago

That’s less of a surface area to support, maintain, or to have to worry about security vulnerabilities.

whynotminot 7y ago

Security.

xenadu02 7y ago

32-bit macOS uses the older fragile ObjC runtime. Meaning no macOS frameworks present on 32-bit macOS could adopt newer features. In fact they couldn’t even add new ivars because that changes the class layout and would be ABI-breaking. That’s beside the increased disk space and memory used having two copies of everything.

msbarnett 7y ago

32 bit code is stuck with the older ObjC runtime, which can’t support a bunch of new language features and suffers from from fragile ABI issues which make changing the internals of classes extremely problematic. It’s not simple to fix (“just upgrade the runtime to support the new features”) because the newer runtime trades on the fact that a bunch of unused space in 64 bit pointers can be exploited for tagging, pointerless classes and a bunch of other things. And if they did fix the fragile ivar problem on the 32bit runtime, you’d need to recompile to use the new way of dynamically calculating strict offsets to member fields — and these apps are mostly dying with 32bit precisely because no one is recompiling them. It’s basically dead-end code that is difficult to maintain and which increasingly requires the rest of the OS to stagnate just to keep it running.

mrpippy 7y ago
Also: the Carbon API set is only supported on 32-bit, and removing 32-bit means all of Carbon can go away. Carbon is a massive API set, with one or sometimes two full legacy APIs (often dating back to the 90s) for everything. Drawing (QuickDraw), multimedia (QuickTime), open/save dialogs (NavServices), fonts/text rendering (Font Manager, ATSUI), windows/menus/dialogs (both HIToolbox and the classic Managers), file I/O, printing, and on and on. Keeping all this stuff functional (to support old apps) while evolving the system underneath is a huge burden which will be lifted from 10.15 on.

agloeregrets 7y ago

Another factor is if they eventually move to their ARM chips in Macs they need to deal with the fact that The Ax CPUs lack 32Bit support and are 64Bit only.