Max 8.1: Mac OS 10.15 Catalina Support and Notarization

As of Max 8.1, we've taken the steps necessary to make Max compatible with Apple's new notarization standards. In our tests, things appear to be working well using Max 8.1 on Mac OS 10.15 beta. Despite these new complexities, Mac standalone developers should be able to distribute their applications if the the new Notarization guidelines are followed.

We understand first-hand how this change in Apple's security policy introduces inconvenience for the developer. We have worked hard to make it possible to build Max standalones that can run under the new Apple security polices, and appreciate any reports and examples where it does not work.

Read more about Apple notarization requirements: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

In order to distribute a Max Standalone application that passes new Gatekeeper checks, these guidelines must be followed. However, Apple has stated that they are delaying some of these requirements until January 2020: https://developer.apple.com/news/?id=09032019a

The runtime application used in Max standalones is built with "Hardened Runtime" enabled, but developers of standalones will need to do the following in order to satisfy Apple's new requirements:

• Have an Apple Developer ID

• Install and make Xcode 10+ your active Xcode installation (use xcode-select if multiple versions are installed). Xcode 11 presumably works as well.

• Code Sign the standalone:

• use the '--force' flag to force re-signing (overwriting Cycling '74 code signing)

• use the '--deep' flag to sign the whole bundle. We have had some reports that this is enough, but other reports that indicate you may have to sign every framework, external object, dylib and any other executable binary that exists in the app bundle. We have found that this is necessary for the Max app itself. We recommend that you start with the --deep flag and see how far that gets you. If you want to try signing every framework, check out the forum post here: https://cycling74.com/forums/mac-standalone-codesigning-2021-update

• use a custom 'entitlements' file while signing, enabling whatever features the standalone may need (camera access, microphone access, etc). See the bottom of this article for an explanation of some of the entitlements we recommend using, and refer to this Apple documentation for even more information: https://developer.apple.com/documentation/bundleresources/entitlements

• Although not explicitly required at the moment, we recommend using the '--timestamp' flag.

• Terminal example: codesign -s [your developer ID] --options runtime --timestamp --force --deep --entitlements [path/to/app.entitlements] -f [path/to/standalone.app]

• Upload your software to the Apple notary service using 'xcrun altool'. We recommend using a DMG or zip to distribute your standalone: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow#3087734

• Terminal example: xcrun altool --notarize-app -f [path/to/standalone.<dmg|zip>] -t osx -u [Apple developer user name] -p [your password] -primary-bundle-id [com.yourcompany.yourapp] --asc-provider [your 'team' name]

• After successful notarization, 'staple' the returned ticket to your standalone using 'xcrun stapler': https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow#3087720

• Note: if you use a .zip file to distribute your standalone, after notarizing, you will need to unzip, then perform the staple on the .app itself, then re-zip.

• Terminal example: xcrun stapler staple -v [path/to/standalone.<dmg|app>]

It currently still is possible to notarize old standalones for use on Catalina by following similar instructions as above: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution#3087722

For those who simply wish to share standalone apps without going through the notarization, un-notarizized applications should be able to bypass Gatekeeper as before (ie right-clicking the app to open).

If you do run into issues, please do not hesitate to drop us a note. We understand how important this option is for those who want to distribute Max patches using the Standalone mechanism. As Apple's requirements change, we fully plan on making the adjustments needed to continue to allow users to do so, if possible.

Addendum - Entitlements

Here is a cheat sheet that might help you determine what may or may not be needed in an Entitlements file. Again, refer to the Apple Developer documentation for more details.

<key>com.apple.security.automation.apple-events</key>
<true/>

This is necessary for triggering apple-events. In addition to any use of third party AppleScript objects, this may be necessary for certain VST/AU plugins and their particular authorization systems (though more info is needed on this point).

<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>

This entitlement allows for using alternate locations for libraries as set by environment variables. This may not be necessary for many standalones, though some may need this for advanced workflows.

<key>com.apple.security.cs.allow-jit</key>
<true/>

This entitlement allows for using JIT compiled code--e.g. CEF, lua, Java, and Javascript objects could make use of this.

<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>

This is a superset which is necessary for many of the above instances, including Gen, which do not specifically use newer JIT specific flags for memory mapping executable pages. 

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

This is necessary to load any 3rd party externals or VST/AU plug-ins that have not been notarized. 

<key>com.apple.security.device.audio-input</key>
<true/>

This is necessary to initialize the audio driver and open audio input.

<key>com.apple.security.device.camera</key>
<true/>

This is necessary to open the camera input.