Mac standalone codesigning: 2021 update

Dan Nigrin's icon

In what seems like an annual tradition now, it is once again time to wrestle with Apple and figure out the hoops one needs to jump through to properly prepare a standalone for distribution on the Mac platform.

This post is NOT going to be an exhaustive series of steps required - I refer you to many previous posts on this topic, in particular the excellent Cycling 74 summary by @Ben Bracken from Sept 2019: https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization

Since that article was written, it seems that a new requirement is to codesign each and every binary embedded in the app bundle (the --deep flag for codesign does not seem to work as advertised). Folks at Cycling helped me with a script that seems to be working - it signs each and every binary in the bundle. This process seems to be working to allow for distributed apps to successfully run on Catalina (10.15) as well as Big Sur (11.x).

See the Ruby script below, including the places at the top you'll need to modify it, shown IN CAPS. Copy everything between the ===== lines, and save it as a text file named "standalone-codesigning-script.rb":

====================================
require 'open3'

authority = "Developer ID Application: YOUR CERTIFICATE NAME"
entitlements = "PATH/TO/YOUR-APP-NAME.entitlements"
appbundle = "PATH/TO/YOUR-APP-NAME.app"
appname = "YOUR-APP-NAME"
resources = [];
count = 1;

# codesign the stuff in C74 folder
Dir.glob("#{appbundle}/Contents/Resources/C74/**/*.{mxo,dylib,framework,bundle}") do |f|
if !File.symlink?(f)
resources.push(f)
end
end

resources.each do |resource|
puts count.to_s + ": " + resource
cmd = "codesign -s \"#{authority}\" --timestamp --deep -f \"#{resource}\""
stdout, stderr, status = Open3.capture3(cmd)
raise stderr unless status.success?
end

resources.clear

# codesign the stuff in Frameworks folder
Dir.glob("#{appbundle}/Contents/Frameworks/**/*.{mxo,dylib,framework,bundle}") do |f|
if !File.symlink?(f)
resources.push(f)
end
end

resources.each do |resource|
puts count.to_s + ": " + resource
cmd = "codesign -s \"#{authority}\" --timestamp --deep -f \"#{resource}\""
stdout, stderr, status = Open3.capture3(cmd)
raise stderr unless status.success?
end

# codesign the Max executable
cmd = "codesign -f -s \"#{authority}\" --timestamp --deep --options runtime --entitlements \"#{entitlements}\" \"#{appbundle}\""
stdout, stderr, status = Open3.capture3(cmd)
raise stderr unless status.success?
=======================================

To run the script, open the Terminal and run this command:

ruby PATH/TO/standalone-codesigning-script.rb PATH/TO/YOUR-APP-NAME.app

If you get an error saying "resource fork, Finder information, or similar detritus not allowed", then run the following in the Terminal, and then try again:

xattr -cr PATH/TO/YOUR-APP-NAME.app


That should get you a properly signed application, which you should then proceed to notarize and staple, as outlined in the article linked to above.

I hope this is helpful - good luck! Please know I offer no guarantees with this, and also please know I'm not a Ruby wizard - I had a lot of help with the above.

billyanok's icon

Dan, huge time saver!
Thank You,
B

Rob Ramirez's icon

👏  🙌🙏

Iain Duncan's icon

Thanks for posting this!

Dan Nigrin's icon

Thanks everyone. But the real credit goes to the Cycling folks who assisted on this.... I'm just the messenger! :-)

Roman Thilenius's icon


when i remember right, you invested a lot of time in the past to share some procedures.

Dan Nigrin's icon

True - though many of those are now irrelevant/incorrect, thanks to Apple, LOL.

Roman Thilenius's icon


Last Christmas I gave you my heart
But the very next day you gave it away
This year, to save me from tears
I'll give it to someone special

Michael's icon

Hey Dan.

Here we go again with MacOS 12.0.1 Monterey. Codesigning the app breaks Miraweb -- no longer does it output the IP, it outputs "http://none:-1"

I'm experimenting with entitlements, and haven't been able to narrow down what might be needed that wasn't needed in Big Sur.

Figured I'd ask if you had any thoughts or ideas. I know this is pretty esoteric.

