I get this pop-up warning on one-off installers and such irrelevant situations. I understand it's to encourage a migration away from 32-bit apps; fine, but there's nothing I can do about it. It's getting on my nerves. Is there some way to put a stop to it altogether?
As mentioned (very briefly) in Apple's guide on how to Prepare your institution for iOS 12 or macOS Mojave, the
CSUIDisable32BitWarnings property key can be used to disable the 32bit warning alert.
This can be done in either of the following two ways:
In the terminal
According to this page, the warnings can be disabled by entering the following command in the terminal:
defaults write -g CSUIDisable32BitWarnings -boolean TRUE
To re-enable the warnings:
defaults delete -g CSUIDisable32BitWarnings
To display the current setting:
defaults read -g CSUIDisable32BitWarnings
where 1 means the alerts are disabled, and 0 or a does not exist error message means the alerts are active.
Using a management profile
The same effect can be achieved by preparing a management profile that sets the property key, as proposed by Apple in the above mentioned article. This may be the preferred solution to disable the alerts on multiple Macs.
This article explains how. It also provides a link to a sample management profile. The profile can be installed by downloading and double-clicking it.
For the sake of completeness, this is the example from the above link:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>CSUIDisable32BitWarnings</key> <true/> <key>PayloadDescription</key> <string>Configures com.apple.coreservices.uiagent settings</string> <key>PayloadDisplayName</key> <string>com.apple.coreservices.uiagent</string> <key>PayloadIdentifier</key> <string>com.company.profile.57E80D89-1CA6-4386-8FDE-81DA0292CA3D.com.apple.coreservices.uiagent.FE123766-B72C-4620-9A21-CCABBEB48B2A</string> <key>PayloadOrganization</key> <string></string> <key>PayloadType</key> <string>com.apple.coreservices.uiagent</string> <key>PayloadUUID</key> <string>FE123766-B72C-4620-9A21-CCABBEB48B2A</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array> <key>PayloadDescription</key> <string>Disable 32-bit application warnings</string> <key>PayloadDisplayName</key> <string>Disable 32-bit application warnings</string> <key>PayloadIdentifier</key> <string>com.company.profile.csuidisable32bitwarning.57E80D89-1CA6-4386-8FDE-81DA0292CA3D</string> <key>PayloadOrganization</key> <string>Company Name</string> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>57E80D89-1CA6-4386-8FDE-81DA0292CA3D</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>
This blog article might be interesting in this context: Mojave’s Legacy Software is doubly wrong
~/Library/Preferences/com.apple.coreservices.uiagent.plist seems to maintain a list of alerts and last alert date for 32bit apps. If your alerts keep reappearing, it might help to delete it, but that is just an assumption.
boom! Not only do we not have to reverse engineer this here (since Rich and the Mac admin team have documented their efforts), Apple is programming this in so that companies can manage this via accepted management tools that scale like MDM and profiles.– bmike ♦Feb 9, 2019 at 12:39
1This does not seem to work anymore. I seem to get this warning once a month per 32-bit app I run, after having set
defaults read -g CSUIDisable32BitWarningdisplays 1, so I have confirmed this setting is enabled. This is on OSX 10.14.1 Apr 16, 2019 at 2:09
1@catchdave, have you tried to prefix the
sudo? May 11, 2019 at 10:37
1@not2savvy: Yes and ran the read command and get
1returned as expected. But still get the dialogs several times a month. Jun 13, 2019 at 4:45
@catchdave, I just noticed and corrected a typo in the property key name of the command line examples. If you had copied them, please try again. Also added an update about the plist that holds a list of 32bit app alerts which may be helpful. Jan 1, 2020 at 2:01
This alert fires one time when you launch each app that’s going to stop working in the near future. Other than opening up system information and getting all the alerts out of the way, there is no documented way to stop this alert or fake the file that tracks whether the alert has fired.
It is to let the users know that the 32-bit apps they are using will no longer be supported in the next major version of macOS. This is especially critical for helpers like installers - there’s no reason these developers don’t use a modern apple package or just modernize their helpers. Imagine how disappointed future you will be to find your 64 bit app can not be reinstalled since it uses a now broken installer.
For more details, you can refer to the Apple Support document, 32-bit app compatibility with macOS High Sierra 10.13.4 and later.
1I'm installing a lot of apps (setting up a new comp), which are themselves 64-bit, but it seems that a lot of the time their installers are themselves 32-bit apps.– IgidMay 1, 2018 at 22:52
1As you mentioned that the installers are 32-bit but the installed apps are 64-bit, the installers may stop running in subsequent major releases of macOS. However the installed 64-bit apps will continue to run. You can get in touch with the app developers and share your concern with them. This way you can ensure continued availability of the apps that you use in the future releases of macOS.– Nimesh Neema ♦May 2, 2018 at 8:51
4That's all well and good, but basically it means Apple's strategy is 'get to the developers by annoying the users'. I'm sure that once the apps' installers are no longer supported they'll update them - I'm not worried about it; I don't want to see the warning. So there's no way through a script or
defaultscommand?– IgidMay 2, 2018 at 11:28
1No, there isn't any way to get rid of the alert.– Nimesh Neema ♦May 2, 2018 at 13:11
3There is in fact a documented way to get rid of the alerts, see my answer. Feb 9, 2019 at 11:57