Thanks, this is fantastic. You should be on the C74 payroll. bookmarked

This is a great resource! Thanks Josh for posting it. You said that /Contents/Frameworks/libmozjs.dylib/ caused submission issues, can I assume that your standalone didn't have any javascript ?

I have a standalone that I would like to have in the App Store but it uses a lot of javascript and I think it would require libmozjs.dylib . Has anyone successfully submitted a standalone that uses javascript to the Mac App Store ? If so any tips ?

Well done Josh! As one of the co-authors of the original "Your Max Standalone on the Mac App Store" document that you link to above, I've been meaning to update it as SO much has changed since we originally wrote it - but you beat me to it! Very nice and comprehensive as well, great work!

If I may though, a few corrections and suggestions though (including one for @chris_dech re: Javascript):

Part 2, Step 1: Should definitely include info about unchecking CEF Support, Gen Support, and Include C74 Resources if they are not needed. CEF Support in particular adds a huge size to your application, and Including the C74 Resources adds a ton of work in the subsequent steps that could be minimized by not including them.

Part 2, Step 3: Although your approach works (naming the app icon as "Max.icns"), it's a bit abnormal to have a Mac application whose bundled icon file is not named "APPNAME.icns", where APPNAME equals your app name. So best to name it appropriately, and then when building your standalone app within Max, use the appicon command in the build script.

Part 3 I've been successful in getting the libmozjs.dylib library included by simply codesigning it in the subsequent steps. This was as recently as early this year (2018) - not sure if you tried that or whether something's changed with Apple (which is always possible!). Here's the example command I used for that recent app:

Also in general - I can't emphasize enough the importance (to minimize subsequent headaches) the removal of files you don't need from the application bundle. For example, in a later section (Part 5, Step 3), you show the need to codesign the MaxPluginScanner executable. Well, if your app doesn't use plugins (i.e. the vst~ object), you can safely remove that file and not worry about codesigning it. Same goes for lots and lots of other files - in particular are the many .mxo files within /Contents/Resources/C74/extensions/

Part 5, Step 3: In my experience you don't need to codesign the actual entitlements.plist - that file never gets sent to Apple either.

Part 6, Step 2: In the past I've had trouble uploading to Apple using the "built in" Application Loader. Perhaps this has been fixed now, but I found that I needed to download and use the older standalone Application Loader v3.0, available directly from Apple.

If I spot any other things I'll be sure to mention them - and again, thanks! In addition, I've started to research the things that will be necessary for app Notarization, which will ultimately be required (optional in Mojave 10.14) even for apps outside of the App Store.... See thread I started: https://cycling74.com/forums/apple-notarizing-for-mojave-10-14-and-beyond

Dan,

Thanks for the feedback ( and for your original tutorial! ) I have updated the post to reflect your suggestions.

Here is the problem I ran into with libmozjs185.dylib

Thanks Josh, and ah crap, that explains re: Javascript lib. The app that I recently submitted was an update, and it was roughly around Feb 2018 or so....

Damn, that's important. Will now have to see if there's any way to update that library....

Just a couple small but important details from the edits you made to your original post:

* You wrote "To reduce file size, you may uncheck CEF Support, Gen Support, and Include C74 Resources" - but this is only true if those things aren't needed in your App! So obviously if you're using gen you'll need the Gen Support, and if you're using jweb (and maybe other objects, not sure?) you'll need CEF support.

* You changed the part about the .icns file, but you omitted adding the appicon line within the standalone build script in Max. You don't *have* to do that, but then you do need to make a change manually in the Info.plist file, to specify the correct filename for the Icon entry...

can you use lipo or ditto to strip i386 code from libmozjs?

That's a good suggestion - definitely worth a try. I don't have anything to submit now but maybe someone else could take it up? I'm guessing the syntax would be:

??

For anyone using iCloud drive, don’t try and codesign or package build on your Desktop or in your Documents folder - you will almost certainly end up with ’Finder detritus’ issues, which will cause your package upload to fail...

lipo command works. I can't comment on whether or not this affects javascript functionality within the standalone...but it does allow the app package to be approved for submission.

example of the command I used

Good to know, thanks for reporting!