Mike

Dan Nigrin's icon

You're right Michael on the esoteric side of things, I'm afraid I have zero experience in codesigning an app that includes Mira. All I can suggest is perusing the various Apple documentation on entitlements; since Mira uses networking protocols, perhaps they've changed and/or tightened up something there?

Also somewhat randomly, I noticed recently that there was a Mira package update, so just be sure you're using the latest...

Sorry couldn't be of more help! Perhaps the Cyclists will chime in if they're on this thread....

Michael's icon

Figured it out Dan. Found the needle in a haystack by removing single strands of hay at a time.

com.apple.security.app-sandbox

That's the culprit. Kills Mira dead.

Now I'm off to see if removing that entitlement will cause any other problems, but I wanted to share this bit of data.

Thanks for the reply!
Mike

Dan Nigrin's icon

If I’m remembering correctly, that entitlement is only necessary if you plan on distributing your app on the Mac App Store.…

billyanok's icon

Yes,
I came across this as well.
B

riotchild's icon
com.apple.security.app-sandbox

kills more than Mira. If your code signing is failing or as was in my case, destroying your app (deleting objects), try removing this from your entitlements.

Thanks Dan and the Cycling 74 team for your work

riotchild's icon

Would anyone mind sharing their entitlements file here? My standalone crashes on an M1 (11.x and 12.x) when I drag an Mp3 onto [playlist~]. The standalone was build on an Intel (11.6.3), wav files work fine, also happens when built on an M1 with 12.x

Source Audio suggested that in may be a privileges (entitlements issue)....

dropped mp3 files onto playlist get converted into aiff and then played using converted file.
Converted files land in max or standalone's cache folder. could it be privileges issue ?

The app needs to play back audio files that a user drags in, save a .txt to wherever the user wants, and import a .txt file from wherever the user wants.

My entitlements file current has:
<key>com.apple.security.automation.apple-events<;/key>
    <true/>
<key>com.apple.security.cs.allow-jit<;/key>
    <true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory<;/key>
    <true/>
<key>com.apple.security.cs.disable-library-validation<;/key>
    <true/>
<key>com.apple.security.device.audio-input<;/key>
    <true/>
<key>com.apple.security.device.camera<;/key>
    <false/>
<key>com.apple.security.get-task-allow<;/key>
    <true/>
<key>com.apple.security.assets.music.read-only<;/key>
    <true/>
<key>com.apple.security.assets.music.read-write<;/key>
    <true/>
<key>com.apple.security.files.user-selected.read-write<;/key>
    <true/>
<key>com.apple.security.cs.allow-dyld-environment-variables<;/key>
    <true/>
<key>com.apple.security.network.client<;/key>
    <true/>

I'm guessing I don't need both
<key>com.apple.security.assets.music.read-write<;/key>
and
<key>com.apple.security.assets.music.read-only<;/key>
?

Thank you.

Shakeeb Alireza's icon

@RIOTCHILD, I have used a python script (based on the ruby script in this post) to codesign/notarize my zipped standalone successfully for 3rd party distribution (i.e. non-app-store distribution). I have extended it a bit since then with some other related features.

In any case, I have used a basic entitlements file to successfully notarize a standalone. It's in the project resources/entitlements folder and includes the following:

"entitlements": { 
"com.apple.security.automation.apple-events": True, 
"com.apple.security.cs.allow-dyld-environment-variables": True,
"com.apple.security.cs.allow-jit": True, 
"com.apple.security.cs.allow-unsigned-executable-memory": True, "com.apple.security.cs.disable-library-validation": True, 
"com.apple.security.device.audio-input": True,
# "com.apple.security.device.microphone": True, 
# "com.apple.security.app-sandbox": True,
}

Note the last two lines are commented out and were not used during code signing/notarization.

Hope this is helpful.

Dan Nigrin's icon

My entitlements file is pretty short. The app in question reads and plays an audio file from disk (but not .mp3). It also writes a preferences file to the standalone's folder in the ~/Library/Application Support/.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-unsigned-executable-memory<;/key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation<;/key>
    <true/>
    <key>com.apple.security.device.audio-input<;/key>
    <true/>
