How to codesign and notarise your app for macOS 10.14 and higher

I took the liberty to create a new thread. The other thread was becoming too large. :slight_smile:
Travis Hicks and Björn Eiríksson shared some code how to codesigned and notarise your apps. Björns way doesn’t work (correct) for me. With the code of Travis and some changes, I got it working every time. Even when you have helper apps in the resources.
So for now, until Sam updates his wonderfull AppWrapper, you can use the following steps.

Codesigning on Mojave gives an error in most cases: “resource fork, Finder information, or similar detritus not allowed”
To fix this, you first need to clear the attributes:

xattr -rc </Path/to/>

Now you can code sign your .app, including making it ready for notarising.
Of course this does not include entitlements and other stuff. It’s just the basic way to codesign.

codesign --force --options runtime --deep --sign "Developer ID Application: <DeveloperIDNameHere>” </Path/to/>

Now create a .DMG file including the .app file and code sign the .DMG file. I use DMG Canvas for this. It’s one of the best in its class. Make sure the option to codesign the .dmg is enabled.

Now we are going to request a RequestUUID number. It will upload the .DMG file and do some magic stuff. This can take a while so be patient.

xcrun altool -t osx -f </Path/to/your.dmg> --primary-bundle-id <APPBUNDLEID>  --notarize-app --username <DeveloperIDNameHere>

After this is finished, you will see the requested UUID. It looks something like 5ecb3409-c20e-2fe5-5672-ebe6ff85c7

It’s time to notarize everything with the returned UUID.

xcrun altool --notarization-info <RequestUUID> -u <DeveloperIDNameHere> -p @keychain:"Application Loader: <DeveloperIDNameHere>"

If you leave out the -p @keychain:"Application Loader: <DeveloperIDNameHere>" it will ask you for your AppleID password.

Now you will see a log::

No errors getting notarization info.
RequestUUID: 5ecb3409-c20e-2fe5-5672-ebe6ff85c7
Date: 2018-10-20 14:07:30 +0000
Status: success
Status Code: 0
Status Message: Package Approved

Last step, we need to staple the .DMG file.

xcrun stapler staple -v </Path/to/your.dmg>

You will see a long log but it should end with:
… The staple and validate action worked!

Congratulations … your app has now been codesigned and notarised.

After you installed the app (from the .dmg) you can double check if everything is working:

spctl -a -v </Path/to/>

Added note:
After your app has been successfully notarised, you will also receive a mail from Apple:

[code]Dear Sir,

Your Mac software (bundle identifier ) has been notarized. You can now export this software and distribute it directly to users.

For details on exporting a notarized app, visit Xcode Help.

Best Regards,
Apple Developer Relations[/code]

Any thoughts on the use of the “–deep” option? See Technical Note TN2206: macOS Code Signing In Depth which says

however that document itself is out of date - perhaps it’s been un-(un-recommended?)

[quote=410724:@Michael Diehr]Any thoughts on the use of the “–deep” option? See which says

however that document itself is out of date - perhaps it’s been un-(un-recommended?)[/quote]

It will recursively search for all files to codesign (for example if you have helper apps in the Resource folder). Of course you could codesign the individual files first but using the --deep is doing the same.
As far as I know, AppWrapper does the same. Sam?

I received the email announcement from Apple the other day like everyone else. Thanks very much for the instructions but I’m confused by the DMG (.dmg) part. For MAS we don’t use a disk image, we use a package (unless I missed something, or maybe I just entered the Twilight Zone). I stopped using disk image installers when MAS became a thing.

You don’t need to worry about this for MAS.

Yes, I know. Sorry I wasn’t clear. What I meant is that I changed all my installers to packages. I use similar AppleScripts to prepare all my Mac installers. Just the code-signing gets done with one certificate or the other depending on if it the version for the MAS or the one for distribution through my website. So I don’t want to change it back to a disk-image because packages are a much easier way to distribute. It can’t possibly be the case that this new notarizing nonsense doesn’t work for packages?

