I have successfully submitted my app to the Mac App Store. Yes it is possible! There seems to be a lack of updated information on this topic, so I have created this guide in hopes of helping out the community. It is important to note that this process will vary for every app, based on which externals/frameworks/extensions are present. You WILL get error messages the first time you submit your build to App Store.
STEP 4: App Store Connect
Create a profile in App Store Connect for your application.
This is where you edit how your app’s display page will look within the App store.
PART 2 | STANDALONE PREPARATION
STEP 1: Edit main patcher inspector
View > Inspector Window
- Disable Workspace [X]
- Open in Presentation [X]
STEP 2: [standalone] object
create a [standalone] object in your patch
- open [standalone] inspector
- update "Bundle Identifier" to match your Apple App ID (com.website.appname)
- update "Preferences File Name"
- Can't Close Toplevel Patchers [ ]
- Disable Loadbang Defeating [X]
- Status Window Visible at Startup [ ]
STEP 3: Reducing File Size with [standalone]
To reduce file size, you may uncheck CEF Support, Gen Support, and Include C74 Resources. However, these can be essential for certain functions (ie. Gen Support is needed if your app uses [gen~], CEF Support is needed if your app uses [jweb]).
When in doubt, try your standalone with and without. My app worked fine with all of these unchecked. And the file size dropped from 315MB to 65MB. (More info HERE)
STEP 2: Add bundle identifier to every Info.plist
Yes. Every file that contains a Info.plist, must be updated. However, all that is necessary is to add your Bundle Identifier. Simply, search info.plist in your application’s folder, and copy-paste the Bundle Identifier row from your main Info.plist file.
*For (MSPReWireDevice.bundle) - replace the existing Bundle Identifier, rather than adding a new one*
STEP 3: Edit .mxo files that contain (~) or (_)
Any .mxo file that contains one of these characters in its name, needs to be edited.
for each .mxo file :
Show Package Contents > Info.plist
Remove (_) or (~) from Executable string
Remove (_) or (~) from CFBundleLongVersionString
You must also rename the .exe file within each .mxo to reflect the name change.
*HOWEVER, do not remove (_) or (~) from the actual .mxo file name*
PART 4 | SANDBOXING
STEP 1: Create Entitlements File
- File > New > File > MacOS > Property List
- name “entitlements.plist"
- save to Desktop
STEP 2: Add Sandboxing Row
To create strings
-hover over “Root”
-press the (+) to add rows
-create sandboxing row
Key : com.apple.security.app-sandbox
Type : Bootlean
Value : YES
STEP 3: Add Entitlement Keys
Entitlements tell Apple which files/features your app has permission to access on the user’s computer. For example, if your app uses bluetooth, you must add the string “com.apple.security.device.bluetooth”.
Key : com.apple.security.device.bluetooth
Type : Bootlean
Value : YES
List of all entitlements HERE
Example entitlements.plist file can be found HERE
STEP 4: Add Usage Descriptions
Certain entitlements also require a usage description. This is basically a note that the user will see when the app asks for permission to access any "sensitive user or device data" such as the microphone, camera, or bluetooth. Be sure to review the list of entitlements that require a usage description.
**These go in your main Info.plist (NOT entitlements.plist)**
Key : NSMicrophoneUsageDescription
Type : String
Value : Used for pitch analysis and audio recordings
productbuild --component ~/Desktop/APPLICATION.app /Applications --sign "3rd Party Mac Developer Installer: Company Name (XXXXXXXXXX)" --product ~/Desktop/APPLICATION.app/Contents/Info.plist APPLICATION.pkg
this creates a .pkg file in your user folder
Step 2: Upload .pkg to Application Loader
- Open Xcode
- Xcode > Open Developer Tool > Application Loader
- Upload your .pkg file
Step 3: Review Errors -> Resubmit
After submitting your app package, you WILL receive errors. Let the trial and error begin!
Please comment below if you have any questions about the process!
This is a great resource! Thanks Josh for posting it.
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!
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.
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:
codesign -f -s "3rd Party Mac Developer Application: Daniel Nigrin" /Users/dnigrin/Desktop/My-App.app/Contents/Frameworks/libmozjs185.dylib --entitlements /Users/dnigrin/Desktop/My-App.entitlements
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
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
ERROR ITMS-90240: "Unsupported Architectures. Your executable contained the following disallowed architectures: '[i386 (.../Contents/Frameworks/libmozjs185.dylib)]'. New apps submitted to the Mac App Store must support 64-bit starting January 2018, and Mac app updates and existing apps must support 64-bit starting June 2018."
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...
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...
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?
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).
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!
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.
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?
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.
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.
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
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]
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.
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...
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.
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!