Max Standalone in the Mac App Store (2018)
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.
PART 1 | APPLE DEVELOPER PROGRAM
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.
PART 2 | STANDALONE PREPARATION
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)
PART 3 | EDITING FILES
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)
/Contents/Frameworks/libmozjs.dylib/
/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
(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
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
EXAMPLE
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”.
EXAMPLE
Key : com.apple.security.device.bluetooth
Type : Bootlean
Value : YES
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)**
EXAMPLE
Key : NSMicrophoneUsageDescription
Type : String
Value : Used for pitch analysis and audio recordings
List of all usage descriptions HERE
PART 5 | Code Signing
Specifics will vary based on the frameworks/extensions/externals used in your application.
STEP 1: Codesign every .framework file
EXAMPLE
codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Frameworks/MaxAudioAPI.framework/versions/A --deep
STEP 2: Codesign every .mxo file
EXAMPLE
codesign -f -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" ~/Desktop/APPLICATION.app/Contents/Resources/C74/externals/mididrivers/coremidi.mxo --deep
STEP 3: Codesign App (w/ entitlements)
codesign -f -v -s "3rd Party Mac Developer Application: Company Name (XXXXXXXXXX)" --entitlements ~/Desktop/entitlements.plist ~/Desktop/APPLICATION.app
STEP 4: Verify Signatures & Entitlements
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
PART 6 | Upload to App Store
STEP 1: Build & Sign Installer Package
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
/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!
Please comment below if you have any questions about the process!
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 *
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:
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
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
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....
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:
lipo libmozjs185.dylib -remove i386 -output libmozjs185-new.dylib
??
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...
Regarding libmozjs185.dylib
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
lipo /Users/username/Desktop/APPLICATION.app/Contents/Frameworks/libmozjs185.dylib -remove i386 -output /Users/username/Desktop/APPLICATION.app/Contents/Frameworks/libmozjs185.dylib
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!
Hi Josh!
Concerning the clause 2: STEP 2: Add bundle identifier to every Info.plist
Do I need to replace an existing bundle identifier with my own one or to add an additional bundle identifier string to an existing one? I got 37 errors when uploaded my software via transporter and I think it is an exact number of Info.plists I edited for .mxo files.
Here the error example:
Incomplete Document Type Configuration. The CFBundleDocumentTypes dictionary array in the 'com.compositorsoftware.saser' Info.plist should contain an LSHandlerRank value for the CFBundleTypeName 'VST effect program' entry. Refer to https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-SW1 for more information on the LSHandlerRank key. (90788)
Hey Ruslan,
How much did you change your default plist that Max generated? I don't think you should change the Document Type items since the ones Max generates are suitable. I am enclosing a png of a recent plist that I used for a successful app store submission one month ago. I have highlighted everything that you need to manually change. Everything else should be taken care of from within Max when it generates the plist. You can definitely use that as a starting point. You should no longer need to change every .mxo file. I would definitely modify my app's plist first to see if it went through. You just modify the items having to do with your app, such as the name and bundle version (this changes with every app store submission). Another bit of advice I would have is that you use AppWrapper 4. This will streamline everything and make it much easier.
Hey James, I uploaded a new build via Transporter including Cycling '74 resources because otherwise the app will not show up if there is no Max in a system. I will definitely try your suggestions! However my build doesn't appear in AppStore connect. I also realized too that I'm no longer need to edit mxo, just edited the plist for Bundle Identifier of MSPReWireDevice.bundle and deleted /Contents/Resources/MaxPlugInScanner/.
I wonder why my build doesn't show up if the transporter uploaded it with 39 notifications successfully?
Here is my journal from transporter:
2023-02-17 18:30:09.987 INFO: ContentDelivery version 2.14.8 (14038).
2023-02-17 18:30:09.990 INFO: Show Progress: Обращение к сервисам Apple…
2023-02-17 18:30:10.774 INFO: Show Progress: Создание копии «SASER.pkg»…
2023-02-17 18:30:10.778 INFO: Show Progress: Подготовка к выгрузке «SASER.pkg»…
2023-02-17 18:30:11.201 INFO: Show Progress: Анализ пакета…
2023-02-17 18:36:28.118 INFO: Show Progress: Отправка результатов анализа в App Store Connect…
2023-02-17 18:36:30.356 INFO: COMPLETED - PART 1
2023-02-17 18:36:33.654 INFO: COMPLETED - PART 2
2023-02-17 18:36:37.516 INFO: COMPLETED - PART 4
2023-02-17 18:36:37.996 INFO: COMPLETED - PART 5
2023-02-17 18:36:39.750 INFO: COMPLETED - PART 3
2023-02-17 18:36:39.755 INFO: Show Progress: Ожидание результатов анализа App Store Connect…
2023-02-17 18:37:21.158 INFO: Show Progress: Сбор атрибутов пакетов…
2023-02-17 18:37:21.159 INFO: Show Progress: Запрос инструкций по выгрузке от App Store Connect…
2023-02-17 18:37:21.544 INFO: 35 upload operations were requested for 35 parts.
2023-02-17 18:37:21.544 INFO: Show Progress: Подготовка файла для выгрузки в App Store Connect…
2023-02-17 18:37:21.558 INFO: Show Progress: Подготовка файла для выгрузки в App Store Connect…
2023-02-17 18:37:22.251 INFO: Show Progress: Выгрузка в App Store Connect…
2023-02-17 18:37:22.425 INFO: Upload progress: 8.665%
2023-02-17 18:37:23.354 INFO: Upload progress: 12.708%
2023-02-17 18:37:24.452 INFO: COMPLETED - PART 2
2023-02-17 18:37:24.567 INFO: Upload progress: 15.018%
2023-02-17 18:37:25.443 INFO: COMPLETED - PART 5
2023-02-17 18:37:25.552 INFO: Upload progress: 17.329%
2023-02-17 18:37:26.062 INFO: Upload progress: 19.640%
2023-02-17 18:37:26.362 INFO: COMPLETED - PART 4
2023-02-17 18:37:26.567 INFO: COMPLETED - PART 7
2023-02-17 18:37:26.684 INFO: Upload progress: 23.683%
2023-02-17 18:37:27.413 INFO: COMPLETED - PART 3
2023-02-17 18:37:27.520 INFO: Upload progress: 27.149%
2023-02-17 18:37:27.616 INFO: COMPLETED - PART 10
2023-02-17 18:37:28.102 INFO: COMPLETED - PART 8
2023-02-17 18:37:28.210 INFO: Upload progress: 31.770%
2023-02-17 18:37:28.594 INFO: COMPLETED - PART 12
2023-02-17 18:37:29.016 INFO: Upload progress: 36.391%
2023-02-17 18:37:29.622 INFO: COMPLETED - PART 14
2023-02-17 18:37:29.742 INFO: Upload progress: 40.434%
2023-02-17 18:37:29.938 INFO: COMPLETED - PART 9
2023-02-17 18:37:30.267 INFO: Upload progress: 42.745%
2023-02-17 18:37:30.629 INFO: COMPLETED - PART 15
2023-02-17 18:37:30.657 INFO: COMPLETED - PART 13
2023-02-17 18:37:30.767 INFO: Upload progress: 46.788%
2023-02-17 18:37:31.313 INFO: COMPLETED - PART 6
2023-02-17 18:37:31.343 INFO: Upload progress: 49.099%
2023-02-17 18:37:31.711 INFO: COMPLETED - PART 17
2023-02-17 18:37:31.952 INFO: Upload progress: 54.298%
2023-02-17 18:37:32.467 INFO: Upload progress: 56.608%
2023-02-17 18:37:32.744 INFO: COMPLETED - PART 1
2023-02-17 18:37:32.904 INFO: COMPLETED - PART 20
2023-02-17 18:37:33.017 INFO: Upload progress: 60.074%
2023-02-17 18:37:33.660 INFO: COMPLETED - PART 16
2023-02-17 18:37:33.672 INFO: COMPLETED - PART 18
2023-02-17 18:37:33.721 INFO: Upload progress: 62.384%
2023-02-17 18:37:33.903 INFO: COMPLETED - PART 11
2023-02-17 18:37:34.259 INFO: Upload progress: 68.161%
2023-02-17 18:37:34.330 INFO: COMPLETED - PART 22
2023-02-17 18:37:34.792 INFO: Upload progress: 72.782%
2023-02-17 18:37:35.382 INFO: Upload progress: 74.515%
2023-02-17 18:37:35.445 INFO: COMPLETED - PART 21
2023-02-17 18:37:35.914 INFO: COMPLETED - PART 26
2023-02-17 18:37:36.028 INFO: Upload progress: 78.558%
2023-02-17 18:37:36.312 INFO: COMPLETED - PART 24
2023-02-17 18:37:36.477 INFO: COMPLETED - PART 19
2023-02-17 18:37:36.592 INFO: Upload progress: 83.179%
2023-02-17 18:37:36.685 INFO: COMPLETED - PART 23
2023-02-17 18:37:36.951 INFO: COMPLETED - PART 25
2023-02-17 18:37:37.094 INFO: Upload progress: 88.378%
2023-02-17 18:37:37.722 INFO: Upload progress: 90.689%
2023-02-17 18:37:38.177 INFO: COMPLETED - PART 27
2023-02-17 18:37:38.291 INFO: Upload progress: 92.999%
2023-02-17 18:37:38.327 INFO: COMPLETED - PART 28
2023-02-17 18:37:38.507 INFO: COMPLETED - PART 31
2023-02-17 18:37:38.951 INFO: Upload progress: 97.689%
2023-02-17 18:37:39.372 INFO: COMPLETED - PART 32
2023-02-17 18:37:39.484 INFO: COMPLETED - PART 35
2023-02-17 18:37:39.493 INFO: Upload progress: 99.422%
2023-02-17 18:37:39.497 INFO: COMPLETED - PART 29
2023-02-17 18:37:40.054 INFO: COMPLETED - PART 30
2023-02-17 18:37:40.575 INFO: COMPLETED - PART 34
2023-02-17 18:37:40.841 INFO: COMPLETED - PART 33
2023-02-17 18:37:40.849 INFO: Time to transfer: 18.254 seconds (9944.48KB/s)
2023-02-17 18:37:40.855 INFO: Show Progress: Проверка состояния сборки…
2023-02-17 18:37:40.855 INFO: Show Progress: Завершение выгрузки…
2023-02-17 18:37:42.079 INFO: Show Progress: Ожидание обработки пакета…
2023-02-17 18:37:42.344 INFO: Show Progress: Выгруженный пакет обрабатывается.
2023-02-17 18:37:45.742 INFO: Show Progress: Выгрузка успешно завершена.
2023-02-17 18:37:45.742 INFO:
================
UPLOAD SUCCEEDED
Delivery UUID: XXXX
Transferred 181529550 bytes in 18.254 seconds (9.9MB/s)
================
Strange, I got two "binary file errors" on this uploads from mobile version of AppStore connect. I think I should tackle it from another angle: making a gen~ code export and parametrizing a simple interface with JUCE...
I made my SASER iOS, iPadOS app using export code to circumvent Apple using JUCE framework:
However, they refused it to App Store due to the following reason:
Guideline 2.1 - Information Needed
We’re looking forward to completing the review of your app, but we need more information to continue.
Next Steps
Please provide detailed answers to the following questions in your reply to this message in App Store Connect:
- what is the purpose of your app?
Guideline 5.4 - Legal - VPN Apps
Your app includes VPN services but does not use the NEVPNManager API to deliver these services.
Next Steps
To resolve this issue, please use the NEVPNManager API to deliver any VPN services in your app.
Resources
Learn more about utilizing NEVPNManager to create and manage VPN configurations in your app.
========
My reply to them was:
The purpose of the app is ULF, VLF (Ultra Low Frequency, Very Low Frequency) software defined radio. The app doesn't use any VPN technology as it doesn't create an internet service. It is No Internet Messenger, which can be used in extreme cases when you need to transmit emergency data. Using 3d party Morse coder/decoder you can send/read messages in ULF, VLF range.
========
It seems Apple "specialists" doesn't look into the site provided at all and very unfamiliar with virtual routing itself.. Anything concerning routing is VPN to them, however there is no VPN technology involved from my side. It is purely VLF UTC timecode which is due to each country, where this NTP operators act. So there is no single operator as they want it from me in NEVPNManager API.
Sorry, for those who looked after this update of SASER, but I can't make it to the public yet.
Ok, after some arguing I removed some sections in description and Apple allowed SASER in AppStore!
So, here it is the Gen~ export code SASER application in App Store made using JUCE sdk:
Here is the demo video of SASER for iPad running on iMac 24" M1 (macOS Ventura):
Congrats! Nice to see gen~ exported code make its way to iOS!
Thanks Dan! With Apple Silicon it's actually much wider now, this app can work with the same efficiency on macOS Ventura 13.1 or above as well as iPad with iPadOS 16.2 and of course iPhone :)
You can watch how SASER 2.0 was tested on this video:
More than 1000+ hours of testing in Compositor v9 Hypervisor makes it a unique audio frequencies instrument.
Very nice - I have no idea what's going on in there, but I can certainly appreciate that it must have taken a while to put together - congrats!