When I try to use altool in Terminal, I get this error

xcrun: error: unable to find utility “altool”, not a developer tool or in PATH

How do I install it (macOS 10.14)?

Do you have XCode 10 and it’s command line tools installed?

You can use .pkg files instead of .dmg files.
.zip files do not work.

Today I tried to codesign+notarize my main apps. But when code signing with --options runtime and run the apps, I get the following error:

An exception of class
FunctionNotFoundException was not
handled. The application must shut down.

Any ideas were to look? Remember, it only happens when code signing with –options runtime

Update: this is very probably a declare that is pointing to a function not available when your app is notarised.
My apps use a lot of declares so I need to find which one … OMG …

With the full stack trace of the error you should probably be able to find easily.
Please post which function it was when you find it :slight_smile:

In the meantime I found the issue.
You can not use libobjc.a.dylib anymore. I replaced it with Cocoa and everything is alright now.
So it seems notificated apps are more piccy in making a declare. They probably cannot be link to a .dylib directly.

@Beatrix Willius No, I was using 9.1. I’m downloading 10.1 beta now. Thanks.

I’ve installed 10.1 beta 3 and its tools installed, as well as Command_Line_Tools_macOS_10.13_for_Xcode_10.1_Beta_3, but get the same error message when I use

xcrun altool…

in Terminal. I do see a file altool buried deep in Application Loader, but that’s no help.

What am I doing wrong (or have yet to install)?

Have you run XcodeX, agreed to the terms and conditions and let it install it’s stuff?

@Sam Rowlands - I use your awesome AppWrapper for one of the steps of my distribution, then DMG Canvas to create the .dmg I ultimately distribute. As I understand the above, some changes will need to be made to AppWrapper to prepare the resulting application to be notarized, and I’ll have to do additional work to the .dmg after it has been created to actually notarize the darn thing.

Do I have this correct? I assume you are planning to update AppWrapper with the necessary changes - I’m just curious if you have any sort of timeline on that yet? Thanks!

@Kimball Larsen I have been looking into the process over the weekend.

I’ve broken it down to two steps.

  • Harden the runtime; I can send you a test version with this option enabled, I still need to verify that the runtime is hardened and update my App Diagnostics to detect non-hardened runtimes. I also need to impliment an interface change to let existing customers not running macOS 10.13.6 and/or who dont have Xcode X installed that it’s required.

  • Notorization; once App Wrapper has completed (make sure you use DMG Canvas integration to simplify matters), there will be a notorize button on the wrapping window. Its an optional step because it’s slow and should only be done when you’re sure this is the build for public consumption.

Step 1; should be completed and into a public beta this week.

Step 2; I have no schedule yet as I haven’t finished the first stage.

I’m kinda frustrated because App Wrapper 3.9 was just about to end its beta testing phaze and go live, now its back into beta again. I took a long time beta testing v3.9, because it’s the first 64-Bit version of App Wrapper.

Just to clear up a detail here, App Wrapper uses it’s own recursive engine to find all Mach-O executable files and code sign them in order (yeah, it must be done in an order or it will fail). It also code signs additional files in executable only locations, Apple have warned that non-executable files should NOT be in executable locations, so expect that hammer to come down at some point.

I had to build my own engine as I found a couple of situations where the --deep option wouldn’t do it correctly and the resulting application would fail to be signed.

p.s. I’ve just discovered how to verify if an application has been hardened, so that’s another thing checked off my list.

Probably a lot or going to kick me but you should do this:

  • release 3.9 64bit as a new release/update now.
  • release 4.0 with the notarising option. Ask an upgrade fee for your hard work. As I said somewhere else, do not give away you software. :wink:

Not going to kick you, .

I will include this in the current beta phase as I’ve already started, that and v4 is miles away. V3.8 uses part of the engine I’ve written for v4, but due to changes and limitations, I need to create a v5 engine, that and it needs an interface overhaul.