Apple may not have revealed its timetable for the removal of support for 32-bit software, but it has made it clear that it will happen, just as it did in iOS. Mojave contains several tools to help us prepare. This article looks at them, and considers how the transition is going.

New for Mojave is a section in System Information titled Legacy Software, which Apple claims details “all applications that have not been updated to use 64-bit processes.” Also in its Software section are listings of applications, extensions, and other forms of code which contain further information.

Mojave additionally introduces a warning dialog which appears the first time that you launch a 32-bit app, and if you’re feeling really adventurous, you can start up in Recovery mode and set your NVRAM so that macOS will block all 32-bit code from running when you restart. The last of these is primarily intended for developers, to help them isolate dependencies on 32-bit frameworks and the like; as it is by far the most radical, and Apple isn’t recommending it for regular users, I won’t consider it any further here.

Legacy Software in System Information

I have no idea what criteria this uses for identifying apps, but it only ever reports a fraction of those which are known to be thoroughly 32-bit. For example, on this iMac with 335 known apps which are 32-bit only, it reports just 5: three support tools from Adobe, Apple’s Compressor, and a helper app for an old copy of QuarkXPress. It doesn’t notice that the whole of Adobe CS6 or Microsoft Office 2011 are also 32-bit apps, for example.

Whatever this new Legacy Software item might think it’s doing, don’t even bother to look. It doesn’t make any sense, and will only mislead you into being complacent.

System Information, other sections

Prior to Mojave, these were the only places to go where Apple provided information on 32-bit code. They continue to function, and if all you have is System Information, then it appears reliable, as far as it goes.

Applications lists all those apps (but only apps) which declare themselves to be 32-bit. These include the whole of Adobe CS6 and earlier, Bento, Apple’s current release of Compressor, and the whole of Microsoft Office 2011 (version 14). This appears accurate, but isn’t always helpful because of the way that it lumps all apps together in alphabetical order. I seem to have loads of apps called Setup, so identifying each can get tedious.

Extensions are often overlooked, but important to check. Unfortunately this isn’t listed in their properties, so you have to inspect each one individually to see its architecture, and even then it may not be given.

Preference Panes do have 32-bit listed in their properties; although normally quite a short list, it bears checking.

Frameworks are among the most numerous, and 32-bit is thankfully listed among their properties. Some of Apple’s frameworks which are still 32-bit include AECore, AppKitScripting, CarbonSound, HTMLRendering, NavigationServices, QuickTime, Scripting, and vmutils. There are over a hundred identified here in all.

The biggest problem with using System Information is that there is no easy way to extract information from it, apart from saving a full system report. Select a load of 32-bit frameworks, and you can’t copy and paste their details into a text document for follow-up action. This remains a startling omission, which severely limits its usefulness when tackling this problem.

Warning dialogs

Another feature which is new with Mojave is a warning dialog which is displayed the first time that a 32-bit app is run. Although a good idea, in practice these are of essentially little use, as these can only be triggered when an app undergoes a full Gatekeeper check because it has its quarantine flag set. So all those old bits of code which have been installed without a quarantine flag, or which have already been run, pass this test with flying colours.

If you don’t see many of these dialogs, it’s probably because your 32-bit code doesn’t trigger them, not because it’s not there in the first place.

32-bitCheck

The sole purpose of my free app 32-bitCheck is to scan folders thoroughly and report which code within them is still 32-bit. It’s not fast, because being thorough means checking every nook and cranny, and testing each file carefully. And it’s not something which you just point at a whole startup volume and expect it to scan several million files there.

When it checks my current Applications folder, it finds 335 apps out of 1429 there are 32-bit only. These are the same as those already listed in System Information’s Applications item, but 32-bitCheck will save them to a text file, or you can copy and paste its results into any other app.

When you look at apps outside the main Applications folder, there are some surprises to come. Of 212 apps in /System/Library, for instance, two, quicklook32.app and InkServer.app, are 32-bit only. In /Library, it is far worse, with 68 out of 165 apps being 32-bit only, these largely confined to the Application Support folder.

I know of no other tool which not only identifies whole apps which are 32-bit only, but extends to cover all types of bundle and Mach-O code files: 32-bitCheck does, and it is in these which the results become more worrying.

In /System/Library, there is a total of over 7500 code files of various types, of which 142 are still 32-bit. Those are mostly old frameworks to support QuickTime, but include the Perl 5.18 extras. The situation in /Library is no better: of more than 5500 code files, over 1400 are 32-bit. Again, many are frameworks, but these include the Silverlight Internet plugin, a lot of QuickTime components, and even some Spotlight plugins.

You may still have some old remnants in your Mac’s hidden folders: /usr here has 23 of 1843 which are still 32-bit, and one quirk is /sbin/autodiskmount, which is still listed as being 32-bit.

How’s it going?

The situation with apps is fairly clear. Most of those left now have already been upgraded (Microsoft Office), or replaced by other apps (Adobe CS). Of those which are not yet accounted for, the great majority no longer exist – for me old developer tools such as an APL environment which was never released in 64-bit form. Perhaps a Virtual Machine will be their only viable future.

Of much greater scale and concern are those code items which are not apps, but frameworks, plugins, and so on. Over the years and with system migrations, our Macs become cluttered with these, some left long after the original app has been removed. Identifying all those which are 32-bit and discovering which apps might use them is a huge and laborious task for many users, and is unlikely to be done. Neither is there an easy way of automating that process of discovery. Apple still needs to provide better tools, which are better-designed to help users address the problems of migration.

Unless you have started with a ‘clean’ Mac in the last few years, it looks likely that a future 64-bit only release of macOS will still catch a great deal of software unawares.