Hi Dan and thanks for the update, Josh! Everything works fine above. I am unable to successfully codesign and submit because of the MaxAPIImpl.framework and MaxAudioAPIImpl.framework. The plist is identical to their associated frameworks and it's getting rejected. I tried changing the executable file row to the correct executable with no avail.

Hi James - I think those new "implicit" frameworks are needed for the hardened runtime stuff in Mac OS 10.15. Wondering if maybe for the App Store, you could just delete all those "Impl" frameworks, and see if the standalone still runs?

I tried but could not successfully load any audio objects.

Hmmm... afraid no other ideas off top of my head... Maybe the Cyclists will come to the rescue!

Figured it out. Turns out the Frameworks are already codesigned when building an app from Max. I edited the two Implicit frameworks' plist to reflect the correct name and then removed and reloaded the code signatures in those Frameworks using codesign --remove-signature (Framework name).

Excellent, great work James!

That worked to some degree but I am still not getting through with these frameworks so after three days of pretty much steady work, I am throwing in the towel and building my app with Max 7. See you on the other side!

@JAMES If you ever do circle back around, I'd be curious if you followed the instructions here: https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization/

You should just be able to re-sign and notarize everything with the -f flag. The "old" way of stripping the signatures (--remove-signature) seems to break/prevent subsequent signing attempts.

thanks for the reply Ben. Notarization is ok but I am still not able to successfully get the implicit frameworks' plists through, though. Thanks for the tip about --remove-signature. I was able to just use the --force flag and get that to work.

My app has been approved for sale on the app store. Thank you to all for the info in this article and past articles and threads and my collaborators for the original article on Max standalones in app store, Dan Nigrin and Oli Larkin. For late 2019, there are a few adjustments that need to be made (or at least updates) in order to get a standalone into the app store. Here are my thoughts / experiences 1) Downgrade to Max 8.0.8 to build the app. This is because later 8 updates provide Implicit frameworks which are not able to be successfully submitted at this point. More on this later, if relevant 2) Max 7 will not work at all as signing the app ruins permissions on all the embedded .mxo files 3) Notarization for the app store is not necessary, however codesigning with entitlements is 4) It is only necessary to codesign once using the --deep and --force flags. Max has its own signatures so --force will overwrite them. Signing with --deep on your entire app will also sign all the nested frameworks and .mxo files. You do not need to sign each individually

5) You can ( though I do not recommend this - I did it after a while to prevent going insane) make adjustments to the underscore in ad_coreaudio in your Max 8.0.8 and it will flow through to your app build. You can even add the Identifier lines to the .mxos but I would not advise tampering more with Max than necessary, although you will presumably only be using it to build your apps. I also kept a spare .dmg with the complete and untampered 8.0.8 on my desktop and had to use it several times. 6) xattr is necessary to fix the resource fork error caused by many custom .icns files but you only need to use it once with xattr -lr -cr

7) IMPORTANT - hardened codesigning is not necessary unless you need your app notarized, which is not necessary for the app store as appstoreconnect and the manual review provide all the checks that notarization would. Hardened codesigning will likely brick your app.

8) Apps made with Max 8 load much slower than those built with 6 and my menubar kept crashing after codesigning. I realized that this might have been specific to my machine so I submitted the app anyway. Time will tell if this continues to be a problem.

9) As another commenter pointed out, building and codesigning is not advisable on iCloud folders. To be safe, build to your app to your local directory.

10) It's a good idea to add "Copyright (human-readable)" key to your main app's plist. I'm not sure this is necessary yet. Also you need to increase or change bundle versions every time you upload a package to appstoreconnect.

Awesome thanks James!! The only thing that's a drag is the downgrading aspect, since 8.1 or greater is necessary for hardened runtime work, for apps not going to the app store... Hopefully the Cyclists will advise though on that issue.

Thanks, Dan. I couldn't get my app to function after hardening it (none of the max or msp objects loaded) but maybe others will have more luck.

