Josh Stovall

Max Standalone in the Mac App Store (2018)

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 1: Enroll in Apple Developer Program

https://developer.apple.com/account/mac/certificate/

STEP 3: Create App ID (aka Bundle Identifier)

https://developer.apple.com/account/mac/identifier/bundle

Apple recommends “reverse domain notation"

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.

create a [standalone] object in your patch

- update "Bundle Identifier" to match your Apple App ID (com.website.appname)

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 

Paste this into your main patcher window. This will make your application quit (⌘+Q) automatically when the main window is closed.

closebang

message

- name your .icns file "APPLICATION.icns" 

- replace existing .icns file @ /Contents/Resources/Max.icns/

At this point, I removed the following files. They caused issues with submission, and my app worked fine without these files. (this is one thing, i’d love to figure out for an updated guide)

(only needed if your app uses the vst~ object)

Update Info.plist to reflect your app’s info. 

Show Package Contents > Contents > Info.plist

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.

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*

- File > New > File > MacOS > Property List

EXAMPLE
Key : com.apple.security.app-sandbox
Type : Bootlean
Value : YES

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”.

EXAMPLE
Key : com.apple.security.device.bluetooth
Type : Bootlean
Value : YES

Example entitlements.plist file can be found 

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 

 of entitlements that require a usage description.

**These go in your main Info.plist (NOT entitlements.plist)**

EXAMPLE
Key : NSMicrophoneUsageDescription
Type : String
Value : Used for pitch analysis and audio recordings

Specifics will vary based on the frameworks/extensions/externals used in your application.

codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Frameworks/MaxAudioAPI.framework/versions/A --deep

codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Resources/C74/externals/mididrivers/coremidi.mxo --deep

codesign -f -v -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" --entitlements ~/Desktop/entitlements.plist ~/Desktop/APPLICATION.app

codesign -v ~/Desktop/APPLICATION.app/Contents/MacOS/APPLICATION/

codesign -d --entitlements - ~/Desktop/APPLICATION.app/

Use if you receive an error message about a “resource fork" while signing. I needed to run this command, I believe it had something to do with the Max.icns file.

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

- Xcode > Open Developer Tool > Application Loader

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!

Mac Platform Information for Standalone Applications

My own summary on submitting a standalone Mac App

Digitally sign a standalone on Mac with an Apple developers ID

max standalone crash on mac 10.8.2 after codesigning with entitlements

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 1: Enroll in Apple Developer Program
https://developer.apple.com
cost $100 per year

STEP 2: Create Certificates
https://developer.apple.com/account/mac/certificate/
Create certificates
     - Mac App Distribution 
     - Mac Installer Distribution
    TUTORIAL VIDEO

STEP 3: Create App ID (aka Bundle Identifier)
https://developer.apple.com/account/mac/identifier/bundle
Apple recommends “reverse domain notation"
     example = com.website.appname

STEP 4: App Store Connect
https://appstoreconnect.apple.com/
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. 

STEP 1: Edit main patcher inspector 
View > Inspector Window

Update inspector
     - 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 4: Enable Quit on Window Close
Paste this into your main patcher window. This will make your application quit (⌘+Q) automatically when the main window is closed.


STEP 5: Build Standalone Application
File > Build Collective / Application…
     - File Format : Application
     - Save to Desktop

STEP 6: Create Custom Icon
Use Image2Icon
     - export ICNS file
     - name your .icns file "APPLICATION.icns" 
               (APPLICATION = your app's name)
     - replace existing .icns file @ /Contents/Resources/Max.icns/
               (Max.icns --> APPLICATION.icns)


/Contents/Resources/MaxPlugInScanner/  
(only needed if your app uses the vst~ object)

STEP 1: Update main Info.plist
Update Info.plist to reflect your app’s info.  
Show Package Contents > Contents > Info.plist

Update existing rows:
     - Get Info string
     - Icon file
     - Bundle identifier
     - CFBundleLongVersionString
     - Bundle versions string, short
     - Bundle version 

Add new rows:
     - Application Category
     - Minimum system version

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.

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

*HOWEVER, do not remove (_) or (~) from the actual .mxo file name*


STEP 1: Create Entitlements File
Open Xcode
     - 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

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”. 

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)**

Specifics will vary based on the frameworks/extensions/externals used in your application. 

EXAMPLE
codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Frameworks/MaxAudioAPI.framework/versions/A --deep

EXAMPLE
codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Resources/C74/externals/mididrivers/coremidi.mxo --deep

verify .app signature
codesign -v ~/Desktop/APPLICATION.app

verify .exe signature 
codesign -v ~/Desktop/APPLICATION.app/Contents/MacOS/APPLICATION/

verify app entitlements 
codesign -d --entitlements - ~/Desktop/APPLICATION.app/


Resource Fork 
Use if you receive an error message about a “resource fork" while signing. I needed to run this command, I believe it had something to do with the Max.icns file.

xattr -lr ~/Desktop/APPLICATION.app
xattr -cr ~/Desktop/APPLICATION.app

this creates a .pkg file in your user folder 
/Macintosh HD/Users/username/

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!


SIMILAR RESOURCES
Your Max Standalone on Mac App Store (Cycling 74)
Mac Platform Information for Standalone Applications (Cycling 74)
Making A Slick Max Standalone (Dan Nigrin)
My own summary on submitting a standalone Mac App (Max Forums)
Digitally sign a standalone on Mac with an Apple developers ID (Max Forums)
max standalone crash on mac 10.8.2 after codesigning with entitlements (Max Forums)


* shameless plug for my app Woodwind Fingerings *

Max Standalone in the Mac App Store (2018)
I have successfully submitted my app to the Mac App Store. Yes it is possible! There seems to be 

max-standalone-in-the-mac-app-store-2018

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 ?

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):

: 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.

: 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:

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/

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

: 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

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.

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:

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

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

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."

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....

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...

* 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:

lipo libmozjs185.dylib -remove i386 -output libmozjs185-new.dylib

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...

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.

lipo /Users/username/Desktop/APPLICATION.app/Contents/Frameworks/libmozjs185.dylib -remove i386 -output /Users/username/Desktop/APPLICATION.app/Contents/Frameworks/libmozjs185.dylib

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?

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).

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 

 flag. The "old" way of stripping the signatures (

) seems to break/prevent subsequent signing attempts.

@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.

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.

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 

 going to the app store... Hopefully the Cyclists will advise though on that issue.

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?

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!

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. 

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: 

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 .  