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

Going to be some resistance to this one

[fyngyrz]

I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.

For some, the answer will be to simply not move to the new OS (notice I didn't use the term "upgrade.") For others, it may be a VM, unless the VM's can't run in 32-bit mode (don't know why that would be the case, but perhaps it is.)

It is Apple's habit to go with "hey, I have an idea" where for some reason, no one stands up and tells them "you know, that's not a good idea..." They did it with the PPC emulation, they did it with headphone jacks, they did it with slowing down people's phones, and now... now they're going to kill a lot of people's tools.

Interesting times for Apple.

Re:Going to be some resistance to this one

[TheRaven64]

They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.

This is so laughably untrue that I don't know where to start.

First, the OPENSTEP bundle format that Apple inherited from NeXT includes a concept of versioning in the loader. You can link either to the latest version of a framework, or explicitly to an older one, and you can ship multiple library binaries for different versions in the same framework, with the linker correctly finding the right one.

Second, each Mac application embeds a MacOS deployment target, which will put some APIs into compatibility modes if you invoke them on a newer system.

Third, all of the Apple headers include annotations about which versions of each of their operating systems introduced, deprecated, and removed APIs, so you can explicitly target older versions and get compiler errors if you use a newer API. I'm not sure why you think it's better for them to provide copies of older headers instead of doing this.

Fourth, a bunch of the APIs include constants that tell specific subsystems about the expected version. For example, each time they improve the line-breaking algorithm in the text layout engine, they bump an enum value so that code compiled with an older deployment target, or code that explicitly opts into the older behaviour for compatibility, will get the old behaviour.

Re:Apple compatibility is a joke

[sit1963nz]

Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'

Re:Apple compatibility is a joke

[0100010001010011]

Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.

How much 'cruft' and security holes exist in Windows because of that backwards compatibility? Let some things die. If you want to run an app on Windows 3.1, run a VM of Windows 3.1.

Re: Apple compatibility is a joke

[Hal_Porter]

You should go to Raymond Chen's Old New Thing blog and tell him this. I'm sure he'd be eager to hear one liner technical advice from Slashdotters on how Microsoft should handle back compatibility.

https://blogs.msdn.microsoft.c...

Re:Apple compatibility is a joke

[codlong]

I know a lot of people use linux, but our shop uses exclusively Apple macbook pros for developers. The system admins lobbied for it because they claim they are much easier to maintain, and OS X gives us a BSD-based system to develop on. Apple is fantastic for professional developers, not just grandma using Facebook.