</dict>
</plist>

I think Source Audio has likely identified the root cause of the problem. Perhaps figure out where exactly Max is temporarily storing the converted .mp3 file, and then see if that's in a location you need some special entitlement for? The detailed rundown of the entitlements at the end of this Cycling post has been helpful to me in the past, but not sure if there have been any changes on the Apple side since it was first posted? https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization

Source Audio's icon

I don't use any system higher than HighSierra for work,
and so can't say where Standalones store settings in Monterey & co.
In case of Max itself, path to cache folder is
~/Library/Application Support/Cycling '74/Max 8/Settings/Cache
(user lib)
the thing is - if Standalone crashes before converting file, than
it probably also failed to create Cache folder.

Can one still give full disc access rights to apps in Monterey ?

Dan Nigrin's icon

Can one still give full disc access rights to apps in Monterey ?

Not sure - I took a look here and didn't see anything obvious: https://developer.apple.com/documentation/security/hardened_runtime

joseph larralde's icon

Hello there, I have some noob questions regarding signing of applications.

I'm building a standalone on Catalina Intel machine that targets Big Sur and Monterey M1 machines, and tried every technique I could find on this forum to sign it. Last attempt was using Dan's ruby script.
Unfortunately I only have access to my own computer, and the distant user who is testing my builds with Big Sur and Monterey is reporting the issues to me.
At the moment when building with Max 8.1.11 everything is working well except the max-ble external used in the standalone. It surprinsingly loads fine, seems to perform a scan, but doesn't seem to have the right entitlements to discover BLE devices, that's why I'm trying to sign the whole standalone with bluetooth entitlements (plus the suggested ones). Whenever I sign it, it loads but doesn't display any window except the Max console, which doesn't tell anything.
When building with Max 8.2.2, the standalone says "max-ble : incorrect architecture", so I didn't even try to sign it yet.

So before I update to Big Sur or install a newer XCode to build a universal external (I'm using my own fork of max-ble at the moment), I'd like to know if I need to enroll in Apple's Developer plan to get a proper Developer ID Application certificate (I only have a free Apple Development certificate for now), or if the notarization process (which I didn't try yet) has become somehow mandatory.

Thanks in advance for any insights,
Cheers

Dan Nigrin's icon

My memory is a bit foggy here, but I do think there was a change at some point along the way in how Cycling packages up the externals bundled in a standalone, I think to help with some of the signing stuff. I can't remember when that was though - it may very well have been between versions 8.1 and 8.2. So I'd probably suggest moving forward with building the 64 bit, universal binary of the external, and updating to Max 8.2 to be sure.

Another thing I can't fully remember is what is necessary in terms of certificates. I'm pretty sure that the free certificate is not sufficient to be able to sign and notarize applications, but I could be wrong. I've always used my paid account. I'm sure if you dig into this on the Apple site you can probably figure this one out.

Sorry I couldn't be more helpful!

joseph larralde's icon

Thanks Dan for your prompt reply !

Actually this is very helpful.
I will try to update XCode to 12.4 first, the most recent version I can install on Catalina which allows universal builds, and see how it goes with Max 8.2.2
At some point I guess I'll have to update to Big Sur and get myself a paid account to avoid further issues (couldn't find much info on Apple's site about free accounts limitations yet), but I'm quite in a hurry to get my standalone to work, so your advice sounds like a good strategy.

