Apple notarizing for Mojave (10.14) and beyond


    Oct 21 2018 | 12:35 pm
    Apple has made updates in Mojave (10.14) to Gatekeeper, re: app “notarizing,” even for apps outside of the Mac App Store.  Although currently optional, they suggest that Gatekeeper will require notarization in a future Mac OS update:  https://developer.apple.com/developer-id/
    When users on macOS Mojave first open a notarized app, installer package, or disk image, they’ll see a more streamlined Gatekeeper dialog and have confidence that it is not known malware. Note that in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple.
    Wondering if anyone has tried to get their Apple Developer ID-signed Max standalone notarized by Apple, and how they did it.  There is some info that Apple provides, that suggests that one has to enable “hardened runtime” status for the app, which seems similar to the entitlements signing required for the App Store, but what I’m concerned about is that the examples Apple provides suggest that one has to do these things within XCode, which obviously won’t work for standalones created with Max:
    I know it’s early for this stuff, but trying to stay ahead of the Apple curveballs that they continue to throw...

    • Oct 26 2018 | 8:34 pm
      OK, answering my own question here, but hopefully this will help others (or me when I forget how I did it a month from now!). Here's the steps I took for successful Apple Max app Notarization. Note that you need to be running at least Mac OS 10.14 for all of these steps to work (steps 0-5 worked for me on 10.13.6, but not the last step, step 6), as well as XCode 10.0.
      Step 0)  Remove libmozjs185.dylib from the app bundle. Currently (as of Max 8.0.1), the version of the Javascript library that's used was apparently compiled using an older SDK that Apple objects to. So for now at least, you need to remove this file (and therefore no Javascript will be supported in your app). Hopefully Cycling can address this in a subsequent Max update. This is no longer necessary starting with Max version 8.0.4. Thanks for fixing this Cycling!
      Step 1)  Codesign the app to enable “Hardened Runtime” status.  Here’s the command I used in the Terminal.  The key change from previous "regular" Developer codesigning is the part at the end, “--options runtime”
      codesign -f -s "Developer ID Application: Daniel Nigrin" /Users/dnigrin/Desktop/MyApp.app --deep --options runtime
      Step 2)  For some reason the Notarizer only works with pkg, dmg or zip files.  So I just wrapped up the .app inside a .dmg, as I would if I were to be distributing it to end-users.  FWIW, I use an app called DropDMG for this, but there are free options too.
      Step 3)  Notarize the package you made in Step 2.  Note that the -u and the -p parameters represent your Apple ID username and password.  I believe there are ways to access your Mac’s keychain for these, but I just put them directly into the Terminal command.  Note that you’re not using your regular Apple ID password for this; I believe you have to first ensure that you have dual factor authentication set up with Apple, and then you have to set up an App-specific password for the Terminal at https://appleid.apple.com .  Once you do that, you use that app-specific password in the Terminal command:
      xcrun altool --notarize-app -f /Users/dnigrin/Desktop/MyApp.dmg --primary-bundle-id com.defectiverecordssoftware.myapp -u xxxxxx@xxxxxxxx.com -p xxxx-xxxx-xxxx-xxxx
      Step 4)  After a bit of time (a few minutes, I guess it’s dependent on your .dmg size and upload speed to Apple), you’ll get a response in the Terminal, and eventually via email too – the email will say whether you’re been successfully notarized or not:
      2018-10-23 08:56:37.955 altool[28413:6636960] No errors uploading '/Users/dnigrin/Desktop/MyApp.dmg'.
      RequestUUID = 7bce4b12-f52e-46ea-8071-xxxxxxxxxx
      Step 5)  You can also do a validating step in the command line, using the UUID provided above. 
      xcrun altool --notarization-info 7bce4b12-f52e-46ea-8071-xxxxxxxxxx -u xxxxxx@xxxxxxxx.com -p xxxx-xxxx-xxxx-xxxx
      This is useful for debugging too, as the response provides a long URL that points to the log for the entire process. If you're not successful in notarizing, inspection of this log is critical to figure out what went wrong:
      2018-10-23 09:01:55.039 altool[28575:6641949] No errors getting notarization info.
         RequestUUID: 7bce4b12-f52e-46ea-8071-xxxxxxxxxx
                Date: 2018-10-23 12:56:38 +0000
              Status: success
          LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma118/v4/19/e7/3e/19e73e6f-4c9d-4814-e5fc-f50dbe125129/developer_log.json?accessKey=1540494114_5933353877481991634_mfV3Cu%2B67wlqwqik7OJSLImkk3LOdbtxnu5cnXIswIoXQqqHiVFlgX9TMQMnzKmLaqaBJABiXJcZRy6ipPojgoyz%2FRpilI1G%2FjPryQnY%2B6%2FHI0nmiBaK1rPQcl8HT6QvtFlvhIp1Vs3LCp%2B%2B34O5k4T%2FY2IGOlv6u <snip>
         Status Code: 0
      Status Message: Package Approved
      Step 6)  The last step is where one “staples” the notarization ticket from Apple to your .dmg, which is how the Mac OS subsequently knows that it’s notarized:
      xcrun stapler staple /Users/dnigrin/Desktop/MyApp.dmg
      Hope this helps. There's a good video overview from a recent Apple WWDC conference that reviews this stuff (plus much more, including explanation of Entitlements, Purpose Strings, etc...) https://developer.apple.com/videos/play/wwdc2018/702/
    • Nov 18 2018 | 8:40 pm
      Dan, you are amazing. Haven't tried it yet, but I would have never figured this out on my own. How did you do it!?
      Tim
    • Nov 19 2018 | 4:13 am
      i wonder if they will one day manage to (legally or technically) forbid third parties to avoid gatekeeper when installing stuff (aka symlink installer) completely.
      from that day on i will call macos no longer an operating system.
    • Nov 19 2018 | 12:55 pm
      @Tim - you're very kind, thank you! Basically just a lot of Googling, poring over Apple published info, and trial and error! If you do try it, please report back with your experience. As with the collective Max community's experience with getting Mac App Store apps approved, we definitely do better when we aggregate everyone's info!
      @Roman - only time will tell. Agree that that would be a sad day though....
    • Nov 19 2018 | 2:28 pm
      That will be the day to switch to Linux... Though there is little hope for a Linux port of Max after Ableton took over...:-(
    • Nov 19 2018 | 11:07 pm
      I'll mess with this at some point, but for now, I'll keep working in Xcode. The relationship between Max and Apple is too tenuous for my comfort.
    • Mar 04 2019 | 10:04 pm
      Hi Dan,
      I'm circling back to this now and really want to get this working, but I'm struggling with it. Every time I go through the above steps, the notarization fails with the status message "Package Invalid". Here's the URL:
      Specifically, it says "MaxPlugInScanner", "message": "The executable does not have the hardened runtime enabled. I thought if I used "--deep --options runtime", I didn't need to sign individual files?
      I'd be deeply grateful for your help with this.
      Tim
    • Mar 04 2019 | 10:15 pm
      Quick update.... I just deleted the executable "MaxPlugInScanner" and it worked just fine! Hope that doesn't mess anything else up, though?
    • Mar 04 2019 | 10:35 pm
      Haha, I'm wrestling with the MaxPluginScanner within one of my Mac App Store apps at the moment...
      Bottom line you can safely delete that file, if your app doesn't depend on the new-for-Max-8 functionality used within the vstscan object.
      Great work! Glad to hear that someone else got through all the way!
    • Mar 05 2019 | 2:14 am
      I can't tell you how grateful I am to you, Dan. Your pioneering in this niche field has made a real difference to the community. Major props, bud!
    • Mar 05 2019 | 12:11 pm
      Thanks Tim! But it's far from a solo effort - lots of kudos go out to members of this forum, and to the Cycling team, who have helped behind the scenes when I get stuck, and to whom I reach out to directly at those points....
      A perfect example is with the libmozjs185.dylib limitation ("step 0" in the original post at the top of the thread) - I reached out directly to Cycling about it, and I think the fix will be forthcoming soon!
    • Mar 07 2019 | 7:12 pm
      Hi Dan,
      Can I ask you another quick question? Do you have any idea why my standalone would be working fine and then look like this after I sign it? I'm so close!!
      Tim
    • Mar 07 2019 | 7:18 pm
      I've had this before - but if memory serves it wasn't after signing, it was after I pulled something critical out of the package bundle.... I'm a bit foggy what that was, but maybe this gives you some clues?
    • Mar 07 2019 | 8:15 pm
      No luck... I tried exporting as an app and not removing anything. It worked fine until I signed it. After, I got the above. I tried exporting with the max window and received a ton of "object not found" errors. Trying to enable/disable a bunch of different options in the standalone object to see if I can isolate the problem.
    • Mar 07 2019 | 8:26 pm
      What I usually do for standalone object:
    • Mar 07 2019 | 8:30 pm
      Thanks, Dan, I'll try that. It's so strange that max is complaining that they can't find the files when they're right there. I'll try your options and see what happens.
    • Mar 07 2019 | 8:36 pm
      Matched your preferences line for line and still have the missing objects. Pulling my hair out.
    • Mar 07 2019 | 8:38 pm
      Let's see the statements you're using for the codesigning, sometimes I've had luck with picking out problems there...
    • Mar 07 2019 | 10:16 pm
      codesign -f -s "Developer ID Application: Timothy Stulman (*************)" PATH_TO_APP --deep --options runtime
      I tried putting only a comment box in and exporting it as an app without changing anything. I open it on the desktop and it works fine. I sign it and get the placeholder image instead of the comment. So it's not something in my app.
    • Mar 08 2019 | 12:26 am
      Update: It works fine with Max 7. I wonder if it has something to do with having two version of max on my machine? I'm going to try it with Max 8 on a different machine that doesn't have 7 on it.
    • Mar 08 2019 | 12:37 am
      Definitely not that, I've got umpteen versions of Max on my machines, they stay separate.
      Are you sure that all is OK with your developer certificate? Maybe have a look at Keychain Access to be sure all is well there (i.e. not expired)
    • Mar 08 2019 | 2:13 am
      Can confirm that it's not my machine or multiple installations. Tried it on a test machine with the exact same results. I'll check my developer certificate, but I would think that if there was an issue, the signing wouldn't be successful and/or I wouldn't be able to successfully notarize. But I'll check. Tomorrow. Thanks so much, Dan!
    • Mar 08 2019 | 12:36 pm
      I presume you're using the latest Max version? Also, what is the setting in your System Preferences/General/Allow Apps Downloaded From? It should be "App Store and Identified Developers"
    • Mar 08 2019 | 5:46 pm
      Yes and yes... I'm on Max 8.0.3 and my system preferences are set to "App Store and Identified Developers". All my dev certs are up-to-date as well.
      What OS are you on, Dan? I'm on the most recent version of Mojave. I wonder if that could be it?
    • Mar 08 2019 | 5:58 pm
      Here's another "clue"... If I sign without "--options runtime", it works fine. As soon as I add it, I get the same "object not found" error for all objects.
    • Mar 08 2019 | 6:12 pm
      OH!!!!! Forget about the OS level, I realize what the issue is from your last post, I'm an idiot. You have enabled Hardened Runtime status, by using the new "--options runtime" flag, great. But you've not yet done the subsequent required steps (numbers 2 through 6 in my post near the top of the thread) (at least I think you haven't). Those are necessary for the app to work right....
    • Mar 08 2019 | 6:23 pm
      I got the notarization approved from Apple previously, confirmed via email and terminal, but not recently. I've been hung up on the signing portion. I'll try going through from beginning to end right now.
    • Mar 08 2019 | 6:57 pm
      Still no luck. My app was notarized, and here's my final step stapling confirmation:
      And here's my app when it opens:
      Do you think I should contact someone at Cycling74? Not sure about you, but I'm running out of ideas.
    • Mar 08 2019 | 6:59 pm
      Damn!! I was sure that was it.... Sorry!
      At this point I'm out of ideas too - yeah sure, you could try the Cycling folks, always worth a shot!
    • Mar 08 2019 | 7:37 pm
      Thanks, man, just submitted a ticket. Really hope I can get this worked out.
    • Mar 19 2019 | 5:48 pm
      Just a quick note to point out that the just released Max 8.0.4 fixes the issue with the Javascript library (originally step 0 in one of my first posts in this thread - I've edited that post to say that this step is no longer required).
    • Apr 04 2019 | 10:16 am
      Go in your User/Library...you have to visualize it first, select your User Home page in the left tab and press command-J, then flag the option. After that, go in Application Support and find your preference file. If you have the issue above, first delete the entire preference folder, relaunch your app, then go inside the new created preference file (let your app opened for the first time), you'll see another folder (temp-MaxRuntime), press command - i and set the privileges to "read only". Done. Try now to close and reopen your app. It's possible that some (a lot) preference files will be created on the Desktop...delete them after the use of your app. This preference files where always created after the launch of your app...it's better they go on the Desktop instead inside the preference file where the temp.MaxRuntime will be overwritten with a dummy file. There should be for sure a better method, but now I know only this workaround.
    • Apr 05 2019 | 12:44 am
      Hi KeepSound,
      What's this in reference to? The missing objects and display issues?
      TS
    • Apr 05 2019 | 1:27 am
      GUI display issues, app not working.
    • Apr 18 2019 | 9:21 am
      Hi Dan... and everyone else! First of all: THANKS for this thread (and this one https://cycling74.com/forums/max-standalone-in-the-mac-app-store-2018). I am currently writing a Python script to automate most (if not all) of the actions required in order to make deployment as smooth as possible! As soon as it's done, I'll share the GitHub link here.
      Unfortunately I'm writing because my app is exhibiting some weird behaviour after being signed. From a fully working status, the app is unable to save some json files (used to store MIDI mappings and dial presets) after being signed. I am currently trying to save these two files inside the app bundle, but also trying to save them outside seems to present the same problem. Has anyone encountered the same issue?
    • Apr 18 2019 | 10:51 am
      From my experience, you can't save in the app bundle. I have success saving at /Users/CURRENT_USERNAME/Library/Application Support/APP_NAME/ , where APP_NAME is the name specified in the standalone object's "Preferences File Name" attribute.
    • Apr 18 2019 | 10:58 am
      Also I seem to remember reading a while back that this location might eventually be taken away as being OK for an app to write files to, and instead apps would need to use the "Container" which the Mac OS now makes for it. So that location would be: /Users/CURRENT_USERNAME/Library/Containers/com.yourcompany.APP_NAME/Documents
    • Apr 18 2019 | 11:32 am
      This doesn't seem to work if I follow the other thread (https://cycling74.com/forums/max-standalone-in-the-mac-app-store-2018). I will try and follow only your step by step guide and see if it makes a difference. When you talk about upload after the notarisation, you're not uplooading to the app store correct?
    • Apr 18 2019 | 11:55 am
      Just to be clear, the other thread is about getting apps on the App Store, this one is about just Notarizing. They're related, but different. So please clarify which you're trying to do.
      Also, when you say "This doesn't seem to work" - can you clarify which of the two locations I mentioned you're talking about, and what you experienced?
      And correct - this upload is only an upload to Apple to allow for notarization, NOT for submission to the App Store.
    • Apr 18 2019 | 12:30 pm
      I am trying to sign an app that needs to be distributed outside the app store. Without the signing, the app results in being corrupted and won't open on any other mac. Signing the app using part of the instructions on the other thread makes the app usable on other machines but prevents the saving and loading of preset json files. I have tried switching location to ~/Library/Containers/com.mycompany.APP_NAME/Data/Documents and while this works with the exported app, as soon as I perform the tasks listed on the other thread (ie, plist editing, mxo file plist and executable renaming, codesigning + entitlements) the app stops saving the files. As you have said, probably following your guide and sticking to signing and notarizing will do the trick. I will conduct further testing and let you know!
    • Apr 18 2019 | 1:11 pm
      It's easy to save in the app bundle!!! In osx and win too.
    • Apr 18 2019 | 1:16 pm
      @Niccolo Thanks for clarifying what you're trying to do. For the short term, you really don't need to worry about the notarizing stuff in this thread, nor the bulk of the things mentioned in the other thread. You really only need to do this:
      codesign -f -s "Developer ID Application: Your Name" /Users/CURRENT_USERNAME/Desktop/MyApp.app --deep
      If you want to ensure that your app survives to the point when Apple *requires* notarization, then you could try the steps in this thread.
      Re: where you should store your files, the Container stuff is really only necessary if you will be sandboxing your app, which is required for the App Store. So using the Application Support folder should be fine for your purposes now.
      @Keepsound Yes, it's technically easy to do within Max, but when you start getting into the notarization and sandboxing stuff with Apple, you will run into problems...
    • Apr 18 2019 | 1:42 pm
      @Dan I can't thank you enough. While the hardened runtime codesigning broke my app (maybe something I should worry in the future) the simple codesign command line works fine, and keeps the preset saving intact. I still need to test it on another machine, but everything seems to be working like a charm! I switched to the Application Support folder as well, thanks!
      @Keepsound That's exactly how I'm saving my files. But previously, codesigning and entitling the app broke that feature.
    • Apr 18 2019 | 1:46 pm
      You're welcome! Glad that worked.
    • Apr 18 2019 | 1:57 pm
      Maybe notharize only the app inside the bundle, not the entire bundle.
    • Apr 18 2019 | 2:01 pm
      Doesn't work that way I'm afraid... Apple is painfully strict!
    • Apr 18 2019 | 8:30 pm
      I mean only the Unix Executable...why shouldn't work?
    • Apr 18 2019 | 8:36 pm
      Because for Apple to consider the application fully "notarized", the *entire* app bundle needs to be notarized, not just one component inside...