Advanced Max: Standalones, Part 5
In part 5 of our series on making applications with Max, I'm going to look at how to code-sign your standalone application. This 12-minute video tutorial demystifies this critical step for distributing your standalone application on the Macintosh platform.
by Timothy Place on May 8, 2018
Sweet as!
nice one, thanks!
Once I updated Xcode it worked like a charm.
I like both: The standalone feature and the fact that Cycling '74 provides a lot of a tutorials and use cases.
1. Max can be seen as an interactive development platform with a lot of use cases but also as a DSP training course with running examples and video classes :).
2. There are many development platforms for audio. But every else, which I checked, needs a lot of work to get started. Some have stability problems or are installation nightmares (especially some open source projects), others are more difficult to learn, next ones have bottlenecks with building GUIs. When I started working with Max (it was Max for Live in the beginning) a few months ago: It worked out of the box: Install, get intro tour, tutorials and a running example for every object in the help. Additionally tons of example patches, open high level objects like beap and: Great video tutorials to really get final results not just a theoretical possibilty to get a result.
3. This excellent documentation is part of what Max's USP is in general: A true RAD (Rapid application development) platform. That means: It can be regarded as strategic. I strongly recommend, that marketing and sales offer it also for other applications not just for music and video artists. In many cases just a few use case patches are necessary with no or nearly no additional development costs. Minimum effort, max. result. I already have mentioned measurement technology, where an interactive platform is required, that connects to measurement instruments (SCPI commands are text messages!) and can do signal processing and visualize it. Connection via LAN or a local pyvisa python server or with minimum development effort (if somebody can build externals) a visa wrapper external (wrapper because only forwarding SCPI text messages to the visa driver lib). Especially the fast handling of GUI elements in Max and many other high level objects as well as the excellent documentation of objects (incl. copy and paste example patches) saves a lot development time. Compared to the development in C++ I experienced at least a factor of 10 in development time! Another B2B could be the industry camera market using jitter (pattern recognition in production quality control, ...). In B2B RAD is interesting, because corporates not just have money, they also give it to you if you help them to make more, because time is money for them. Additional to increased sales and diversification, new interesting markets keep Cycling' 74 in an independent position not only from a single industry sector!
Actually, certificate creation worked but codesigning didn't. Terminal says:
is already signed (response to -s)
code has no resources but signature indicates they must be present (response to -v)
Friend that I sent patch to got "corrupt, throw away" message
: (
Certificate generation worked but codesigning didn't.
Terminal says "is already signed" with command -s
says "code has no resources but signature indicates they must be present" with command -v
Sent patch to friend, warned it was corrupt and should put in trash.
Tried codesign -f -s "certificate" -v --deep path-to-patch
but got "resource fork, Finder information, or similar detritus not allowed"
: (
Thanks @VOKARS! I'm glad your loving Max! I loved it so much that after a few years I got my dream job working on it and haven't looked back!
@JB This is a bummer! Lots of people end up having some hiccups and frustrations like this.
Xcode version, MacOS version, etc. all have an impact. Sometimes an app gets partially signed and then fails in the middle -- that can lead to a situation like you describe. In that case you can "unsign" the application. This link shows how to do that: https://stackoverflow.com/questions/20875927/how-to-undo-codesign
Does that app that I showed for verifying the code signing have anything interesting to say in it's summary?
RB app shows that the Cycling 74 certificate is in place
"Developer ID Application: Cycling '74..."
Requirements and resources didn't pass static validation
9 executables are signed by "Apple root CA", "Developer ID Application: Cycling '74
Another attempt using codesign -f -s resulted in "resource fork, Finder information, or similar detritus not allowed"
Afraid to try --remove-signature as someone in the thread said then I wouldn't be able to sign the binary thereafter.
Thanks for your help!
If there is a signature on the app already you won't be able to sign. Max should be removing the signature automatically when you build your app.
Googling for "resource fork, Finder information, or similar detritus not allowed" turned-up this link: https://developer.apple.com/library/content/qa/qa1940/_index.html
Not sure if that helps?
If you get "resource fork, Finder information, or similar detritus not allowed"
run in terminal:
xattr -cr <path_to_app_bundle>
then sign as usual (codesign -s "certificate" path_to_app)
There are two different certificate and codesign options:
Codesign for App Store Distribution
codesign -s "3rd Party Mac Developer Application: <name (number)>" <path to app>
For direct distribution
codesign -s "Developer ID Application: <name (number)>" <path to app>
Thanks so much for this.
Just a note to say this part doesn't appear to be linked to from the other tutorials...
Thanks, Roger! We'll try to get that fixed up!
Dear Timothy,
any place it is possible to download the patches from?
Thanks!
Bw. Ejnar
With app build in Max 8.0.5, attempting to code sign with just the -s option results in "... is already signed" error. Attempting to sign with -f -s applies the signature, but then fails with "code failed to satisfy specified code requirements".
Did something change in Max 8 that's preventing this from working?
i should note that the "is already signed" error also occurs with a simple app with nothing but a standalone object in it, and no modifications whatsoever (other than excluding C74/gen/etc resources in Standalone inspector).
You say that CEF support cannot be enabled if we are to submit our patch to the App store - why is this?
This is very bad news for me, because my patch depends on having jweb working properly, which is doesn't seem to do with CEF support removed...
Btw, I'm also getting the "is already signed error", (just trying to certify for direct distribution atm...)
Roger, i was having some issues with "is signed" too. Not sure exactly what it was that fixed it - it may have been either a computer restart, or rebuilding the app on the code signing machine (previously app was built on a different machine running 10.14, i was attempting to code sign on 10.10) I think I maybe had also omitted unchecking some of the standalone include options outlined above on my first build. Anyway, after some of that jiggery pokery i was no longer getting the is signed error.
Just a quick note (and a confirmation that we're investigating this): the capabilities of the 'codesign' tool appear to be vastly different from one OS/Xcode release to the next. On my Xcode 9.2.1-based development system (10.14.4), I can use 'codesign' to completely strip the standalone of existing signatures and then apply new ones for a working, signed executable. On an Xcode 8-based system (10.11.x), I cannot. We'll let you know more as we've had a chance to narrow this down and eliminate a few variables, but it may be that this process will require specific versions of MacOS/Xcode/Command Line Tools. Which would be unfortunate, but better than it not working at all. Watch this space.
In case this info is helpful - I managed to codesign my app (for direct distribution) on 10.10 with max 8.0.5 and Xcode 7.2.1. I used the -f -s options when codesigning. App passed gatekeeper on both my 10.10 system and a 10.14 system.
Excellent, thanks - I will indeed be watching this space!
The -f -s method is working for me both on Xcode 8 and Xcode 9-based systems. I haven't had a chance to try Xcode 10 yet, which I'm sure has been carefully engineered to make our lives harder.
Hardened Runtime and other exotic requirements are currently unsupported/impossible given our standalone format. We'll be doing some work on this in the coming weeks/months, though.
So, updating to OS10.14 might be a way forward with respect to the "is already signed" issue?
I've been avoiding it because it looks likely to cause problems with my audio interface, but I really need to move on with this, so if there's a consensus that 10.14 is working, I may bite the bullet...
10.14 is fine (my audio interface problems were fixed in 10.14.4 or so, when Apple fixed up some USB issues FWIW). But as mentioned above, one of the systems I tested on with was OSX 10.10, so it's not necessarily an OS-dependent thing. The 'codesign' tool changes from Xcode to Xcode, though, and that's likely the determining factor more than your OS version.
Excuse my ignorance, but if I'm using the Terminal to do the code signing, then is it still dependent on which version of Xcode I have installed?
I'm using Xcode 9, which you say worked for you, but afaicr, I was able to run the Terminal commands before I had any version of Xcode installed.
As you can see, I'm somewhat out of my depth here...
To the best of my knowledge, the codesign tool is installed with Xcode and/or the Command Line Tools. Maybe it's preinstalled, but I doubt it and I don't have a virgin system to test on. As such, the version (and capabilities) of codesign will reflect the Xcode version. For instance, the Xcode 8 version of codesign doesn't support the "--remove-signature" flag IIRC. I have Xcode 9.4.1 on my dev machine at the moment, and the codesign I have worked fine with the tests I performed.
Sorry to crosspost, but as you work for Cycling74, you should be aware your procedure is no longer sufficient. First, it's necessary to specify the --deep option now for code signing to work at all, thanks to Dan Nigrin for helping sort this out, but you probably already know that. Second, and the reason I am letting you know because you might not find out otherwise, is that new developer apps are still rejected on Mojave.
This sent really surprising because of a note that appears on the Apple website when you request a certificate for distributing outside the Mac store:
While I understand the changes recently have been quite rapid and there are changing requirements every macOS release, I do have to voice disappointment at the way Cycling74 has been supporting standalone. It's been nine years now since I started trying to make working standalone and I have never been able to do it at all without months of substantial help from other users. There is STILL no working example of a project anywhere, and there is no documentation or directions at all on how to include files that may be modified by a user. This has reached last chance stage with me on the next macOS Catalina. If it doesn't work out the box on Catalina, I have to say, it's reached the point where it's easer to develop in C++ on Juce.
Just glancing through this quickly...seems like a bit of confusion between code signing and notarization, the latter needing 10.14 + Xcode 10
I’ve used this to notarize an existing app that was already codesigned. About 1/2 after running this (with my real credentials of course) I got an email back that the app was now notarized and sure enough, it opened in Catalina without the warning.
altool --notarize-app --primary-bundle-id "your.bundle.id" --username "yourAppleId@me.com" --password "your app dev password" --file “path to your application”
It's no confusion. Code signing is not sufficient for new developers, as I said, it also requires notarization. This was not explained before, and moreover, it no longer works out the box with Max 8.0.8, I can confirm other user reports on this. It could be because, despite setting not to include CEF as instructed, 8.0.8 still includes cef in the bundle, but its going to take some time to figure out.
Just as other users have reported, my app passed notarization after putting it in a zip file, but after stapling as instructed on Apple website, uploading, downloading, and trying to open it, yes it now passes the gatekeeper test. But now the patch windows do not open. No menu. Nothing.
Every two years, I try building a standalone, and every single time, there's a different problem like this. This is the fifth time since 2009. I'm sorry but Im really running out of patience with it.
Aha. Figured out a workaround for new developers on 8.08
1: codesign .app file with --deep option
2. Put in zip file and Notarize it.
3. THROW IT OUT. the process of notarization destroys the file. But you are now a notarized developer!
4 codesign the original file with --deep option AGAIN. DO NOT NOTARIZE AGAIN.
Now you can distribute it independently and it works, because you've already been recognized as a notarized developer, the second time, you can just codesign it. Of course there's no way of getting it on the Mac store, and it doesn't open files from unapproved locations, which is the next problem I have to solve. Good night. Sorry for crosspost.
For those interested in Apple's new security requirements and how to make your app work with them, we have published an article address it here.
It appears it's someone else's turn to take you up on that. Happy new year to you )
Hi Tim.
Thank you for these very helpful tutorials.
I have been having an issue code signing Mac standalones created in Max 8 on Catalina using the hardened runtime option (which is required for notarizing the resulting application). I have created a topic reporting that issue (https://cycling74.com/forums/issue-with-code-signing-mac-standalones-with-hardened-runtime).
I have consulted the article you referred to in your last post above but that does not resolve the issue.
I am hoping for any insight from your or other helpful people on this forum.
Thanks,
Adam
The issue I reported above was resolved by Ben Bracken on that topic's page: https://cycling74.com/forums/issue-with-code-signing-mac-standalones-with-hardened-runtime
The bottom line is that for the runtime-hardened (a requirement for notarization) code-signed standalone (generated with Max 8.3.1) to load externals and work correctly, code signing must be done while adding the entitlements option with a proper entitlements file.
Hi Timothy!
Thanks for a great 5 part video tutorial that I really enjoyed.
Is there any chance to get an updated video of the part 5 with code-signing since so much have changed from the Apple part of things?
I would really appreciate it since your videos are so entertaining and easy to follow along.