Also, thanks everyone on this thread for the valuable information I could find here (which unfortunately doesn't help much in my situation at the moment).

I'll report here whenever I make some progress

joseph larralde's icon

Unsurprisingly, still not working at the moment when built with Max 8.2.2 using a universal build of max-ble

this post seems to confirm that a paid account is needed for distribution
Here is the relevant part :

The code you copy from the Xcode archive is typically development-signed:% codesign -d -vv to-be-signed/Daemon

Authority=Apple Development: …

To ship this code, you need to re-sign it for distribution.

I just enrolled in the developer program and installed xcode 12.4, will see how far I can go now before updating to Big Sur

joseph larralde's icon

Still not working on a 2017 M1 macbook runninng latest Big Sur, built from my late 2015 Intel Catalina macbook with a proper "Developer ID Application" certificate ...
Could anyone confirm that the recursive signing procedure with the ruby script is still valid ?

Here is my entitlement file, in case it helps :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.automation.apple-events<;/key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables<;/key>
<true/>
<key>com.apple.security.cs.allow-jit<;/key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory<;/key>
<true/>
<key>com.apple.security.cs.disable-library-validation<;/key>
<true/>
<key>com.apple.security.files.user-selected.read-write<;/key>
<true/>
<key>com.apple.security.device.audio-input<;/key>
<true/>
<key>com.apple.security.device.camera<;/key>
<true/>
<key>com.apple.security.device.bluetooth<;/key>
<true/>
</dict>
</plist>

Maybe I'm missing some important step.
This is getting very tedious without a M1 machine at hand to perform my own tests.
Thanks in advance for any feedback, at this point I'm clueless, I just hope I don't need to buy a new macbook to solve this problem.

Next thing on my list ATM is to try to distribute a collective instead.

Dan Nigrin's icon

Can you clarify exactly what is not working now. Is the signed/notarized/stapled application able to start and run on the M1-user's machine, but just not operate properly? Any messages in the Max console if so?

Also, it's probably worth for your M1-user to check to be sure there are no pending requests in the System Preferences for granting of privileges to your app to do whatever it needs to. I'm not describing it very well, but hopefully you know what I'm alluding to.

Dan Nigrin's icon

And yes, the Ruby script still works for me in my use cases.

joseph larralde's icon

Of course, sorry for not being precise enough.
The app crashes at launch and the log is not very meaningful (see below).
Is the notarization / staple process mandatory ? I just signed the standalone and zipped it with ditto as suggested here before uploading it to my server.
I'll suggest the user to check for privileges, though I'm not sure what privileges should be granted for the use of BLE devices ...
I think I'll try to get a signed version not including max-ble to work first, maybe the crashing is totally unrelated

The relevant log parts seem to be :
...
System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 2 Dispatch queue: com.apple.root.default-qos

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace TCC, Code 0x0
...
Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 ??? 0x00007ffe9494e8f4 ???
1 libsystem_kernel.dylib 0x00007fff2052f56e __abort_with_payload + 10
2 libsystem_kernel.dylib 0x00007fff20530fef abort_with_payload + 9
3 com.apple.TCC 0x00007fff24cf2f72 __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163
4 com.apple.TCC 0x00007fff24cf37a3 __TCCAccessRequest_block_invoke.130 + 498
5 com.apple.TCC 0x00007fff24cf13c8 __tccd_send_message_block_invoke + 573
6 libxpc.dylib 0x00007fff20289a9c _xpc_connection_reply_callout + 36
7 libxpc.dylib 0x00007fff20289a24 _xpc_connection_call_reply_async + 69
8 libdispatch.dylib 0x00007fff20398870 _dispatch_client_callout3 + 8
9 libdispatch.dylib 0x00007fff203b1035 _dispatch_mach_msg_async_reply_invoke + 375
10 libdispatch.dylib 0x00007fff203a851c _dispatch_kevent_worker_thread + 1390
11 libsystem_pthread.dylib 0x00007fff2053f4a5 _pthread_wqthread + 386
12 libsystem_pthread.dylib 0x00007fff2053e42f start_wqthread + 15

Here is the full log :

crash-log.txt
text/plain 97.00 KB

Thanks a lot !

joseph larralde's icon

Here is some more news :
- I made a version without the max-ble external, signed it with the same entitlements, and no crash
- I notarized the version of the app including the max-ble external successfully, but it is still crashing with the same log
So the problem seems to arise from the use of max-ble, as the app is supposed to pass the gatekeeper.
The only reason I can think of right now is that I don't provide the right entitlements during the signing process.
I will try to drop a line to support and see if I can get an answer.

Dan Nigrin's icon

Yeah, it's feeling like this is definitely specific to your Bluetooth-based stuff - unfortunately which I have zero experience with on my end. Sorry and good luck, and please report back....

joseph larralde's icon

No problem :)
Huge thanks for your help, you got me closer to the solution anyway.
I just sent an email to support, will report back here although the answer will probably be a little off-topic ...

