One of the longstanding joys of the Mac has been how you can customise apps, giving them new icons and, in the past at least, even a few gentle tweaks. What’s unfortunate is that changing apps isn’t just for users. If we can alter them, so can an attacker, and the last thing any of us would want is for Safari or Preview to turn malicious. Over the years the scope for making changes to apps has therefore been reduced. This article explains how, and what we can still do.

To understand how customisation has been limited, we need to know what can and can’t change.

Signature

The most basic requirement of any app is that it’s signed. This provides a set of hashes that can be used to verify that none of its contents have been changed since that app was signed, and those hashes are hashed again to product code directory hashes, CDHashes, that are used to identify and recognise the app. Whatever we might customise in an app, its CDHashes must match its contents.

Certificate

Next comes the chain of trust established by the certificate used to sign the app. Developer certificates are issued by Apple as their Certificate Authority, so they each can be traced back through an Apple Intermediate certificate to Apple’s Root certificate, the chain of trust.

An Apple-issued certificate isn’t required for macOS to run an app, though. Because many Mac users build their own apps locally from open source, local or ad hoc certificates are also acceptable. However, anyone can sign an app with an ad hoc certificate, including an attacker, and, apart from the few malicious apps that have been signed using developer certificates, all other malware for the Mac is now ad hoc signed. As ad hoc signatures have no chain of trust, you can’t put any trust in them.

Notarization

Over the last few years, Apple has required developers to get their apps notarized. That involves ensuring the app meets certain security requirements, and is submitted to Apple to be checked to see if it contains any malicious code. Apps that satisfy those requirements are then issued with a ticket, that’s usually stapled inside the app’s bundle. That consists of the app’s set of CDHashes, again used to identify and recognise that app.

Although there’s no reason that you can’t notarize your own apps, and any you have resigned, that requires a paid-for subscription as a developer, putting it out of the reach of most. However, in an enterprise it can prove useful.

Launch constraints

Since macOS 13.3 Ventura, a new set of restrictions have been imposed on all apps and command tools provided as part of macOS, in launch constraints. These are rules that must be met for macOS to launch that app or binary, and include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch.

Launch constraints for bundled apps prevent them from being run from anywhere else. If you manage to make a copy of any of those apps, and that’s a challenge in itself, then macOS will prevent you from running that copy. This is made harder to avoid by the fact that these launch constraints are stored in an inaccessible Trust Cache, so the only way you could work round those rules is by turning System Integrity Protection (SIP) off, which in turn reduces Boot Security. That’s explained in more detail here.

Although third-party apps don’t get to use launch constraints or the Trust Cache, some may now have started using environment constraints, which can have similarly restrictive effects. The best way to discover this is using Apparency, which also includes a full guide to the constraints available.

Bundled apps

If you can’t remember which apps are bundled and which are not, look in /System/Applications, as that shows all those in the Signed System Volume, to which you need to add Safari, as that’s sealed in a cryptex.

Sadly, because of all their levels of protection, you can’t customise any of the bundled apps. Even copying them from their read-only SIP-protected location to a folder in your Home folder, which is difficult enough, that copy can’t be run, no matter what you do to it. You can make a Finder alias to the original app and give that a custom icon that will appear in Finder windows. But the app’s original icon will still be displayed everywhere else, including in the Dock, so it’s simply not worth the effort.

If you had ideas that you could replace all Tahoe’s new-style app icons with those from Sequoia, I’m afraid you will be disappointed.

Third-party apps

One customisation you can apply in complete safety is to replace a regular app’s icon. To do that, paste the new icon into the top left of its Get Info dialog, and further information is given here. This doesn’t affect any of the security protection of that app, as the new icon is added as a hidden Icon file at the top level inside the app’s bundle, which isn’t included in its CDHashes.

Any more substantial changes, even to the app’s resources, should break its signature and CDHashes, and macOS won’t like that.

If there’s a really good reason for making a change, and you can justify resigning the app using an insecure ad hoc signature, you could try stripping its current signature, changing the app bundle, then resigning it with an ad hoc signature. There are two cautions, though:

• Any ad hoc signature is inherently insecure, and makes it simple for malicious code to tamper with that app.
• This may break the app’s updating process, and if it doesn’t, any update will undo your customisation.

Before going any further, you’ll need to add Terminal to the list in System Settings > Privacy & Security > App Management, otherwise your commands will be unable to make any changes to the app. Then make a copy of the app you intend to change, so you can readily revert to the original. Once you’ve done that, open Terminal and use the command codesign --remove-signature MyApp.app to strip the existing signature from the app MyApp.app. Note that two hyphens precede the remove-signature verb. When you’ve made your changes, use the command codesign --sign - MyApp.app to sign that app with an ad hoc signature.

Summary

• Apps bundled in macOS from 13.3 onwards can’t be copied and run from elsewhere, preventing all customisation, and can’t be given custom icons.
• Third-party apps can have custom icons applied in the normal way.
• Any internal surgery inside the app bundle will break its notarization and signature, and shouldn’t be attempted.
• If it’s an essential change, you may be able to strip the signature, make the change, and resign with an ad hoc signature.
• Ad hoc signatures are inherently insecure, and should be avoided if at all possible.