Apple notarizing for Mojave (10.14) and beyond
Please post more than that - the full crashed thread.
P.S. - Know that I personally probably won't be of much help, but it might give the Cycling folks a bit more info.
Report file:
https://www.dropbox.com/s/myi2mhagvvu12r6/Liveloopreport.pages?dl=0
31 thread that cause the crashing:
Thread 31 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_kernel.dylib 0x00007fff65a79bea __abort_with_payload + 10
1 libsystem_kernel.dylib 0x00007fff65a7b4f3 abort_with_payload_wrapper_internal + 80
2 libsystem_kernel.dylib 0x00007fff65a7b525 abort_with_payload + 9
3 com.apple.TCC 0x00007fff5dbcd5a7 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163
4 com.apple.TCC 0x00007fff5dbcb545 __TCCAccessRequest_block_invoke.114 + 500
5 com.apple.TCC 0x00007fff5dbcba6c __tccd_send_message_block_invoke + 231
6 libxpc.dylib 0x00007fff65b5fa08 _xpc_connection_reply_callout + 36
7 libxpc.dylib 0x00007fff65b5f990 _xpc_connection_call_reply_async + 69
8 libdispatch.dylib 0x00007fff658c0578 _dispatch_client_callout3 + 8
9 libdispatch.dylib 0x00007fff658d7080 _dispatch_mach_msg_async_reply_invoke + 369
10 libdispatch.dylib 0x00007fff658cf48c _dispatch_kevent_worker_thread + 1324
11 libsystem_pthread.dylib 0x00007fff65b1a744 _pthread_wqthread + 362
12 libsystem_pthread.dylib 0x00007fff65b19827 start_wqthread + 15
Thanks for that - hopefully someone from Cycling (or otherwise!) will come to the rescue. Obviously my eyes are drawn to "Crashing Due To Privacy Violation"....
This looks like your app is trying to access somewhere or something that it doesn't have permissions to. What kinds of things does your app do? What entitlements are you using?
My app access to microphone permission when it launches, I'm pretty sure that's the problem. I codesigned with the permissions for mic
com.apple.security.device.microphone
com.apple.security.device.audio-input
I also noticed and I mention in a previous post in this thread, that I had to sign all the .mxo and it worked on one computer but it does not work anymore. I was wondering if I have to code sign also all the info.plist from all the .mxo or if I should add the entitlements on the info.plist of the app info.plist
I wonder if Max is aggressively asking for access to the camera. What happens when you add com.apple.security.device.camera permissions to your entitlements?
I would also recommend using these:com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
There may be some extensions that are loaded on startup (javascript, gen, etc) that require this. Alternately, you could remove any of these from the standalone if you aren't using them.
I'd probably err on asking for too many permissions, especially if you don't have a super slim standalone. Again, the basics of what we recommend trying in the entitlements department are here (at the bottom, Addendum):
https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization/
All the entitlements I have:
com.apple.security.device.microphone
com.apple.security.cs.disable-library-validation
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.automation.apple-events
com.apple.security.device.audio-input
com.apple.security.device.usb
com.apple.security.files.user-selected.read-write
And I'm adding now camera which I don't need. But... Seriously Max would aggressively ask for the camera? I'll check that then.
Dan, thanks so much for your support and everything you've done. I've been able to successfully codesign and I can confirm that adding the --deep flag without --options runtime fixes the missing objects issue.
However, I haven't been able to notarize. My log contains multiple entries for the following errors:
-"The binary is not signed with a valid Developer ID certificate."
-"The signature does not include a secure timestamp."
-"The executable does not have the hardened runtime enabled."
The first thing I should clarify is that I'm still on High Sierra (10.13.6).
If that's the issue, I'll upgrade, but wanted to see if I'm missing something else before I do.
Joel, you must include the --options runtime flag; that's what enables hardened runtime status, which is required for notarization.
I'm not positive re: 10.13, but I don't think that should matter.
My best suggestion is to follow Ben Bracken's/Cycling's Notarization post linked above in Ben's last message. When followed exactly, it has yielded good results for me and several other people. When it comes to which entitlements to include in your entitlements file, the best strategy is to include more than required at first, and see if your app runs correctly. At that point, you can begin to successively try to remove ones you don't think you need, and keep retesting in-between.
Ah ok - so getting the entitlements correct is the real fix to the quick fix of omitting --options runtime?
For sure - whether it's the only thing I can't say, but it's a definite requirement, so I'd start there!
I'm getting an "unknown exception" error in the terminal when I include the entitlements command. I'm not sure what's going on - is it because something in that file is parsed incorrectly? (I started by just copying in all the strings from Ben Bracken's post above.) Or is the .entitlements file something I have to get from Apple?
Would love to look at an example .entitlements file if someone has one and is willing to share!
Here's one I have been using for a recent project, and which resulted in a successful notarization and utilization on Catalina:
<?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>
Thanks! Got the command to run successfully but I'm stumped - still won't notarize.
Got multiple entries in the log with the error (but only this error, so I guess that's progress):
"The binary is not signed with a valid Developer ID certificate."
Maybe I do have to be on Mojave or Catalina?
I'm starting to think I don't have the first command right. I'm using:
codesign -s "Apple Development: Joel Corelitz"
because it matches what's in my keychain.
codesign -s “Developer ID Application: Joel Corelitz” , which is what I see in all the step-by-step guides,
has always given me:
“Developer: no identity found
And I realize this is a basic question I'm not sure exactly what to put in quotes.
I'm an admin on a company account. I've tried the company name too but anything following "Developer ID Application: gives me the same error.
Yes, that means you're not pointing to the correct certificate. Open up the Keychain Access app (it's in Applications/Utilities), click on My Certificates in the left hand pain under Category, and if you don't see "Developer ID Application: YOUR NAME", then you don't have the correct certificate installed. If it is there, then be sure it doesn't have a little red "x" on its icon, and that it has not expired.
That's it - it's the wrong certificate. Looks like creating that kind of certificate isn't allowed as admin.
Maybe I need account holder access?
Thanks again - this week has been quite a crash course and I'm really grateful for this thread!
Have you gone through the process at this URL, to get your "Developer ID Application" certificate? https://developer.apple.com/account/resources/certificates/list
The "Learn More" links as you go through that process are helpful to walk you through the process. For example, the first one points you to this link, which is how you get started:
https://help.apple.com/developer-account/#/devbfa00fef7
I did but turns out I got the wrong one.
But now I have a valid Developer ID Application certificate from the company and I still get this in the Terminal:
“Developer: no identity found
...which is what initially prompted me to try using the other certificate. Totally stumped at this point.
Can you post:
* the full command you are using to codesign
* the full contents of your entitlements file
* the exact name of your Developer ID Application certificate, as seen in Keychain Access. For example, mine is called "Developer ID Application: Daniel Nigrin"
Sure -
codesign -s “Developer ID Application: We Are Listen, LLC ” --options runtime --timestamp --force --deep --entitlements /Users/joel/Desktop/test.entitlements -f /Users/joel/Desktop/Virgin_Terminal_Generative_V1l_test.app
This returns the error: “Developer: no identity found
when the exact same command is used with:
"Apple Development: Joel Corelitz" it runs fine and returns "Replacing Existing Signature", so I don't think it's the contents of my entitlements file or anything like that.
I should add that *anything* with "Developer:" returns the same error in terminal so it seems like more of a Terminal error than anything.
Two things to note about your certificate specification in your codesign command:
* You have a space after LLC and before the "
* I'm not sure if commas are allowed?
That was my mistake - probably the result of banging my head against this and trying with without commas, putting my name in, everything I can think of. But I get the same result even without the space. Seems like anything containing "Developer isn't working.
Can you send a screenshot of the line in your Keychain Access app, in the MyCertificates section, that shows your Developer ID Application certificate?
I was just able to successfully notarize. Finally figured out the issue. For some reason, copying & pasting the codesign command from the Notepad was causing errors in the Terminal. I manually typed in the same command, character-for-character, and it was successful.
Sometimes the dashes get converted into "fancy dashes" or something like that. Either way, glad you were successful!
Me too!
So - is there any definitive solution to the missing objects issue? I'm having that issue on Catalina but not Mojave. My patch is all factory objects and 2 simple abstractions, but the app is missing a lot more than those
Here's what I've tried (with no success), based on what I've read on this thread -
-Skipping the stapling step
-Signing, notarizing a DMG, stapling, then signing again without the --options runtime flags but then not notarizing the DMG and sharing that.
Here's a screenshot of my entitlements file.
For me, following the steps at https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization/ works - no problem with missing objects. It's highly unlikely that skipping or changing any of those steps will be met with success.
If you have any question about whether you are using the right entitlements or not, try building a simple test standalone with just a handful of objects in it, and sign with the minimal set of entitlements you've got above. Then see if that works. If not, it means that something else in the sequence of steps is not going correctly.
ok - I've been following the steps on that post too. It must be an entitlements issue. I'm only skipping steps to troubleshoot based on some (older) posts in this thread that suggested notarization and --options runtime were breaking the app, but it seems like maybe that's cleared up now.
Yes, remember that this thread goes back to 2018, so not all info is up to date...
I'd highly recommend just building a simple test app with very little in it, e.g. a comment, standalone object, maybe a dial or number box or umenu kind of thing - and try with that.
New problem:
Ok, so I had successfully signed and notarized a version of my standalone on January 4th. I have made a new version that I am now trying to do the same thing. As far as I know, I am using the same steps, and I have not made any significant changes to my patch that would change anything in terms of entitlements etc. Now, my notarization is being declined!! I know Apple has been announcing some policy changes..... is it possible the policy changes are responsible for this? I also just now tried signing/notarizing a copy of the standalone that was originally successful and that has also been just denied. The rejection letter talks about checking a log for trouble shooting, but can't figure out how to do this in terminal. Any thoughts?
I've written this issue before but I got no answer and I have not found the fix yet. When I turn on the DSP (should ask mic permission but it does not), max crashes:
Report file: https://www.dropbox.com/s/myi2mhagvvu12r6/Liveloopreport.pages?dl=0
31 thread that cause the crashing: Thread 31 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_kernel.dylib 0x00007fff65a79bea __abort_with_payload + 10 1 libsystem_kernel.dylib 0x00007fff65a7b4f3 abort_with_payload_wrapper_internal + 80 2 libsystem_kernel.dylib 0x00007fff65a7b525 abort_with_payload + 9 3 com.apple.TCC 0x00007fff5dbcd5a7 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163
THE STEPS I DID:
I succesfully code signed my app
codesign --options runtime --timestamp -f --entitlements /Path/To/Entitlements.plist -s "Developer ID Application: myname (xxxxxxxx)" filepath
with the following entitlements:
com.apple.security.device.microphone
com.apple.security.cs.disable-library-validation
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.automation.apple-events
com.apple.security.device.audio-input
com.apple.security.device.usb
com.apple.security.files.user-selected.read-writeand notarize
I tried with deep and no deep and I read the documentation of Apple which says the following:
"Important: While you use the --deep option for verification to mimic what Gatekeeper does, it is not recommended for signing. During signing, if you have nested code, and if you are signing manually, you sign nested code in stages (as Xcode does automatically), starting with the most deeply embedded components first. You then sign code at the next level of hierarchy, and so on. You work your way outward, finally signing the top level entity that contains all the others. Signing all the components in one shot with --deep is for emergency repairs and temporary adjustments only. Note that signing with the combination --deep --force will forcibly re-sign all code in a bundle"
I did lots of tests and I realized that code signing the .app with --deep flag is not enough. After notarizing was declined, I got the link with all the issues and I figure out that all the .mxo needed to be notarized and also the following files:
sqlite3_darwin-x64.node
MSPReWireDevice
Also code signing files separately needs to be from the inside out. So I first code sign the .mxo files, then the two files I mention before and the end the app with all the entitlements mention before.
I also tried adding com.apple.security.app-sandbox for the .mxo as I have a hint that the problem might be from there. When I add this entitlement in the app, it won't open.
I'm really stuck here and I don't know what else to try.
Do you all have access to the mic but just codesign the .app?
@Ssingh - from an earlier post of mine in this thread, here's what has changed with signing/notarization post Feb 3, 2020:
"Re: what is the difference pre/post Feb 3, see this Apple post: https://developer.apple.com/news/?id=12232019a , in particular the link within it, which points here: https://developer.apple.com/news/?id=09032019a "
And @SSingh, re: checking the log, see my 2nd post on the first page of this thread.
@Josep - I've also read that Apple document about not using --deep as we do, but honestly it has never caused me any trouble at all.
What does still seem a bit "off" to me is the number of entitlements you have. You have many that I don't think are applicable to the hardened runtime use case, and rather for the Mac App Store, if memory serves. I'd recommend not including any entitlements that you don't see listed on the bottom of Cycling's post at https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization/ , and see if that fixes things.
Finally, re: MSPReWireDevice - are you using ReWire in your app? I usually recommend stripping a standalone of unneeded elements, so if you're not using ReWire, you can get rid of that one... This topic is beyond the scope of this thread though...
@Dan,
I've limited the entitlements to the ones on the post you mention but I'm having the same issue. I was wondering if you can notarize the app without signing the .mxo.
I successfully notarize without signing any individual .mxo's - just the main app, again as outlined at the Cycling link I mentioned above.
Sorry I've not been able to get you to the finish line, but at this point, I think I'm running out of ideas for you to try... Perhaps others have suggestions?
I'm still stumped on the missing objects issue. Entitlements seem fine. I have read posts from Cycling that seem to suggest that Hardened Runtime breaks the app and causes the missing objects issue, but since it can't notarize any other way (or be opened any other way in Catalina), it isn't a step it seems like anyone can skip. Is there a possibility it could have something to do with sharing on Dropbox? I've successfully signed, notarized and stapled a test standalone app that runs everywhere but Catalina, where it looks like this:
Here's a link to an example that includes the patch, build script and entitlements file:
https://www.dropbox.com/sh/urzp8ty18wxls7p/AAC1upDbe_B7yrAXILqsNXqka?dl=0
And here's the signed, notarized and stapled .dmg:
Be sure to have the maxzlib.mxo and the sqlite.mxo in the C74 folder inside the resources folder inside your standalone bundle.
Externals can be minimized if for example you're not using some devices. Init has to be untouched, Interfaces can be minimized. Other folders depends on your preferences settings in the standalone obj. Empty folders can be removed. Maxzlib.mxo avoids the gui loss.
I haven't removed anything - they're in there:
@Joel - a few things I noticed and that you could try. I'm not in front of a Catalina machine at the moment (it works fine on 10.13), but assuming that it would fail for me there too:
* Dropbox could potentially be doing something - not necessarily to download your DMG from there, but if you keep your app on there as you are signing it, it might be interfering. If you're not already, try building your app to your Desktop, and then sign, notarize, staple, DMG-ize, etc... to your Desktop as well, and *then* move the final DMG to Dropbox.
* In your screenshot, it looks like you're running the app from the mounted DMG image. Try dragging the app to your Desktop, or perhaps even your Applications folder. Just wondering if in Catalina there might be new restrictions on running the app from a virtualized image or something.
* I noticed in your standalone object that you don't include the Max database - I usually leave this checked. Longshot, but worth a try. I double checked in my projects and I *don't* have this option checked. So cross this one off your list of things to try...
Pulling out my hair here.... hours of time going down the drain... checking my notarization log, and it is saying "The binary is not signed with a valid Developer ID certificate." or "The binary is not signed."...... I'm following instructions exactly, I've checked both my keychain access and my apple developer account, everything looks good. Running "codesign -vvv --deep --strict" tells me everything looks good! I checked the notarization log of my previous standalone which was approved back in January, and I was actually getting all the same messages, the only difference being that in January, instead of it being an "error", it was a "warning". So somehow I was able notarize and distribute an app that was signed with an invalid Developer ID, and my users were able to open it? Something is strange here..... do I need to talk get in touch with Apple technical support at this point?
@Ssingh, can you post your full current codesign command?
Ok, turns out part of my problem was addressed already above, I had the wrong developer certificate (needed to get the one starting in Developer ID Application). So that took care of some of the errors. But it is still rejecting my app I because the .mxo's are not getting signed. Here is what I am using:
codesign -s "Developer ID Application: My Name" --options runtime --timestamp --force --deep --entitlements "path_to_entitlements" -f "path_to_app"
You said you have not needed to sign them individually.... is there something I am doing wrong?
That codesign command seems good to me.
Grasping at straws here, but in your standalone object, do you have "Include C74 Resources" option checked? If so, try unchecking it, and trying the process again...
It is unchecked.... only option I see is to delete all the unnecessary .mxo's and manually sign the ones I need, but this would be quite frustrating because I am doing beta testing, which means I have to make regular updates, a lot of work every time I want to get a new beta to my testers. Other people here seem to be getting by without doing extra signing of the mxo's, is that because they don't need to be signed, or is it because the "deep" is not working for me as it is for others?
I'm honestly not sure at this point. Again, perhaps others have ideas...
Just a note here regarding Apple's tightening of their requirements. We now have to sign every external object, framework, dylib, etc (basically any executable binary) in the Max app, so you may have to do the same.
Ok, deleted most of the mxo's (kept the same as keepsound's screenshot above), manually signed the ones that were left, plus also had to manually sign executable in the MacOS folder....... and.... success!! Finally! It seems other people around here are having success (post feb 3) without signing the mxo's.... if this is true, how is it possible?
Wow, OK that's good to know. I apologize if I may have been confusing the picture - whereas I *thought* I had been successfully signing with a single codesign command and --deep post February 3, I just checked, and the last one I released was in fact earlier than that (January 3 actually).
All that said, what a royal PITA all that signing! Maybe some smart person (or Cycling! :-) ) can develop a script or something?
PITA indeed! But not sooooo bad once deleting the extra undeed mxo's. I just had to do 7 separate manual signings. But, the problem, as I said before, is beta testing. I can't so easily just send updates, quite a lot of hoops to jump through. Also, I have been using QuickLicense/AddLicense to protect my software (couple years went into this app!!), and that is no longer getting past notarization. I have emailed the company, hopefully they can resolve, which I think involves them just adding hardened runtime to their code sign feature (couldn't have success myself manually doing it). Thank you for all your help, Dan..... I spent quite a lot of hours figuring this out, but it would have been waaaaaaay more hours without your help.
An update on missing objects, which are no longer missing:
I was building / signing / notarizing / stapling on the desktop and then transferring to Dropbox to share the .DMG. So Dropbox doesn't seem to be contributing to this issue, at least for sharing.
Dragging the app off the .dmg solved the problem. Looks like Catalina does have restrictions on the virtualized disk. So in the end, it was pretty simple!
Grateful for this thread, and Dan or your help!
That's great, another mystery solved!
SSingh I was wondering if Quick License ever got past notarization ?
I couldn't get it to work..... but strangely....... ClickInstall CAN get something wrapped with QuickLicense/AddLicense past notarization. And I have no idea why because it seems somehow they are doing it without hardened runtime (the hardened runtime option actually didn't work!). I tried to get their tech support to explain to me just how that was possible, but the guy didn't know. Quite a mystery. I didn't purchase ClickInstall yet, but I did try it with their 10 day trial. Going into another round of development now, might have to buy it later, unfortunately its is very expensive.
Yeah it is expensive I have QuickLicense and I was worried about new OS blocking it. I guess the only way is to buy click install dang it. I am interested in getting this to work I am trying to redo some Max apps that are 32 bit up to 64bit and I noticed this advisory about Catalina. I feel like I spend more time doing this kind of stuff then actual development. Let us know how it goes I still am worried about even upgrading to Catalina I am still on Sierra with Max 7 and QL8. Looks like I need QL9 Max 8 Catalina and Click Install to actually distribute anything. I wish I could just use Max 7 and QL8 somehow..
I wish they would just update QuickLicense so that it would work, but who knows when that will happen! Maybe it couldn't hurt to write to them and bug them about it. The more pressure they get the more likely they would be to change.
Hey @SSINGH, @DAVIDSON AUDIO & MULTIMEDIA,
Have you successfully used Quicklicense for app use in Catalina? I'm a long time user of Quicklicense but can forsee issues with Catalina? So Click Install does work?
Thx, B
ClickLicense "appears" to work, somehow by some strange magic they get it through notarization without hardened runtime enabled. But I still wasn't able to get users to install without bypassing gatekeeper. QuickLicense works fine, but also not able to notarize. Of course users can bypass gatekeeper, but I was running into problems with users whose computers belonged to universities/schools etc and they couldn't authorize the program by themselves.
Hey SSINGH, Thx for the reply.
My install needs to as painless as possible!
I can get my app codesigned and notarized with runtime enabled using a DMG but I'n not sure how this will work with Quicklicense? Click Install can do the notarising if I'm not mistaken?
Hi,
I used to notarize my Max app very successfully using this command in terminal:
xcrun altool --notarize-app --primary-bundle-id com.mycompany.mycompany -u my@email.com -p xxxx-xxxx-xxxx-xxxx -f PATH
But when I try to do it now I get this error:
NSLocalizedDescription = "Unable to upload your app for notarization.";
NSLocalizedFailureReason = "--notarize-app is missing one or more required options: --asc-provider.";
In addition I get this warning:
Warning: altool has been deprecated and, starting in fall 2023, will no longer be supported by the Apple notary service. You should start using notarytool to notarize your software.
So I'm trying to learn how to notarize my max app using notarytool but I have no information how to do it.
Have you already tried notarytool?
Thank you
Ugh - I've not had to notarize anything recently, so I have not yet encountered anything like this... Looks like you are blazing new trails - please report back on what you find!
Than you Dan for your reply. Yes, it seems I'm the first one in the max community.
I found this page but I still have some doubts:
https://scriptingosx.com/2021/07/notarize-a-command-line-tool-with-notarytool/
I'm stuck now in the --keychain-profile "notary-scriptingosx" , do you know what's that?
Notarizing the Installer Package
Now we get to the new, most interesting part. We will notarize the newly-created installer package with notarytool:
% xcrun notarytool submit hello-1.0.pkg \
--keychain-profile "notary-scriptingosx" \
--waitThis is amazingly less effort than what we needed to do previously with the altoo command. We give the filename of the archive we want to submit, the keychain profile with our credentials, and the --wait option.
notarytool will upload the file, give us a submission id, and then wait for the returned status from the Notary service. You can follow the output for the details.
You will also notice that notarytool uploads the pkg much faster than the previous altool workflow.
Thanks for all that info, it will certainly come in handy! It seems from that site that they're not only reviewing the new notarizing approach, but also attempting to script all the steps together, which I would imagine would not be mandatory....
I will keep my research and I'll keep you posted. Please if you have some time please have a look at the document, I believe you are more advance than me so you might find out faster the solution following the resources I provided.
Thanks and looking forward!
This is also iteresting:
https://keith.github.io/xcode-man-pages/notarytool.1.html
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]
But I don't know what's team id neither profile name, any thoughts?
I usually look directly at the Apple documentation - this seems to cover it: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow#:~:text=Upload%20your%20app%20to%20the%20notarization%20service
And creating the Keychain profile seems like it was covered in the first link you provided. Team ID location is covered in that link as well.
Yeah! I managed to do it. So first I had to store credentials:
xcrun notarytool store-credentials --apple-id "name@example.com" --team-id "ABCD123456"
And then this is the command for submission:
xcrun notarytool submit --keychain-profile "PROFILENAME" --wait PATH
Then Staple as always:
xcrun stapler staple PATH
And verification:
spctl --assess -vv --type install PATH
I hope this information is useful for all of you!
Josep
Developer of www.liveloop.live
Awesome, congratulations and thanks for reporting back!
Hey @Josep Garces, thanks for your insight. After years I'm trying to notarize a Max Standalone app (because, if I remember correctly, signing is not enough anymore to distribute online) and I am encountering an issue.
ng signed the app, and zipping it, the command you suggested:xcrun notarytool submit --keychain-profile "PROFILENAME" --wait PATHThrows an error. Even though the processing of the uploaded .zip files completes, and it gives me an id, the status is set to: Invalid.
Have you encountered something similar?
Trying to CodeSign the .app built with Max 9.0.2 in macOS Sequoia 15.1.1 and it returns this error:
/Users/ruslanyusipov/MyApp.app: replacing existing signature
/Users/ruslanyusipov/MyApp.app: resource fork, Finder information, or similar detritus not allowedBoth using Dan's ruby script standalone-codesigning-script.rb
And this command:
codesign -f -s "Developer ID Application: Ruslan Yusipov" "/Users/ruslanyusipov/MyApp.app" --deep --options runtimeAny clues on this?
P.S. Full error:
/Users/ruslanyusipov/MyApp.app/Contents/Resources/C74/externals/ad/ad_coreaudio.mxo: replacing existing signature (RuntimeError)
/Users/ruslanyusipov/MyApp.app/Contents/Resources/C74/externals/ad/ad_coreaudio.mxo: resource fork, Finder information, or similar detritus not allowedHave you tried running
sudo xattr -cr
on the app in terminal?
B
Nevermind Billy, I purchased AppWrapper for this task, thanks to James for the tip in another thread.
It makes the .app file but the resources for it are absent. I need to dig deeper, why it cut offs all the resources and doesn't load reg files.
The AppWrapper signs the app, but sandboxing feature kills all .png resources. As far as I know sandboxing is required for AppStore.
The command that Billyanok listed above is what I use when I get this error, has worked for me in the past.
AppWrapper started to give an error complaining about external resources. It says that they already have an anchor other than com.myapp.myapp.
I used the command Billy put earlier for manual processing and at first it worked, but after working with AppWrapper it started to give the same error that App is already signed (replacing existing signature) even after applying:
sudo xattr -cr MyApp.app