joseph larralde's icon

Update : got it to work !
I just needed to add the NSBluetoothAlwaysUsageDescription key to the standalone's Info.plist, and the notarized app finally opened.
[max-ble] was still not discovering devices on Big Sur, so I updated my OS and XCode versions, and checked how a freshly built [max-ble] behaved in Max.
Turns out that the issue was due to a patcher scripting workaround I made to force devices disconnection that was not causing this on Catalina, not sure why but I removed it and now everything seems to work as expected.
A "disconnect" message still needs to be implemented in [max-ble] as a clean alternative to my nasty workaround to get the desired behaviour back, but for now the standalone behaves well enough.
Thanks again for the help, and sorry for the noise
Cheers

Dan Nigrin's icon

That's great, glad you got it sorted out, and thanks for posting the solution here as well!

Ruslan's icon

Thank you Dan for your effort! I successfully signed an app using your script and notarized it. However, when I'm trying to staple it I get error 65:

CloudKit query failed due to "Record not found".
Could not find base64 encoded ticket in response for
The staple and validate action failed! Error 65.

I made it twice once on dmg, created with disk utility and another on .zip (extracting an app before stapling) with this error. I know for stapling to be performed it is needed to use a --deep flag during the codesign procedure. Dan, the script uses this value and no success on stapling.

Besides altool will be deprecated as of fall 2023 and the guide should refer to notarytool.

Does anyone have any success with stapling Max 8.3.3 apps?

Ruslan's icon

Staple works using notarytool!!! But for this you need to create an api key. Here is the usage guide:

notarytool submit file-path
{ -k key-path -d key-id -i issuer | --apple-id
apple-id [--password app-specific-password]
--team-id team-id | -p profile-name [--keychain keychain-path] }
[--wait --no-s3-acceleration]

App Store Connect API Keys

Developer ID team administrators can create App Store Connect API
keys for the developers on their team by logging into
<https://appstoreconnect.apple.com/access/api>; and selecting the
"Keys" tab. For security purposes, the private key can only be
downloaded once.

-k, --key key-path
App Store Connect API key. File system path to the
private key.

-d, --key-id key-id
App Store Connect API Key ID. For most teams this will be
a 10 character alphanumeric string.

-i, --issuer issuer
App Store Connect API Issuer ID. The issuer ID is a UUID
format string.

Then you can run:
xcrun stapler staple -v [path/to/standalone.app]

Dan Nigrin's icon

Thanks for reporting your findings, and congrats on making it all the way through!

fraction's icon

sharing my experience as well. The script above works on monterey 12.6 as well. Thx to everyone at C74 and Dan Nigrin who put that together, extremely usefull. As for the notarize process it's pretty smooth when you have created a developper key with your credentials. Then just use :

% xcrun notarytool submit myapp.pkg --keychain-profile "myprofile" --wait

sign and notarize an app is really a long journey, but it worths it.

Ruslan's icon

2Fraction, strange in my experience there was App Store Api key needed. Glad to see it works without it.

fraction's icon

@ruslan - yes before being able to save your credential, you have to create the specific apple api key and password. But when it's done you can just save those credential. This one was pretty useful for me : https://scriptingosx.com/2021/07/notarize-a-command-line-tool-with-notarytool/

Ruslan's icon

Guys, so what about sandboxing in Max 8.5.3? Would like to upload my app to App Store but know that sandbox must be enabled for this. Codesigning with sandbox enabled gave me an error in the past, should I try it again or there is a native option for this in Max?

Dan Nigrin's icon

There's no "native" solution within Max for this. I haven't tried with a new app in quite a while, so not sure what the current state is - but in the past, I and several others were successful in getting our apps up there.

I'm assuming you've found the threads on the forum that cover this topic? That's probably the best that you will do in terms of advice at this point - and knowing how frequently things change on the Apple side of things, be prepared to have to deal with new issues that might have come up since the last time those threads were updated....

Good luck!

Arvid Tomayko's icon

I’ve got codesigning and notarizing working fine with Max 8.5.3 standalones, but have never tried the App Store.

Ruslan's icon

