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.
    All the tutorials in this series: Part 1, Part 2, Part 3, Part 4, Part 5

    standalones part5 signing


    • May 09 2018 | 7:28 pm
      Sweet as!
    • May 12 2018 | 7:02 am
      nice one, thanks!
    • May 12 2018 | 10:54 pm
      Once I updated Xcode it worked like a charm.
    • May 14 2018 | 9:00 am
      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!
    • May 14 2018 | 6:07 pm
      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 : (
    • May 14 2018 | 7:35 pm
      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" : (
    • May 14 2018 | 9:42 pm
      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!
    • May 14 2018 | 9:47 pm
      @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?
    • May 15 2018 | 12:38 am
      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!
    • May 15 2018 | 2:41 pm
      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?
    • May 16 2018 | 7:21 am
      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)
    • May 18 2018 | 3:28 am
      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>
    • Jan 04 2019 | 2:15 pm
      Thanks so much for this. Just a note to say this part doesn't appear to be linked to from the other tutorials...
    • Jan 08 2019 | 7:48 pm
      Thanks, Roger! We'll try to get that fixed up!
    • Jan 24 2019 | 2:49 pm
      Dear Timothy, any place it is possible to download the patches from? Thanks! Bw. Ejnar
    • May 06 2019 | 8:50 am
      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?
    • May 06 2019 | 9:12 am
      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).
    • May 12 2019 | 7:00 pm
      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...
    • May 12 2019 | 7:45 pm
      Btw, I'm also getting the "is already signed error", (just trying to certify for direct distribution atm...)
    • May 14 2019 | 5:24 am
      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.
    • May 14 2019 | 6:29 pm
      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.
    • May 14 2019 | 7:07 pm
      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.
    • May 15 2019 | 9:47 am
      Excellent, thanks - I will indeed be watching this space!
    • May 16 2019 | 1:49 pm
      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.
    • Jun 12 2019 | 12:39 pm
      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...
    • Jun 12 2019 | 3:59 pm
      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.
    • Jun 13 2019 | 12:59 pm
      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...
    • Jun 13 2019 | 1:03 pm
      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.