Software which is designed to be installed on macOS Sierra should not be a problem, as its developers should ensure that it negotiates its way through the additional protection now built into macOS. But some older software will encounter problems. This article looks at what can go wrong, and how you can address it.

 

Signatures and Gatekeeper

As in El Capitan, all newly-downloaded apps are checked by Gatekeeper when they are run the first time after installation. Sierra has lost the option which allowed unsigned apps to be run without further checks. However, you can still run unsigned apps from the Finder when you need: select the app icon, bring up the Finder’s contextual menu, and select Open.

Running installers from disk images or archives

An extension to Gatekeeper now performs App Translocation on any installer app in a mounted disk image or archive. This moves the app to a randomised location, and runs it from that hidden folder. This breaks some older installers, as they can no longer find the resources which they need for the installation process.

If an installer does break, there is little that you can do to try to work around it, other than trying to manually extract and copy across the required components, something that many installer apps prevent. If the installer won’t run as normal, and won’t run when copied over to your hard disk, it is going to be almost impossible to use now.

Old Installer bundles

Gatekeeper performs additional checks on packages which are loaded and run by the Installer app. Some traditional packages kept as bundles may fail these checks, in which case the installation becomes impossible. Developers now have to use their tools to create new flat-file installer packages, which is not something that a user can do. So far this does not appear to affect many old installer packages, thankfully.

Installation into folders protected by SIP

Most of Sierra’s system folders now come under System Integrity Protection (SIP). This applies to almost all of /System/Library, together with the hidden folders /bin, /etc, /sbin, /tmp, /usr, and /var. Within those, there are some folders with less or no protection from SIP. Those include /System/Library/Caches, /System/Library/Extensions, /System/Library/Speech, /System/Library/User Template, and /usr/local.

As a general rule, any installer which tries to install components in /System/Library will not work, as some of those components at least cannot be installed in their intended folders. The same applies to /usr, unless it is in /usr/local.

There are two approaches worth considering. The better is to use a tool such as Pacifist to extract the components contained in the installer package, and manually install those in equivalent folders in /Library instead. Where developers have provided updated installers which are compatible with Sierra, that is their most likely approach, and it should not compromise security.

Say, for example, that the installer contains a kernel extension and a LaunchAgent, which it wants to install in /System/Library/Extensions and /System/Library/LaunchAgents respectively. Current policy is that kernel extensions like that should be installed in /Library/Extensions, although you may discover that /System/Library/Extensions is still possible (as that folder is not yet fully protected by SIP). However, /System/Library/LaunchAgents is fully protected, you cannot alter its contents, and the installer will fail as a result.

If you extract the two components to another folder, you can then install the kernel extension in /Library/Extensions and the LaunchAgent in /Library/LaunchAgents. You may then need to edit the LaunchAgent (perhaps using Lingon) to correct any path references, such as that to the kernel extension.

If you cannot perform that manual installation, but must install the software, the only way is to restart in Recovery mode and disable SIP. That requires the Terminal command
csrutil disable

Restart, run the installer, then restart again in Recovery mode and turn SIP back on using the Terminal command
csrutil enable

This may still fail if any kernel extension is not properly signed using a special signature for such extensions, or macOS may simply refuse to load the components. Worse still, they could cause a crash during startup, which might require you to remove the components. If you have only been able to install them with SIP turned off, you will have to go through the process of turning SIP off all over again before you can remove them.

Don’t forget to turn SIP back on. If you’re unsure whether it is active, simply type
csrutil status
into Terminal to see that.

Removing bundled apps

SIP works both ways: not only can you not install items in its protected folders, but you cannot tamper with apps and components which are protected by SIP. This means that you cannot move or remove the following apps from the Applications folder:
App Store, Automator, Calculator, Calendar, Chess, Contacts, DVD Player, Dashboard, Dictionary, FaceTime, Font Book, Image Capture, Launchpad, Mail, Maps, Messages, Mission Control, Notes, Photo Booth, Photos, Preview, QuickTime Player, Reminders, Safari, Siri, Stickies, System Preferences, TextEdit, Time Machine.

You cannot move or remove the following apps from Applications/Utilities:
Activity Monitor, AirPort Utility, Audio MIDI Setup, Bluetooth File Exchange, Boot Camp Assistant, ColorSync Utility, Console, Digital Color Meter, Disk Utility, Grab, Grapher, Keychain Access, Migration Assistant, Script Editor, System Information, Terminal, VoiceOver Utility.

If you are unsure as to which folders are protected and which not, you can copy the current SIP configuration from /System/Library/Sandbox/rootless.conf and /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths to another folder, and inspect those listings. You can also use the Terminal command
ls -laO path
with path as the path to the folder you wish to inspect. Folders which are identified there as sunlnk cannot be removed, and items listed as restricted are protected by SIP.

Compile and install

Software which is provided as source code and compiled on your Mac prior to installation is restricted to using /usr/local as its destination, and cannot for example install into /usr/bin. If the build scripts do not allow you to specify an installation folder which is compatible with SIP, you will have to modify them to do so. It is usually simplest to use one of the package management systems designed to make this easier, such as MacPorts or Homebrew.