Dan, I was able to sign the app with sandbox enabled and open it successfully, however one .png image in fpic doesn't loaded. I think this is because of sandbox signing and the fact that this image is in the separate window. It screws the path to it in .mxf for some reason. I was able to upload it to App Store with 39 errors and afterwards I received a notification from mobile AppStore connect that there is a "binary file error". I can try to sell an app via my site but App Store is a huge marketplace and is a great exposure, so I will try my best to let my App in it.

Dan Nigrin's icon

@Ruslan, I would suggest posting in one of the App Store-specific threads, where you’ll find more people with the right experience. I haven’t had your specific problem with fpic’s before so don’t really know what’s up.

Alec Gordon's icon

Hey, I'm sorry to revive this thread, but I've been struggling with the 'audio capture not authorized' error for a while. I'm packaging an application, when unpackaged and launched via a dmg installer the error doesn't appear, only when I launch it as a package.
What exactly do I need to do to run this script? Do I package it into the installer as a post-install script? Has anyone figured out how to get around this particular error?

Dan Nigrin's icon

I'm sorry Alec, I have zero experience with using .pkg's to deploy, I've only ever used .dmg's. That said from my understanding, the steps were the same? You codesign the app just as you otherwise would, and when it comes time to notarize and staple, you just do that with your .pkg instead of the .dmg?

Michael's icon

Hi everyone. 2025 here.

Macbook Pro macOS Sequoia (15.3.1) on an M4 chip.

Codesigning breaks Max now, both Max 8 and Max 9-generated app bundles. I've tried several different script variations to codesign, and after running the codesign script, the app crashes upon launch with an EXC_BAD_ACCESS error

Crashed Thread: 0 JUCE Message Thread Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Exception Codes: UNKNOWN_0x32 at 0x00000001124f7c10

Exception Codes: 0x0000000000000032, 0x00000001124f7c10

Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page

Anyone had any success codesigning an app recently?

Mike

Michael's icon

And another quick troubleshooting update. I was able to codesign with a reduced entitlements list. But, what kills everything is the hardened runtime which is required now. When signing with

--options runtime

i.e.,

codesign --force --deep --verbose --options runtime --sign

The app crashes as above.

Still tinkering but I think I may have hit a wall, since hardened runtime is now required for notarization.

Mike

billyanok's icon

Do you have a patch I could test?

B

Michael's icon

Sure, I can send the full app pre-signed. It should open properly (assuming it lets you open it unnotarized), with a bunch of entitlement requests. Here's the link to the app bundle. Note that without a score file installed, it won't actually do anything.

I can also send the project folder, but there are probably dependencies that will require some code libraries (all available publicly) like Mira, HIRT, etc.

Would that be of interest/help? You can grab the project here

Shane's icon

I've had luck with AppWrapper 4, fwiw.

Michael's icon

You’ve done this recently since os14+?

Dan Nigrin's icon

@Michael - I was able to successfully codesign something as recently as mid-January of this year? I'm not home right now, but from memory I still used the same Ruby script at the beginning of this thread, and my same .entitlements file I've been using for some time.

What did change for me is the notarizing step; for that I needed to pivot to using Apple's altool rather than notarytool which I had been using previously.

Shane's icon

Yes, I've been using AppWrapper 4 to wrap and do initial codesigning, then DropDMG to make (and sign) the DMG, then notarizing with:

xcrun notarytool submit --wait --apple-id [your Apple Developer ID] --password [your app-specific password] --team-id [your team-id] [your filename here]

And then stapling:

xcrun stapler staple [your filename here]

(This is all on macOS 15 Sequoia)

Stuart Smith's icon
Stuart Smith's icon

This is my entitlement file -

<plist version="1.0">

<dict>

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

<true/>

<true/>

<key>com.apple.security.device.usb</key>

<true/>

<true/>

<true/>

<true/>

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

<true/>

<key>com.apple.security.device.microphone</key>

<true/>

<true/>

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

<true/>

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

<true/>

<key>com.apple.security.network.client</key>

<true/>

<key>com.apple.security.device.audio-video-bridging</key>

<true/>

<key>com.apple.security.get-task-allow</key>

<string>YES</string>

