Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com)

Last year, Apple announced that macOS High Sierra "will be the last macOS release to support 32-bit apps without compromise." Now, in the macOS High Sierra 10.13.4 beta, Apple is notifying users of the impending change, too. "To prepare for a future release of macOS in which 32-bit software will no longer run without compromise, starting in macOS High Sierra 10.13.4, a user is notified on the launch of an app that depends on 32-bit software. The alert appears only once per app," Apple says in the beta release notes. Ars Technica reports: When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall. Developers and users curious about how this will play out will be able to look at the similar process in iOS for context. On January 1 of this year, Apple stopped accepting 32-bit app submissions in the Mac App Store. This June, the company will also stop accepting updates for existing 32-bit applications. iOS followed a similar progression, with 32-bit app submissions ending in February of 2015 and acceptance of app updates for 32-bit apps ending in June of 2015.

Comments

Apple compatibility is a joke

[Anonymous Coward]

I can still run Windows apps originally compiled in 1992 on Windows 10.

Just sayin'.

Re: Apple compatibility is a joke

[Midnight Thunder]

While I do feel Apple can be too eager in breaking backwards compatibility, I also think Microsoftâ(TM)s model is equally absurd.

In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?

Re:Going to be some resistance to this one

[Immerman]

Having developed on both platforms (addmitedly only some on Apple), I have to say that Apple has a tendency to add a lot of little "programmer shinies" with every new update - handy new utilities, programming features, etc. that tempt developers to use them. Which then makes their software incompatible with older versions of the OS. So, if you want to keep running the latest versions of all your modern apps you pretty much need a fairly recent version of the OS.

Contrast that with Microsoft, whose "go suck it" attitude to developers, and tendency to try to replace old, reliable components with newer, more annoying ways of doing things, combined with their commitment to maintaining backwards compatibility, means that developers tend to stick with the old tried-and-true standbys, unless there's some compelling reason to move forward (e.g. powerful new features added in DirectX 10 and 11).

Apple's approach does a lot more to create a constantly improving programming environment (or at least the impression of one), but also keeps their users on a more vigorous upgrade treadmill.

That said - at this point I suspect most 32 bit-only Apple software can probably run in an "emulated" compatibility layer with plenty of performance, much as older XP apps can do on modern windows. But such compatibility is always imperfect, hence "will be the last macOS release to support 32-bit apps without compromise."

Re:32-Bit is like what 16-Bit was in the late 90s

[Immerman]

>Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.

You think? I'm not so sure. Or, at least it will take a lot longer than previous transitions.

The driving force behind bit-size increases seems to be RAM - vector processors (aka GPUs these days) and other SIMD techniques address performance issues quite sufficiently, and there's very little call for calculations to be performed more precisely than can be done in 32 bits, much less 64 (neglecting limited demand for exact calculations, which will always need to be implemented in software)

32 bit computers had been flirting with their limitations for a while - 32 bit addresses can only access 4 GB of RAM without all sorts of performance-killing jumping through hoops (pointer arithmetic is fundamental to almost everything). And unlike 16 bit computers (which can only natively address 64kB of RAM and required hoop-jumping from day one on PCs), 32 bit OSes were born in the time of the 386, when a couple MB of RAM was impressive, and 4GB was an unimaginably insane amount, so new OSes could get the performance benefit of assuming all RAM was directly addressable, with vast ranges of "this will never be used" address space that could be allocated to various non-RAM purposes (hence only being able to use ~3.5GB of your 4GB of RAM on Windows XP).

64-bit computers though are a far larger jump again. Going from the 286 (16 bit calculations, 24 bit addresses through "protected mode") to the 386 (32 bit native addresses) only introduced an extra 8 address bits - 256x times the space, from 16 MB to 4GB, or about 16 years by Moore's Law at the time. Going from 32 to 64 bits adds about 4 billion times the natively computable address space - or about 48 years by the modern accelerated Moore's Law. Meanwhile, actual uses for more memory seem to finally be slowing down - over a decade since Microsoft introduced a mainstream 64-bit OS, there's still not really much to be gained by most people having more than 8GB of RAM in a PC.