Application hanging indefinitely after successful notarization

Hi, I have an app built in Unity that I am trying to sign an notarize for distribution. I can successfully codesign the app and it runs properly. But after successfully notarizing the app, the app stops opening.

My process is as follows:

# codesign the app. omitting "--deep" "--option runtime" or both will result in notarization failing
codesign --force --deep --verify --verbose --option runtime --sign "Developer ID Application: ORG NAME (ZZZZZZZZZ)" path/to/app.app

# create notarization submission zip
/usr/bin/ditto -c -k --keepParent path/to/app.app path/to/app.zip

# submit for notarization
xcrun notarytool submit --wait path/to/app.zip -v --apple-id apple@id.com --password "aaaa-aaaa-aaaa-aaaa" --team-id "ZZZZZZZZZ" 

Notarization seems to succeed. Running:

spctl -a -vvv -t install path/to/app.app

-returns:

path/to/app.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: JOHN DOE (ZZZZZZZZZ)

The Problem:

  • Before code signature, the app runs normally
  • After code signature, the app runs normally
  • After notarization, the app hangs indefinitely on opening. It stays in the Dock until force quit. The app does not create its main window. There are no Gatekeeper warnings or pop-up windows.

Additional Information:

The second time I attempt to open the application I get a pop-up warning me that the app was force-quit while opening windows.

This happens whether or not I have used xcrun stapler to staple the notarization to the app

This happens whether I run the app from the terminal, by double clicking on the .app package, or by running the Unix Executable within Contents/MacOS/

Any idea how I can debug this and figure out what's going wrong? Any help would be greatly appreciated.

Answered by DTS Engineer in 872205022

Notarisation is a read-only process, so notarising an app can’t cause it to stop working.

Usually problems like this are caused by the hardened runtime. Notarisation requires that you enable the hardened runtime, so folks re-sign their app with that enabled and then it fails.

There are two ways you can approach that:

  1. Run the Developer ID-signed build before you notarise it. This should hang in the same way.
  2. Enable the hardened runtime on your day-to-day development builds. This lets you debug this issue like you would any other hang.

Resolving Trusted Execution Problems has a section on debugging hardened runtime issues, namely Resolving Hardened Runtime Incompatibilities.


Oh, one more thing. This is problematic:

codesign --force --deep --verify --verbose --option runtime --sign "Developer ID Application: ORG NAME (ZZZZZZZZZ)" path/to/app.app

To start, you’re supplying both --verify and --sign, which is never a good idea. For any given invocation of codesign, you should do one or the other.

Next, when signing, don’t use --deep. See --deep Considered Harmful for an explanation as to why that’s problematic.

Note It’s find to use --deep when verifying, which is one of the reasons that doing both operations in the same codesign invocation is problematic.

For detailed advice on how to sign and package Mac code outside of Xcode, see:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Notarisation is a read-only process, so notarising an app can’t cause it to stop working.

Usually problems like this are caused by the hardened runtime. Notarisation requires that you enable the hardened runtime, so folks re-sign their app with that enabled and then it fails.

There are two ways you can approach that:

  1. Run the Developer ID-signed build before you notarise it. This should hang in the same way.
  2. Enable the hardened runtime on your day-to-day development builds. This lets you debug this issue like you would any other hang.

Resolving Trusted Execution Problems has a section on debugging hardened runtime issues, namely Resolving Hardened Runtime Incompatibilities.


Oh, one more thing. This is problematic:

codesign --force --deep --verify --verbose --option runtime --sign "Developer ID Application: ORG NAME (ZZZZZZZZZ)" path/to/app.app

To start, you’re supplying both --verify and --sign, which is never a good idea. For any given invocation of codesign, you should do one or the other.

Next, when signing, don’t use --deep. See --deep Considered Harmful for an explanation as to why that’s problematic.

Note It’s find to use --deep when verifying, which is one of the reasons that doing both operations in the same codesign invocation is problematic.

For detailed advice on how to sign and package Mac code outside of Xcode, see:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Application hanging indefinitely after successful notarization
 
 
Q