Any idea which of these steps are necessary just to get past Gatekeeper, particularly in Catalina? I'm doing beta testing now, which means I make regular updates based on bugs, feedback etc. Testers who have updated to Catalina can't get my standalone past Gatekeeper. (There is an error that the program is "corrupt" or something..... which in earlier OS versions was fixed by doing "master disable" in Terminal, but computers belonging to an institution usually have this blocked, so doesn't work for them either). Typical steps which are supposed to work (ctrl-click to open etc also don't work). Which of these steps are necessary and which of these steps can I skip? This is a lot of hoops to jump through every time I want to send out a new version to the testers! (Particularly updating alllll the plist files.) I can't test this on my computer because it obviously works for me, and I can't ask beta testers to waste their time either trouble shooting this with me. Any thoughts?

SSINGH: Apple's security requirements change so frequently, that it is hard to keep up! I'm sure there are a few more steps necessary now. To be honest, I have not gone through the process since before Catalina, so I am not personally up to date. Someone should make a new guide for 2020. 🤔

As far as the time it takes to edit ALL the plist files, I would recommend doing your beta testing OUTSIDE the App Store, and just uploading to the store when it feels solid. Actually, at one point I tried to re-submit a few times in a week and Apple marked my submission as spam. 😂 So, don't go overboard with that. Also will save time having to update the plist files.

Once the app is IN the App Store, you won't have to deal with Gatekeeper, ctrl-click to open, etc... so it really is the way to go. There is also a way to distribute outside the App Store, and have the app registered with Apple to bypass these things. But that still requires the Apple Dev Program and (I believe) all the plist junk.

JAMES: Thanks for your updates. I'm just now seeing them, you bring up some great additions and adjustments! And congrats on getting in the App Store!

Thanks for the reply Josh! SSINGH, I'd be curious to hear if you tried codesigning your app in hardened mode and notarizing it. These steps are not necessary for the app store, but they may allow beta testers to bypass the gatekeeper. I'd also be interested to hear if you codesigned with entitlements and what entitlements you are using.

Agree with James Howard Young - @SSINGH, you should follow the steps outlined on Cycling's page they set up dedicated to this topic: https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization .

One important point to note though is that Apple is going to be tightening up things further, after an initial grace period, on Feb 3 - this will *require* hardened runtime status to be in place: https://developer.apple.com/news/?id=12232019a

Finally, note that this thread is meant to be dedicated to getting apps up and available on the Mac App Store, which is not the same set of steps to just be able to release an application and have it work on Catalina (or otherwise). So if the latter is what you want to do, you'd be better off taking a look at this thread instead: https://cycling74.com/forums/apple-notarizing-for-mojave-10-14-and-beyond

Thank you all for your help. I will move my further reports of problems and successes to the other thread as I am indeed not planning to put this in the app store yet.

OK, time for me to jump into the fray.

I haven't needed to update my existing apps on the App Store, until I recently realized (and my users did too) that they weren't working on Catalina. The app issues a ton of messages upon startup along the lines of:

"message.mxo cannot be opened because the developer cannot be verified. MacOS cannot verify that this app is free from malware. MyApp created this file on an unknown date."

These apps were built with Max 8.0.6.

So today I tried a shot at building with Max 8.1.1, and before even dealing with any Apple issues, I've run into a problem in getting the signed app to run correctly on Catalina, when signing with the App Sandbox entitlement set to TRUE which is required for the App Store. If I set it to FALSE, the app runs fine, but when set to TRUE, I get similar errors for the two *3rd party* externals I am using, like this example (from Jasch's externals collection):

In addition to the previous entitlements I had been using successfully on previous App Store builds, I tried including Disable Library Validation set to TRUE, but that didn't help.

The command I'm using to codesign is: codesign -s [my developer ID] --timestamp --deep --entitlements [path/to/app.entitlements] -f [path/to/standalone.app]

Any ideas?

Hi Dan. You need to exlude the externals using excludeexternals true from being built with the standalone and then manually include them in the externals folder of your app bundle (they should be there by default if you check "include c74 resources" in the standalone object.) You then need to add your bundle ID to each .mxo. This is tedious if you need to do each one so what I did was generate a list of the externals being used when I built the app, then I added the bundle ID only to those I needed, deleting the rest. Once you have edited all the .plist files you can codesign the whole app with deep and force once. I have just given a rough overview here, assuming you can ask for explanation on any item if necessary. Good luck!

