I remember when 64-bit apps first started becoming possible, people said you'd only need them for special cases, when lots of memory was needed. But looking back, that "lots of memory" is anything greater than 3GB, which today does not seem like a lot. It's time for 32-bit apps to join 16-bit apps in that great computer museum in the sky.
From a technical side and OS design standpoint, this is not necessary. The real reason for this is to push their agenda towards the new hardware. They are flirting with producing a non-Intel platform and this is designed to help make this a cleaner transition. Overall it's very disappointing to see this kind of action from Apple without being both more forthright or offering more options for its users. They can continue to offer uncompromised support even more simply than they did with PowerPC support as they previously did for a longer period of time since it's actually part of the hardware, especially for the "legacy" (ha ha) systems that will be around for many, many years to come.
Let's not even address your tinfoil hat accusations that others have already addressed, and let's keep with the technical side and OS design standpoint. I wade around in Windows OS code on a regular basis for my role where I work, and I can tell you with 100% certainty that dealing with both 32-bit and 64-bit applications in a mixed environment in the OS adds lots of complications to accomplish, and plenty of room for bugs to creep into the mix when thunking between 32 and 64 bits, as the kernel will be running in the opposite bitness for at least one of them, and things can literally get lost in the conversion.
It also has an absolute performance cost to run a combination of both 32 and 64-bit applications, in CPU cache, as well as RAM in general: supporting 32-bit at the same time requires a significant amount of code that's executed and thus also binary files that exacts a price.
Apple isn't an enterprise-focused company, but rather more of a consumer/home user-focused company, while Microsoft is the opposite. They have their advantages and disadvantages, and Windows carries over all kinds of compatibility shims for the sake of backwards compatibility over a very long period of time, because that's what Enterprise demands, and that's the price of doing business. It's a major cost to make sure that third-party applications that depend on past behavior (documented and not) don't break, leaving a lot of unhappy users. This holds back the development of Windows, and keeps it from being as lean as it might otherwise be: there's a LOT of deprecated stuff in Windows that hasn't been removed, that really should be, because it has been replaced with something better, but Microsoft caters to the enterprise and that's where they make the bulk of their money, so... Windows has a huge amount of inertia to change.
The problem is, that Apple doesn’t bundle transitions.
PPC to Intel then introduction of 64bit then no Rosetta then no Carbon then no Java then no QT then no 32bit then ARM etc.
each time some plugins, apps, etc. stop working, one has to buy replacements, which may stop working with the next transition.
It would have been easy to keep QT, Java and 32bit a PPC thing running on Rosetta, and wait with the intel introduction until it was strictly 64-bit.
The problem is, plenty of small software “just works” but is discontinued, and each extra transition is a failure point. So better fewer big transitions, than many smaller ones.
The problem is, that Apple doesn’t bundle transitions.
PPC to Intel then introduction of 64bit then no Rosetta then no Carbon then no Java then no QT then no 32bit then ARM etc.
each time some plugins, apps, etc. stop working, one has to buy replacements, which may stop working with the next transition.
It would have been easy to keep QT, Java and 32bit a PPC thing running on Rosetta, and wait with the intel introduction until it was strictly 64-bit.
The problem is, plenty of small software “just works” but is discontinued, and each extra transition is a failure point. So better fewer big transitions, than many smaller ones.
1) You missed the transition from Motorola to PPC. Did they use 16-bit Moto processors for the original Mac? I don't think they did.
2) All those changes are a good thing. The last thing I want is to be running Mojave and have a crapload of spaghetti code that is still supporting everything you mention all the way back to PPC. It would cause a countless more issues which would slow down their progress. If there is archaic code that you need to run your system then the solution is to simply not update your Mac. Maybe that's not an ideal solution, but it's not ideal for Apple to still support legacy code forever. Dropping 32-bit binaries means they can pave the way for supporting x86_64 and AArch64 in a future release more seamlessly, which is better for Apple, developers, and customers.
From a technical side and OS design standpoint, this is not necessary.
No, because Apple did something smart. Back in Mac OS X 10.5 with Objective-C 2.0 they used the 32-to-64 bit transition to hide some big changes to the OS — most noticeably, the ability to make changes to classes under applications: Classes are no longer fragile. Rather than introduce a second version of 32-bit and make developers pick which to target, they just left it alone and moved on with 64-bit code. This meant that maintaining those classes was going to be a pain. Either they didn't update them at all, they came up with ways to update them just for 64-bit, or they came up with a way to patch in 32-bit support.
None of that is a big deal in the short term, but there comes a point where that game has to end and you need to move on. The new runtime went public in late 2007. 10 years is a long time to drag that legacy runtime behind.
The problem is, plenty of small software “just works” but is discontinued, and each extra transition is a failure point. So better fewer big transitions, than many smaller ones.
Isn't that exactly what we do have? PPC to Intel was 10 years ago, 68k to PPC 10 years before that. Command line to GUI 10 years before that. 1 major transition every 10 years isn't too much to stomach.
I suppose the transition could have been PPC to x86-64 and killed two birds with one stone, but rewriting macOS to not only work on Intel, but also exclusively use the 64-bit instruction set may have been outside Apple's reach. And Rosetta would quite possibly have failed.
From a technical side and OS design standpoint, this is not necessary. The real reason for this is to push their agenda towards the new hardware. They are flirting with producing a non-Intel platform and this is designed to help make this a cleaner transition. Overall it's very disappointing to see this kind of action from Apple without being both more forthright or offering more options for its users. They can continue to offer uncompromised support even more simply than they did with PowerPC support as they previously did for a longer period of time since it's actually part of the hardware, especially for the "legacy" (ha ha) systems that will be around for many, many years to come.
Flirting not the same as planning. ARM-based cpus are way behind Intel chips in terms of pure horsepower. The other issue is there is no magic way to make the transition from Intel to ARM painless anymore then there was from PowerPC to Intel. In fact, the later was so much of a change that Apple didn't even try to write a way for PowerPC programs to run on Intel systems.
Also from a technical side and OS design standpoint there is a very good reason to drop the 32-bit support - no need to support two programing libraries. This makes for a smaller OS which in turn makes debugging and fixes a lot saner.
As a software engineer for many decades myself, let me say that Ylon is absolutely correct. It is disappointing to see the sadly common arrogance of Apple and the development community here. The focus should be on USERS not developer's needs. If I want to run that old 32-bit version of Photoshop so I don't have to tithe to Adobe every month, I should be able to do so. If I want to program my old Harmony One remote I should be able to do so. If I want to run Quicken 2007 because Intuit are idiots, I should be able to do so. Apple is here to serve me, not the other way around. And, as Ylon also pointed out, we're not talking about emulating a completely different processor architecture here. This is all about saving and making money for Apple and the software companies (and lazy kids pursuing aesthetic goals). Get off my lawn!
Comments
It also has an absolute performance cost to run a combination of both 32 and 64-bit applications, in CPU cache, as well as RAM in general: supporting 32-bit at the same time requires a significant amount of code that's executed and thus also binary files that exacts a price.
Apple isn't an enterprise-focused company, but rather more of a consumer/home user-focused company, while Microsoft is the opposite. They have their advantages and disadvantages, and Windows carries over all kinds of compatibility shims for the sake of backwards compatibility over a very long period of time, because that's what Enterprise demands, and that's the price of doing business. It's a major cost to make sure that third-party applications that depend on past behavior (documented and not) don't break, leaving a lot of unhappy users. This holds back the development of Windows, and keeps it from being as lean as it might otherwise be: there's a LOT of deprecated stuff in Windows that hasn't been removed, that really should be, because it has been replaced with something better, but Microsoft caters to the enterprise and that's where they make the bulk of their money, so... Windows has a huge amount of inertia to change.
PPC to Intel
then introduction of 64bit
then no Rosetta
then no Carbon
then no Java
then no QT
then no 32bit
then ARM
etc.
each time some plugins, apps, etc. stop working, one has to buy replacements, which may stop working with the next transition.
It would have been easy to keep QT, Java and 32bit a PPC thing running on Rosetta, and wait with the intel introduction until it was strictly 64-bit.
The problem is, plenty of small software “just works” but is discontinued, and each extra transition is a failure point. So better fewer big transitions, than many smaller ones.
Is that NOW or in the next OS concurrent with the removal of 32-bit support?
1) You missed the transition from Motorola to PPC. Did they use 16-bit Moto processors for the original Mac? I don't think they did.
2) All those changes are a good thing. The last thing I want is to be running Mojave and have a crapload of spaghetti code that is still supporting everything you mention all the way back to PPC. It would cause a countless more issues which would slow down their progress. If there is archaic code that you need to run your system then the solution is to simply not update your Mac. Maybe that's not an ideal solution, but it's not ideal for Apple to still support legacy code forever. Dropping 32-bit binaries means they can pave the way for supporting x86_64 and AArch64 in a future release more seamlessly, which is better for Apple, developers, and customers.
None of that is a big deal in the short term, but there comes a point where that game has to end and you need to move on. The new runtime went public in late 2007. 10 years is a long time to drag that legacy runtime behind.
I suppose the transition could have been PPC to x86-64 and killed two birds with one stone, but rewriting macOS to not only work on Intel, but also exclusively use the 64-bit instruction set may have been outside Apple's reach. And Rosetta would quite possibly have failed.
Also from a technical side and OS design standpoint there is a very good reason to drop the 32-bit support - no need to support two programing libraries. This makes for a smaller OS which in turn makes debugging and fixes a lot saner.