In OS X 10.6, the open command was enhanced to allow passing of arguments to the application: open./AppName.app -args -AppCommandLineArg But for older versions of Mac OS X, and because app bundles aren't designed to be passed command line arguments, the conventional mechanism is to use Apple Events for files like here for Cocoa apps or here for Carbon apps. Terminal (Terminal.app) is the terminal emulator included in the macOS operating system by Apple. Terminal originated in NeXTSTEP and OPENSTEP, the predecessor operating systems of macOS. As a terminal emulator, the application provides text-based access to the operating system, in contrast to the mostly graphical nature of the user experience of macOS, by providing a command-line interface. Command Line Tools Are indeed shipped with and easily accessible in macOS using the Terminal.app. Since macOS is based (originally) on the Berkeley Standard Distribution Unix (usually called BSD Unix, or just BSD), it comes with (pretty much) the standard suite of Unix command line tools. Typically, command-line programs are launched from a shell (like the bash shell in macOS) embedded in a utility application like Terminal in macOS. For the sake of simplicity and ease of learning, in this tutorial, most of the time you will use Xcode to launch Panagram. When upgrading to MacOS Catalina, Version 10.15. you can install the command line tools for xcode 11.3 like this: $ softwareupdate -list Software Update Tool Finding available software Software Update found the following new or updated software:. Label: Command Line Tools for Xcode-11.3 Title: Command Line Tools for Xcode, Version: 11.3, Size: 224878K, Recommended: YES, $ sudo.

Apple announced that early next year macOS will start highlighting notarization status more prominently. This is great, because currently the difference between Developer ID and notarized Developer ID apps is just a short sentence in a Gatekeeper dialog. Also notarization, which is optional today, will be required by future versions of macOS. The new documentation is very detailed and surprisingly precise about resolving common issues, but does not describe how to automate an asynchronous notarization process.

In this article we will create a Makefile for notarization, as I prefermake to Bash scripts.

Build an archive using a Xcode bot

As an example, I’m going to notarize a NewMacApp introduced in the article about distributing Mac apps. For a more production-like experience, we will use a Xcode bot.

And let’s start with the configuration. Make sure that the Do Not Export Product item is selected in the Archive popup:

To sign the final product, we will use a custom ExportOptions.plist, but from the command line.

In the Signing Options we can disable automatic certificate and profile management by the Xcode Server:

For public distribution, a profile is not necessary, and we will access the certificate directly from the command line.

If you run a new integration now, the bot should create an Xcode archive.

Enable a Hardened Runtime

In order to be notarized, a Mac app must have a Hardened Runtime enabled. Sandboxing is not required (thanks to Matt Massicotte for correction). Jeff Johnson perfectly describes the difference between the two, I highly recommend his article.

So let’s enable both the App Sandbox the Hardened Runtime in the Capabilities tab of our NewMacApp project:

Don’t forget to commit the changes, to make them available by the next integration.

Macos Command Line Tools

Export an archive using a Developer ID

An archive built by our Xcode bot is signed for development, but we need the Mac app signature to include the Developer ID. We can sign the app using xcodebuild -exportArchive which requires a property list with export options. So create a file named ExportOptions.plist in the root project folder:

Please note that we leave an empty certificate UUID and a team ID for the git repository. An up-to-date certificate stored in your Keychain can be accessed using a command line utility named security. Here begins our Makefile. A standard utility named plutil can be used to fill both placeholders:

And now, if the Xcode bot runs a command make notarize from the project folder, the ExportOptions.plist would be filled with the correct UUID and the Team ID necessary for the export:

Macos Command Line Tools Version

Send a zipped Mac app bundle for notarization

Once we have the Mac app signed using our Developer ID certificate, the bundle can be archived as a .zip file and then sent to Apple for notarization using a new command line utility from the Xcode toolchain named altool:

Some notable things from the last script:

We are ‘zipping’ and submitting only the bundle NewMacApp.app, not the whole Xcode archive.
Our dSYM files with debug symbols are not needed, a notarization service expects only the application binary and embedded frameworks or libraries.
The primary bundle ID is like a follow-up number. It does not need to match the application bundle ID and will be included into a notification email.
The altool will generate useful output, and we’re opting-in for XML to generate that output as a property list, more convenient for automation.
Apple ID credentials are needed to upload the app for notarization. We don’t provide them directly however, and instead use environment variables.

Provide credentials using the local Keychain

The altool requires our username and password for authentication. First, let’s define two environment variables in our Xcode bot Arguments panel, the DEVELOPER_USERNAME and the DEVELOPER_PASSWORD:

Note a special prefix @keychain: before the item named XCODE. So second, let’s create a special item with our real password in the Keychain:

If we run a modified Makefile now, the Xcode bot would ask for a permission to access the local Keychain and send our Mac app for notarization.

Wait while the Mac app is notarized by Apple

A property list that we saved above can be used to retrieve an up-to-date information about the submission. In particular, we are interested in the so called Request UUID provided by Apple. The altool is able to fetch the latest status of the upload using this identifier.

We should check the current status of the upload until it changes. Let’s create a helper function in the Makefile:

Macos App Download

In the script above, we look at the reported Status every minute, while its value is equal to in progress. Eventually the status will change, and the function will break. Before stapling the Mac app with a notarization ticket, the upload status should become success:

Finally, our Mac app is checked by Apple and ready for distribution. There is just one more thing — we can attach the notarization ticket to the binary itself, so that it becomes available offline:

Done. The bundle report should look something like this, if you check it using a fantastic tool named RB App Checker Lite:

Conclusion

From my experience, the whole notarization process usually takes 3-5 minutes and does not depend on the bundle size. I uploaded a full version of the Makefileto the GitHub. And you can adopt it for another workflow, if you do not use Xcode bots for continuous distribution for example.

Macos Command Line Apps Windows 10

Notarize your apps, good luck!