I don't mean to be harsh on the OP or anyone else posting here, you're all just sharing good and useful information, and I appreciate that. But I have to say that Apple's all-out attack, with Catalina, on end-users and independent software development is disgraceful. As far as I can see, nothing good can come of it... I'm out.

I understand your frustration and perhaps creating apps for app store with Max isn't the best solution, which is why I will be using JUCE from now on to develop macOS and iOS apps from within Xcode. But I do have to give cycling74 many, many thanks for making these tools available and for always remembering the "needs" of standalone developers. They provide excellent support and most of it is seamless.

Thanks James! Does that command (which I presume goes in your collective script?) exclude Max's built in externals too, or just the 3rd party ones?

Yes that command goes first in the collective script and excludes all externals from being built with app, including the built-in. It will generate them in the externals folder in the bundle where the bundle ID can be manually added to info.plist

James, I agree with everything you said about Cycling '74. The object of my remark wasn't Cycling '74 at all, but Apple, and the closed software ecology they've set (and seem to be setting) up for end-users and independent software developpers, especially with Catalina...

Are you referring to the sandboxing or the hardened mode that they will be implementing?

Got it, thanks. Now I understand what you were talking about earlier in the thread with all the info.plist stuff... What a pain!

Cycling, can you guys help with this? Maybe just a way to exclude *3rd party* externals, making the task described above a bit more palatable?

Excluding only third part externals likely won't work as you still need to add bundle id's to built-in mxo's. You probably also need to build with 8.0.8 since later versions use the implicit frameworks which won't work

James, sandboxing is certainly a part of what I'm alluding to, yes, but hardly all or even most of it... OpenGL, 32-bit deprecation, Notarization, etc.. This discussion could take us far and wide, and away from the core purpose of this thread... I don't want that to happen, I only meant it as a passing remark.

Ah, understood on the bundle ID's, and also on the Impl frameworks. Still hoping that the Cycling folks have a way around both of these things (having to update every external's Bundle ID, and also the Impl frameworks), don't want to be stuck on an older version of Max just for this...

Can you clarify exactly what the problem was when submitting to Apple or whatever when using the 8.1.x version of Max, and the Impl frameworks?

The plists can't be edited ahead of time otherwise they could just add bundle id's to them all but they have to match your specific app.

The problem with implicit frameworks is that the executable name in the plist refers to the original framework. You can edit that, but it doesn't fool anything. I tried to recreate the symlink with the original name to try to force it to go through but that didn't work either. I worked on this pretty steadily for about two weeks before giving up.

Understood on the plists (and am wondering if Cycling could automate that as part of the standalone building process, perhaps as an option?)

And also understood on the frameworks stuff, I've been trying this AM and got your same result.

So guess it's in Cycling's hands...

As far as you can tell, your App Store apps built with Max 8.0.8 are behaving OK on Catalina?

My apps built with 8.0.8 crash when the menubar is clicked for some users (including me) We have narrowed down the what but not the why.

OK thanks James, very helpful. If I get to that point I will report back if I have the same issue...

Just following up - using the steps James outlined above, my app (an update to an existing one) was approved for sale on the store. I do NOT have any issue with the app crashing on menubar clicks (though I have had one report of a crash/freeze upon startup - investigating that one).

That's excellent. I experience the menubar crash and one user has reported it. Cycling did not get it and neither did several users, nor App review, apparently. I can confirm that it involves the metal framework and have submitted a request for code level support at Apple which they are investigating right now.

Hi James, did you ever get feedback on this one? Looks like I also have some end users reporting crashing as well, but that I've not been able to reproduce. The closest I've had is occasional spinning rainbow wheels soon after startup for several seconds, but which eventually go away. Wondering if it's in some way similar to yours...

Nope never got any further with it. I've got about 80 units out plus a a couple hundred updates but only one complaint. I've got a few users confirming that they don't have a problem plus the cycling people not experiencing the problem as well. I do however have the problem so I know it exists but it bothers me that I can't put my finger on it.

I've gotten loads of updates (2k), as well as several new sold as well, and as best as I can tell only a couple of reports of problems. That said, I know that many people simply don't report the problems they might experience... Anyway, thanks for the info!