Apple notarizing for Mojave (10.14) and beyond

    • Feb 12 2020 | 8:33 pm
      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.
    • Feb 12 2020 | 8:48 pm
      Report file:
      31 thread that cause the crashing: Thread 31 Crashed:: Dispatch queue:
      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 0x00007fff5dbcd5a7 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163 4 0x00007fff5dbcb545 __TCCAccessRequest_block_invoke.114 + 500 5 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
    • Feb 12 2020 | 9:03 pm
      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"....
    • Feb 12 2020 | 9:05 pm
      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?
    • Feb 12 2020 | 9:44 pm
      My app access to microphone permission when it launches, I'm pretty sure that's the problem. I codesigned with the permissions for mic 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
    • Feb 13 2020 | 12:27 am
      I wonder if Max is aggressively asking for access to the camera. What happens when you add permissions to your entitlements?
      I would also recommend using these:
      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):
    • Feb 13 2020 | 7:08 pm
      All the entitlements I have:
      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.
    • Feb 13 2020 | 7:26 pm
      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.
    • Feb 13 2020 | 9:26 pm
      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.
    • Feb 13 2020 | 9:34 pm
      Ah ok - so getting the entitlements correct is the real fix to the quick fix of omitting --options runtime?
    • Feb 13 2020 | 9:45 pm
      For sure - whether it's the only thing I can't say, but it's a definite requirement, so I'd start there!
    • Feb 13 2020 | 11:59 pm
      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!
    • Feb 14 2020 | 12:59 am
      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" ""> <plist version="1.0"> <dict> <key><;/key> <true/> <key><;/key> <true/> <key><;/key> <true/> </dict> </plist>
    • Feb 14 2020 | 3:51 am
      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?
    • Feb 14 2020 | 11:55 am
      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.
    • Feb 14 2020 | 12:08 pm
      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.
    • Feb 14 2020 | 12:11 pm
      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!
    • Feb 14 2020 | 12:28 pm
      Have you gone through the process at this URL, to get your "Developer ID Application" certificate?
      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:
    • Feb 14 2020 | 3:41 pm
      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.
    • Feb 14 2020 | 4:38 pm
      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"
    • Feb 14 2020 | 4:43 pm
      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/
      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.
    • Feb 14 2020 | 4:45 pm
      I should add that *anything* with "Developer:" returns the same error in terminal so it seems like more of a Terminal error than anything.
    • Feb 14 2020 | 4:52 pm
      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?
    • Feb 14 2020 | 4:56 pm
      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.
    • Feb 14 2020 | 5:13 pm
      Can you send a screenshot of the line in your Keychain Access app, in the MyCertificates section, that shows your Developer ID Application certificate?
    • Feb 14 2020 | 5:35 pm
      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.
    • Feb 14 2020 | 5:40 pm
      Sometimes the dashes get converted into "fancy dashes" or something like that. Either way, glad you were successful!
    • Feb 18 2020 | 4:26 pm
      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.
    • Feb 18 2020 | 4:44 pm
      For me, following the steps at 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.
    • Feb 18 2020 | 4:58 pm
      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.
    • Feb 18 2020 | 5:04 pm
      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.
    • Feb 18 2020 | 10:39 pm
      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?
    • Feb 19 2020 | 12:11 am
      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:
      31 thread that cause the crashing: Thread 31 Crashed:: Dispatch queue:
      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 0x00007fff5dbcd5a7 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163
      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: 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 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?
    • Feb 19 2020 | 1:17 am
      @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: , in particular the link within it, which points here: "
    • Feb 19 2020 | 1:20 am
      And @SSingh, re: checking the log, see my 2nd post on the first page of this thread.
    • Feb 19 2020 | 1:28 am
      @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 , 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...
    • Feb 19 2020 | 8:57 pm
      @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.
    • Feb 20 2020 | 4:22 am
      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?
    • Feb 20 2020 | 4:34 am
      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: And here's the signed, notarized and stapled .dmg:
    • Feb 20 2020 | 6:50 am
      Be sure to have the maxzlib.mxo and the sqlite.mxo in the C74 folder inside the resources folder inside your standalone bundle.
    • Feb 20 2020 | 6:55 am
      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.
    • Feb 20 2020 | 11:46 am
      I haven't removed anything - they're in there:
    • Feb 20 2020 | 1:10 pm
      @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...
    • Feb 20 2020 | 3:19 pm
      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?
    • Feb 20 2020 | 3:30 pm
      @Ssingh, can you post your full current codesign command?
    • Feb 20 2020 | 4:03 pm
      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?
    • Feb 20 2020 | 4:29 pm
      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...
    • Feb 20 2020 | 4:36 pm
      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?
    • Feb 20 2020 | 4:40 pm
      I'm honestly not sure at this point. Again, perhaps others have ideas...
    • Feb 20 2020 | 6:01 pm
      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.
    • Feb 20 2020 | 8:26 pm
      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?
    • Feb 20 2020 | 8:46 pm
      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?
    • Feb 20 2020 | 9:31 pm
      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.
    • Feb 20 2020 | 9:36 pm
      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!
    • Feb 20 2020 | 9:42 pm
      That's great, another mystery solved!
    • Mar 13 2020 | 7:55 pm
      SSingh I was wondering if Quick License ever got past notarization ?
    • Mar 13 2020 | 9:08 pm
      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.
    • Mar 13 2020 | 9:37 pm
      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..
    • Mar 13 2020 | 9:42 pm
      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.