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...
    • May 08 2019 | 9:38 pm
      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".
      Catch 22.
      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.
    • May 08 2019 | 10:48 pm
      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....
    • May 09 2019 | 2:15 pm
      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.
    • May 09 2019 | 2:22 pm
      Good idea, but know that in the above thread, @Timothy.Stulman tried with just a comment box in a patcher and still had issues...
    • May 09 2019 | 2:29 pm
      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.
    • May 09 2019 | 3:09 pm
      Bummer - will have to dig in to see if I can figure it out. Might need Cycling's help on this one!
    • May 16 2019 | 1:45 pm
      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.
    • May 16 2019 | 1:58 pm
      Jeremy, thanks so much for digging into this, and for the update. Fingers crossed!
    • May 16 2019 | 5:41 pm
      hi, would this help? http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/?fbclid=IwAR3UlDsLH3kta8uVi_A_rmxIEzKcc9tzTX_2Sfoq3P9JlXUAHcewwLFmDh0
    • May 16 2019 | 7:30 pm
      Sure, you can instruct users to turn off security features in order to run software, but that's not an ideal solution, nor will such software make it into the App Store, which is the point of conforming to Hardened Runtime requirements. Anyway, as I said, there's no quick fix, but we'll do our best to roll with Apple's punches.
    • May 16 2019 | 7:47 pm
      And for sure we can see the writing on the wall, that Apple will ultimately *require* apps to be hardened/notarized, whether purchased from the App Store or not. Sadly, it's only a matter of time I think.... See first post in this thread.
    • May 16 2019 | 7:56 pm
      This is my primary use for Max/MSP, so I really hope we can get this worked out eventually. Thank you, Jeremy, for your continued efforts. We're all really grateful for the work you do!
    • May 16 2019 | 9:36 pm
      Personally I'm not interested to sell my apps on the App Store of Apple, but for sure that my apps are working in Mojave and in the future, also old apps and also if some of them have stored (and thus changing) setup files in them... Now the gatekeeper changer is just a good option for me, and if someone don't would change it for the entire computer, he can launch a app pressing the the alt/option key. For the entire mod I've build a little app that does what you can do with the Terminal...maybe can be useful for someone. Note that I don't know if this method is working or not, I'm always on Sierra now. Here the download link: https://app.box.com/s/0ofli74507o59t7cb6p7qc7944meot5z (Vers 1.1)
    • May 17 2019 | 5:45 am
      1- Apple script app doing same would be just few KBs for same thing 2 - "pkill, echo $1 | sudo spctl --master-ensable penter"
      You should correct that line P.S. Gate keeper will revert to default settings, unless one sets autorarm flag to off:
      paste this into aplle script and save as app :
      do shell script "sudo spctl --master-disable; sudo defaults write /Library/Preferences/com.apple.security GKAutoRearm -bool NO" with administrator privileges
      There are many other options like only setting getekeeper off for individual app and so on, for example:
      sudo xattr -rd com.apple.quarantine path to the app or sudo spctl --add path to the app
    • May 17 2019 | 9:18 am
      Thanks! Corrected. Vers 1.2 Same link
    • Jun 16 2019 | 3:25 am
      I’ve just read through this entire thread and I’m confused. I just sent a standalone built with 8.0.6 to someone with Mojave and they’re Saying Mohave said was damaged and required him to trash it.
      Are there official steps to send a stand-alone to a mojave user? It seems like dans steps are what’s perscribed but I’m not sure what all the references to hardened runtime mean.
    • Jun 16 2019 | 10:46 am
      @AudioMatt it seems like you are encountering the same problem I did a while back. This post focuses on notarizing apps but as @Dan previously stated, you don't need to notarize the standalone if you simply want to share it. For macOS, to share a standalone app you simply need to sign it. To do so, run this command on your terminal: codesign -f -s "Developer ID Application: Your Name" /Users/CURRENT_USERNAME/Desktop/MyApp.app --deep In order for this to work you need to generate a Mac App ID from your apple developer portal, download the certificate and make sure that its stored in your keychain. To so you need to be enrolled in the apple developer program and have access to their online developer tools.
    • Jun 16 2019 | 11:24 am
      @Niccolo's reply is what I would have written myself.
      There's workarounds out there for the moment (some in the thread above, and here's one with just a bit of Googling: https://techstuffer.com/this-app-is-damaged-error-macos-sierra/ ), but future versions of the Mac OS remain unclear in this regard...
    • Jun 16 2019 | 12:09 pm
      @niccolo @dan I'll give this a try when I charge my phone.
      I gotta say it sounds like they're frog-in-a-potting a world where you can't distribute applications without their consent which I find pretty fucking scary.
    • Jun 16 2019 | 8:35 pm
      Wait wait wait... I have to pay 100 bucks to deploy my standalone to another computer?!
    • Jun 16 2019 | 8:42 pm
      Yes @AudioMatt, or you ship the standalone with instructions on how to open apps from unidentified developers. (https://www.imore.com/how-open-apps-unidentified-developers-mac)
    • Jun 16 2019 | 10:08 pm
      Well, if you can get it to them without them downloading, it will still work I believe. It's the download process which "taints" the file somehow. Or at least I think??
    • Jun 17 2019 | 7:54 am
      Just few thoughts... As first, I don't care about apple protection, and will allways jailbreak whatever apple forces one to do, for myself and my customers. For those of You wanting to distribute apps "officially"... Statement from Jeremy : "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" I stoped using "usual" building procedure for standalones quite a while ago. For many reasons, main being able to update apps without need of recompiling them. So basically, I put all stuff that my standalone needs in app folder, and use .maxpat instead of .mxf. mxf is just a patch with embedded externals, patchers and whatever resources, but that stuff anyway gets extracted in runtime, which allways irritated me. And maxpat needs just a few lines of code to get "converted" to mxf, very primitive checksum, and few other bits. So if mxf is a problem for notarizing standalone, I am sure folks at cycling can easily solve at least that.
    • Jun 17 2019 | 11:19 am
      That's a really good observation @Source Audio. Though you mention .maxpat files, I presume you do the same for the externals that the application needs? I thought those were what were being extracted from the .mxf, and which were causing problems with Apple.... On the Mac, I believe they all get extracted to /Users/USERNAME/Library/Application Support/APPNAME/temp64-APPNAME/mxt/ ???
    • Jun 17 2019 | 1:11 pm
      Yes, I also copy needed externals to app folder. In fact one can build mxf witout embedding externals, just move them out of max search path before building mxf or standalone. Same procedure was used by ircam to bulid FTM based standalones in old versions. But I mentioned this just to point that if standalone was able to run maxpat, instead of insisting on mxf file, all would/could be easier. All it needs is to auto - run main patcher as maxpat. ------- And yes - the externals get extracted into path You mentioned.
    • Jun 17 2019 | 2:42 pm
      Got it, thank you. Hoping that the Cyclists can figure something out, perhaps along these lines...
    • Jun 17 2019 | 3:10 pm
      We're investigating our options (we have a number of different "entry points" to this problem which need to be considered) and will have a plan for how to proceed with the standalone stuff specifically before too long. We'll keep you posted. In particular, we'd like to solve this problem with a view toward not having to solve it again in a couple of years... :-) Anyway, have no fear, the elves are on the case. Thanks for your patience!
    • Jun 17 2019 | 3:21 pm
      Awesome, thanks as always Jeremy!
    • Jun 17 2019 | 3:23 pm
      That's good news, thanks. It must be frustrating to have to spend time fighting that apple nonsense, instead of using it for something creative.