Dan Nigrin

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 

 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:

https://help.apple.com/xcode/mac/current/#/dev88332a81e?sub=dev7468a021d

https://help.apple.com/xcode/mac/current/#/devf87a2ac8f

I know it’s early for this stuff, but trying to stay ahead of the Apple curveballs that they continue to throw...

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.

Apple has made updates in Mojave (10.14) to Gatekeeper, re: app “notarizing,” even for apps outside of the Mac App Store.  Although currentl

apple-notarizing-for-mojave-10-14-and-beyond

OK, answering my own question here, but hopefully this will help others (or 

 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 

 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.

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!

  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”

  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.

  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 

 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 

 .  Once you do that, you use that app-specific password in the Terminal command:

  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:

  You can also do a validating step in the command line, using the UUID provided above. 

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:

  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:

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/

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

    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>

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/ 

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!?

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.

@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....

@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....

That will be the day to switch to Linux...

Though there is little hope for a Linux port of Max after Ableton took over...:-(

That will be the day to switch to Linux...
Though there is little hope for a Linux port of Max after Ableton took over...:-(

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.

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.

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. 

Quick update.... I just deleted the executable "MaxPlugInScanner" and it worked just fine! Hope that doesn't mess anything else up, though?

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!

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!

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!

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!

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....

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!!

Screen Shot 2019-03-07 at 2.12.02 PM.png

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 

 that was, but maybe this gives you some clues?

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?

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.

Max001.png

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.

Screen Shot 2019-03-07 at 3.29.04 PM.png

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. 

Matched your preferences line for line and still have the missing objects. Pulling my hair out.

Let's see the statements you're using for the codesigning, sometimes I've had luck with picking out problems there...

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.

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.

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)

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)

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!

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"

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"

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?

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. 

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.

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)

. Those are necessary for the app to work right....

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....

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.

Still no luck. My app was notarized, and here's my final step stapling confirmation:

Screen Shot 2019-03-08 at 1.53.23 PM.png

Screen Shot 2019-03-08 at 1.55.58 PM.png

Do you think I should contact someone at Cycling74? Not sure about you, but I'm running out of ideas.

Still no luck. My app was notarized, and here's my final step stapling confirmation: 

Do you think I should contact someone at Cycling74? Not sure about you, but I'm running out of ideas.  

At this point I'm out of ideas too - yeah sure, you could try the Cycling folks, always worth a shot!

Damn!!  I was sure that was it.... Sorry!

Thanks, man, just submitted a ticket. Really hope I can get this worked out.

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).

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.

Mac-Show-User-Library-Folder-Permanently.jpg

Schermata 2019-04-04 alle 12.24.52.png

What's this in reference to? The missing objects and display issues?

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. 

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?

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.

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.

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

I've never tried this myself yet though - if you do please report back. More info is here: 

https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6

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

I've never tried this myself yet though - if you do please report back.  More info is here:  https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6 

This doesn't seem to work if I follow the other thread (

). 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?

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?

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.

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.

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!

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!

Schermata 2019-04-18 alle 15.16.34.png

It's easy to save in the app bundle!!! In osx and win too.

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.

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...

@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 

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...

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!

That's exactly how I'm saving my files. But previously, codesigning and entitling the app broke that feature.

@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.

Maybe notharize only the app inside the bundle, not the entire bundle.

Doesn't work that way I'm afraid... Apple is painfully strict!

Doesn't work that way I'm afraid...   Apple is painfully strict!

I mean only the Unix Executable...why shouldn't work?

Because for Apple to consider the application fully "notarized", the *entire* app bundle needs to be notarized, not just one component inside...

Thank you so much for writing this guide Dan - I was able to successfully notarize a Max standalone!

Except, similar to others' experience in this thread, now it won't actually run. My standalone hangs before showing the main window if I codesign it with hardened runtime.

It works fine if I codesign it normally, as I have been doing, but then it doesn't notarize. And apparently it doesn't fit into apple's legacy rules for "preexisting software".

Update 2019-05-09: I tried with a pre-exisiting Max 7.3.5 build of my standalone. That also won't notarize (apparently doesn't fit into Apple's legacy rules). Even if I deep re-sign it with hardened runtime, apple notarization reports that many of the .dylibs remain unsigned, and "The [main] binary uses an SDK older than the 10.9 SDK." It also does not run properly when signed with hardened runtime. It gets farther and displays the window, but can't find any objects and some fonts, and the window is filled with brown hatching like other posters here. So Max 7 standalones seem to be a solid "no go" for notarization.

Thank you so much for writing this guide Dan - I was able to successfully notarize a Max standalone! 

Except, similar to others' experience in this thread, now it won't actually run. My standalone hangs before showing the main window if I codesign it with hardened runtime. 

It works fine if I codesign it normally, as I have been doing, but then it doesn't notarize. And apparently it doesn't fit into apple's legacy rules for "preexisting software". 

Hmm, looking like maybe I need to dive back into this and see what's up, as several people are reporting the same problem as you say Arvid....

When I get a few moments I'll give it a try and report back....

Thanks so much Dan. Maybe I'll try some simpler test standalones and see if i can get any of those to work after hardened runtime signing to maybe isolate the problem. The one I'm trying to notarize is a pretty massive patch that uses lots of different Max features.

Good idea, but know that in the above thread, @Timothy.Stulman tried with just a comment box in a patcher and still had issues...

thanks missed that. But confirmed over here as well - a simple standalone with just flonum, cycle~, live.gain~ and dac~ built in Max 8.0.5 is broken when signed with hardened runtime. Can't load any objects. Amusingly, if I just resign as normal, it runs perfectly fine again.

thanks missed that. But confirmed over here as well - a simple standalone with just flonum, cycle~, live.gain~ and dac~  built in Max 8.0.5 is broken when signed with hardened runtime. Can't load any objects. Amusingly, if I just resign as normal, it runs perfectly fine again.

Bummer - will have to dig in to see if I can figure it out. Might need Cycling's help on this one!

Bummer - will have to dig in to see if I can figure it out.  Might need Cycling's help on this one!

Hardened Runtime is going to be pretty much impossible with our current standalone format, so this will require a non-trivial review of what we're doing and how we can meet the ever-changing needs of the improved security measures being pushed by Apple.

By manually signing every external and extension loaded by Max, I was sorta-kinda able to get some stuff loading, but it's complicated: our standalone is a wrapper around the collective file format, and we use that format to embed resources required by the patcher. Like externals. When loading the standalone, the embedded externals are extracted and loaded, which won't work at all with hardened runtime enabled. So that's just the beginning. It looks like LLVM won't allow us to allocate memory either (llvm error Allocation failed when allocating new memory in the JIT), so we may need to do some extra work to get Gen working, etc.

I don't think this is going to be easy, but we will come up with a plan of attack as soon as we have a chance and get back to you on this.

By  manually signing every external and extension loaded by Max, I was sorta-kinda able to get some stuff loading, but it's complicated: our standalone is a wrapper around the collective file format, and we use that format to embed resources required by the patcher. Like externals. When loading the standalone, the embedded externals are extracted and loaded, which won't work at all with hardened runtime enabled. So that's just the beginning. It looks like LLVM won't allow us to allocate memory either (llvm error Allocation failed when allocating new memory in the JIT), so we may need to do some extra work to get Gen working, etc.

Jeremy, thanks so much for digging into this, and for the update. Fingers crossed!

Jeremy, thanks so much for digging into this, and for the update.  Fingers crossed!

Apple notarizing for Mojave (10.14) and beyond