<key>com.apple.security.network.server</key>

<true/>

</dict>

</plist>

Michael's icon

Thanks all. I've been notarizing with the ruby script above and it (the app) works fine, but when I add --options runtime to create a "hardened runtime" the app works. It might be some of the externals/libraries I'm using that might be running in emulation. (I wrote the original app on a non-Apple silicon machine.) That said, the app compiles and runs properly on an M4.

@Stuart - I've been using Package Builder (same company as DMG Canvas) to build an installer package before using DMG Canvas. I've got a lot of different things that need to be installed in a specific folder structure, so I need to create an installer package first. When I haven't enabled the hardened runtime (--options runtime) the package won't notarize. When I do enable hardened runtime, it notarizes fine but the app crashes. What do you use to notarize? Dan's script or...?

@Shane - I'll try using AppWrapper. Quick follow-up question: do you also use Dan's ruby script above? (I haven't used AppWrapper, so this might be an obvious answer once I download it)

@Dan - what is the altool?

Thanks again all. Much appreciated.

Shane's icon

Hi Michael,

No, I haven't haven't been using the Ruby script, just AppWrapper. It has lots of options for what needs to be included in Hardened Runtime, etc. I found some info about using it somewhere here in the forums (can't find it right now). In any case, it handles all the codesigning of the standalone, and DropDMG does the same for the dmg.

Good luck,

Shane

Dan Nigrin's icon

@Michael - altool is the “new” notarytool. When i tried to use notarytool in January I got a message saying it was deprecated and that I had to use altool instead.

Stuart Smith's icon

Micheal -

"When I haven't enabled the hardened runtime (--options runtime) the package won't notarize. When I do enable hardened runtime, it notarizes fine but the app crashes. What do you use to notarize? Dan's script or...?"

I codesign with --option runtime and notarize with DMG canvas, works fine as you can see in the download I sent. I codesigned your app not from the project files, is there something else you are adding that is problematic?

S

Michael's icon

Hi @Stuart,

AppWrapper is indeed a really convenient piece of software. I'm still struggling to figure out all of the parameters to set (and as such haven't successfully codesigned the software yet), but that's my ADHD not wanting to read the manual and to dive right in.

What would be super helpful is if you have the saved AppWrapper file you used to successflly codesign my app, and I will just use those settings.

Dude, this may well be the solution, so thank you! (and thanks to everyone here. I appreciate it!)

Michael

Stuart Smith's icon

Hey Micheal,

I'm sorry I never use App Wrapper, I used the Ruby script kindly provided by @DAN NIGRIN.

It's fairly simple to use once configured.

I tried App Wrapper and couldn't get it working but I know quite a few people on have on this forum..

Michael's icon

Sorry Stuart – I got you and @Shane confused w/ one another :)

Dan Nigrin's icon

Just wanted to correct myself in my previous posts - I got things backwards; notarytool is the newer, currently supported notarizing tool, and altool is the deprecated one. See TN3147: Migrating to the latest notarization tool | Apple Developer Documentation

Shane's icon

Hi Michael,

I'm not sure what settings you need in AppWrapper, but I have the following:

I am wrapping for Website Release (not AppStore or Development), and I have "Hardened" and "Entitlements" checked, but not "App Sandbox."

Most of my settings are the defaults. Nothing under Provision Files. Under Capabilities, I have three boxes checked under Hardened Runtime: Allow execution of JIT-Compiled Code, Allow Unsigned Executable Memory, and Disable Library validation. I am not sure if all of these are required, but I arrived here through trial and error. I use v8 to call 2 JS scripts, as well as shell, and these settings seemed to fix some problems I was having with those. YMMV...

Because I am using DropDMG and notarizing and stapling myself, I am not using AppWrapper for packing, and I haven't changed anything under Scripting either.

Hope this helps,

Shane

Michael's icon

Everyone: SUCCESS. I don't know what I was doing wrong, but it's working now. For the record, I used Dan's updated Ruby script (I think I was using an older version initially without knowing it.)

Again, appreciate you all.

Mike

Dan Nigrin's icon

Excellent, glad you got it sorted!

Stuart Smith's icon

Great!

It can be a long haul the first time..