Apple notarizing for Mojave (10.14) and beyond
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...
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
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/
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
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....
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.
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
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!
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!
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
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.
What I usually do for standalone object:
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)
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"
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?
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) (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:
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.
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!
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.
Hi KeepSound,
What's this in reference to? The missing objects and display issues?
TS
GUI display issues, app not working.
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.
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 (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.
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!
It's easy to save in the app bundle!!! In osx and win too.
@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.
You're welcome! Glad that worked.
Maybe notharize only the app inside the bundle, not the entire bundle.
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".
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.
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.
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.
Jeremy, thanks so much for digging into this, and for the update. Fingers crossed!
hi, would this help?
http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/?fbclid=IwAR3UlDsLH3kta8uVi_A_rmxIEzKcc9tzTX_2Sfoq3P9JlXUAHcewwLFmDh0
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.
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.
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!
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)
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
Thanks! Corrected. Vers 1.2 Same link
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.
@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.
@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...
@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.
Wait wait wait... I have to pay 100 bucks to deploy my standalone to another computer?!
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)
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??
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.
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/ ???
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.
Got it, thank you. Hoping that the Cyclists can figure something out, perhaps along these lines...
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!
Awesome, thanks as always Jeremy!
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.
Great news. Thanks Jeremy!
thank you for this thread,
after some sadness and trepidation that none of my applications work anymore, i started following the steps with some optimism hoping to have a working standalone on mojave that i can share with collaborators and clients. i think i was able to replicate everyone's instructions up to this point and unfortunately ended up with the same end result:
1) a standalone built with max on mac os 10.14.5 works fine on my personal machine but cannot be distributed to others without proper codesigning and notarization as described above in this thread.
2) after codesign WITHOUT the hardened runtime option the app still works but cannot be properly notarized and is still undistributable
3) after codesign WITH the hardened time option the app is approved by apple but breaks, objects cannot be found and the UI looks like the image form TIMOTHY.SIMULATION's post from March 8, 2019 above. none of the suggestions regarding deleting preferences, etc. have any positive effect.
could anyone please confirm that this is the current state of affairs so i can give up on building standalones on mac for the time being. if there is no near term fix, i hope that cycling would consider reintroducing a runtime player. i imagine it is not uncommon for max users to work and collaborate with people who are not familiar with programming or max specifically. it is very discouraging when trying to use max as a tool for creative collaboration to explain that in order to be able to run code for a performance or installation one would have to download a 500mb program, install it and run it in demo mode but one need not be concerned because a collective would not be affected by the demo.
Hi @Liubomir, I'm sorry to hear that you're encountering many problems. I wanted to ask you a question regarding your issue: why do you need to notarize your app? Aren't you able to just codesign it? Codesigning the app worked for me, and I'm able to distribute my standalone freely without any major issues. Moreover users do not have to install Max and run it in demo mode.
From what I gathered Apple might require in future apps to be notarized, but that's not yet the case. Simply running:
codesign -f -s "Developer ID Application: Your Name" /Users/CURRENT_USERNAME/Desktop/MyApp.app --deep
did the trick for me. But maybe I'm not aware of the benefits of notarizing an app.
Is there any extra processes to getting the code signing working other than downloading the cert and sticking it in keychain? I'm getting no identity found errors for the codesigning.
You can double check that your certificate is all OK in the KeyChain Access app. Click the "My Certificates" category in the lower left panel, and you should see the entry there. Make sure the certificate name you are using in the command Niccolo listed above is exactly the same as what's shown in the KeyChain Access app.
@niccolo, thanks for the response. unfortunately only codesigning does not work for my particular problem. the app that i have built relies on external files loaded from the app's folder. if i run from my account my console reads:
jsui: ui engine loaded
js: full path: x:/Users/liubo/Desktop/erst/erst019syphon4/erst/erst19syphon4h.maxpat
js: patch path: x:/Users/liubo/Desktop/erst/erst019syphon4/erst
js: text path: x:/Users/liubo/Desktop/erst/erst019syphon4/erst/texts/default.txt
if i download the app it runs inside some private folder and is unable to find the files it needs
jsui: ui engine loaded
js: full path: x:/private/var/folders/w5/x732bbkd4ddct46vbbt4nmc80000gn/T/AppTranslocation/C6E0F9C1-A286-4BA9-9A7A-3D7EB2729124/d/erst19syphon4h.maxpat
js: patch path: x:/private/var/folders/w5/x732bbkd4ddct46vbbt4nmc80000gn/T/AppTranslocation/C6E0F9C1-A286-4BA9-9A7A-3D7EB2729124/d
js: text path: x:/private/var/folders/w5/x732bbkd4ddct46vbbt4nmc80000gn/T/AppTranslocation/C6E0F9C1-A286-4BA9-9A7A-3D7EB2729124/d/texts/default.txt
it makes no difference if i try to include the files needed within the app and in general for distributing to other, i'd like them to be able to save and retrieve presets files within the same level folder as the app (not inside).
admittedly, i don't understand how translocation works and how to deal with it, i just know that none of the people i work with can use my software anymore due to path issues and neither can i. any advice would be greatly appreciated.
Removing quarantine xattribute before running the app
would prevent translocation.
sudo xattr -rd com.apple.quarantine path to the app
Among many articles and threads :
www.synack.com/blog/untranslocating-apps/
read it to get some idea about what happens.
To prevent getting quarantine set, one could also use
curl to download app.
one example :
sudo curl -SL www.some-domain/files/MyApp.app.tar.gz | tar -x -m - -C /Applications
File must be tar or tar.gz compressed, the idea is to download
compressed stream and extract it directly into /Applications, without
storing archive on the disk.
or download plain zip file :
curl -o /Applications/MyApp.zip www.some-domain/files/MyApp.zip
and unpack it by hand .
This all worked on high hierra, on mojave
I did not do any tests, but imagine it's the same, at least
for the moment.
in mojave Terminal.app needs full disk access enabled
in privacy prefpane to be fully functional.
Hey guys, is anybody aware of any changes going on between apple and Max? Two months ago I was easily able to release my app by simply code-signing it. Now I updated the app and tried to release a 4.1 version, and even though I codesign the .app bundle, when trying to open it on another machine it flags up saying:
"AppName" can't be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more info
I can assure you this was not happening with the release I did a few months ago. Any thought on what this might be and how might I try to solve it? Thanks!
I code signed mine (I had to choose the correct cert) and got it to open via contextual menu.
Hi @Audiomatt, thanks for the prompt response. Yes, contextual menu works fine for me as well... but I'd have to ship the app with info on "how to open"... Not that big of a deal, but curious considering that only two months ago I didn't have to jump over this hurdle!
@Niccolo, I started having the same problems with Mojave even after proper code-signing which is why I thought maybe Apple is moving forward with requiring notarization as well.
@Dan Nigrin: Thanks a lot for you GREAT work! But questions remain for me. First of all .... your routine works! - sometimes ;) (strange). As some posts above recommended, i removed "maxpluginscanner" from the app after building the standalone. At this moment the app launches (without "maxpluginscanner") and works good. After coded the app it wont start and crashes. Could it be a) that the removing of the "maxpluginscanner" causes troubles in conjunction with coding the app? and b) do i have to add a new certificate (distribution certificate?) for every process of coding or notificating although it is always the same app version? And c) thank you very much.
O.
Hi @Otger,
(a) I doubt removal of maxpluginscanner causes any problems related to codesigning
(b) I'm not completely understanding what you're asking, but each time you change your application in any way, you do have to codesign it again.
All that said, considering what @Jeremy (who is a Cycling '74 employee) said above - I would not invest too much energy around app notarizing at this point, as it seems there are some tougher problems that need to be addressed by Cycling first.
Hi @Dan,
(a) ok, so i have to wait till cycling found any solution that a standalone comes through the notification routine of apple. This will cost me some money :( I will write to cycling my experiences. Perhabs it will help them. (Btw how do other companies manage this edge?)
(b) Do i have to request new certificates in my developer account for new releases? I think yes, because its technicaly a new app. But do I have to request new certificates if i only want notifying (for what reason ever) the same release twice, without modified anything in the app?
I'm a bit nervous that this thread has co-mingled two different issues, and that it's become confusing to follow: the original discussion was around getting Max standalone applications to be notarized, and the second, more recent one around simply getting the applications to be developer-signed and successfully deployed over the Internet such that the Mac doesn't complain that the application is "damaged" with no easy ability (for end users anyway) to open it.
Despite some initial success I had with the first (notarization) issue, it now seems that there's some fundamental issues related to how Max works currently that will prevent notarization from being successful, and that Cycling will have to attempt to address. So I'd suggest that discussion of those issues remain here in this thread.
Regarding the second issue, at least for me, I've not seen affect me or my applications yet. However it does seem to be real issue considering the number of people who've reported it. I'd suggest if this is still an issue for people that a new thread be started (with a pointer to it from here please), so that we can try to get to the bottom of it.
@Otger - although I'm not positive, I think what you're referring to in (a) is the 2nd one of these two issues. And with respect to (b), no, you don't need a new certificate for each new release - you simply need to sign each release with that same developer certificate.
Seems like apple has relaxed the requirements a little, at least for now:
https://developer.apple.com/news/?id=09032019a
I wonder if that will help us? It says this will be in effect only until Jan 2020, so its not a long term solution.
Wow, thanks for the heads up Arvid, I do think that might be useful. Especially the very first bullet, and perhaps the second too.... I wonder if this means that everyone should hurry and notarize their existing apps prior to Jan 2020, and get "grandfathered" in that way? Hmmmm.
Aaand it is! I just successfully notarized, unzipped, stapled, re-zipped, re-uploaded, then downloaded and successfully ran a code-signed Max standalone compiled in Max 7.3.6. And it even gave me this nice dialog
and the MacOS asked if the app could use the mic when i first launched it, which I had never seen before with my app.
If your app is packaged in a zip archive:
the name of the zip file does not seem to matter to notarization
you can't staple to the zip, so you'll have to staple to the app package(s) in the zip, then re-zip. Apple's docs say to staple to every item, but i don't think its necessary (or possible) to staple to normal files like PDFs or RTFs that are packaged with the app.
Awesome, thanks Arvid! Can you elaborate a bit on what changes you made to the steps outlined at the top of the thread to get where you did? Did you just remove the "--options runtime" bit at the end of the Step 1 codesigning process, and everything else the same?
No substantive changes to your method, Dan. I literally submitted the same .zip I was already distributing containing my code-signed standalone, got an "approved"email (and status via terminal as you described how to do it), then stapled the .app, re-zipped and re-uploaded to my webspace.
Then I re-downloaded that .zip from my site and ran the enclosed software to check. Success!
One odd thing though: the first time I ran the notarized app that I re-downloaded, I got a bunch of identical errors in the standalone's Max Console about sysmidi (i think) not understanding something… I forget what it was - didn't screenshot - but I quit and ran again and didn't see it again. They didn't come from any max object in particular. And it could have been a fluke. I have lots of MIDI devices plugged in via USB and sometimes my MIDI setup does misbehave after long times between reboots with the computer going in and out of sleep… so just a warning to look out for maybe. Edit 2019-09-05: this did not happen again with another standalone.
Edit 2019-09-05: Also it seems you don't really need to re-zip and upload the zip again if you didn't make any changes to the app bundle. It seems existing zipped .app bundles that have had an identical copy notarized will be recognized as such by macOS, even if they themselves have never been stapled. So stapling doesn't actually change anything about the .app. I'm guessing all it does is tell Apple's registry of notarized packages that you do indeed want to connect this notarization with the .app package publicly.
And yes – this is all without hardened runtime (i didn't even re-sign the standalone).
Great, thanks Arvid. I have a similar use case, in that I have many existing apps (bundled as .dmg's) for my users. So if I understand correctly, I can just go through the process you did with just the .dmg, and it should just magically work - will give it a try.
If I understand Apple's site though, if I'm not mistaken, I shouldn't even have to update the .dmg's that are on my site; I think once an app is notarized, Gatekeeper checks online to see if that app's bundleid has been notarized, and if so it lets the app proceed. This is why notarization works even for apps that have already been distributed - see https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
Will report back after I've had a chance to check all this...
Yup, I can confirm your experience too Arvid! I took an existing .dmg, with an enclosed app that had previously been codesigned, but NOT with hardened runtime status, and just notarized and stapled it (Steps 3-6 from the top of the thread, with Step 5 being optional). All went flawlessly, and I was able to run the app after downloading that new .dmg from the Internet onto a 10.14 machine (I don't have a Cortana 10.15 beta to test on). I got the same message you did when the app was opened for the first time, saying "Apple checked it for malicious software and none was detected."
I'm optimistic that this means our standalones will continue to run on 10.15 - at least for now. We still do need to get to the point where we can get the hardened runtime status in place, but for now I'm not complaining!