Max Standalone in the Mac App Store (2018)

Oct 20 2018 | 6:38 pm

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)

[standalone] reference | TUTORIAL VIDEO

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.

Max Patcher
In Max, select New From Clipboard.

Show Text

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

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

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!

* shameless plug for my app Woodwind Fingerings *

Floating Point
Oct 20 2018 | 11:42 pm
Thanks, this is fantastic. You should be on the C74 payroll. bookmarked
Share
Chris_DeCh
Oct 21 2018 | 3:08 pm
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 ?
Share
Dan Nigrin
Oct 21 2018 | 4:19 pm
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
Share
Josh Stovall
Oct 21 2018 | 8:34 pm
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."
Share
Dan Nigrin
Oct 21 2018 | 8:43 pm
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....
Share
Dan Nigrin
Oct 21 2018 | 8:55 pm
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...
Share
testcase
Oct 22 2018 | 4:36 pm
can you use lipo or ditto to strip i386 code from libmozjs?
Share
Dan Nigrin
Oct 22 2018 | 4:44 pm
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
??
Share
tgdrakarg
Oct 22 2018 | 9:39 pm
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...
Share
Josh Stovall
Oct 30 2018 | 12:59 am
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
Share
Dan Nigrin
Oct 30 2018 | 2:36 pm
Good to know, thanks for reporting!
Share
James Howard Young
Nov 20 2019 | 11:46 am
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.
Share
Dan Nigrin
Nov 20 2019 | 12:13 pm
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?
Share
James Howard Young
Nov 20 2019 | 12:14 pm
I tried but could not successfully load any audio objects.
Share
Dan Nigrin
Nov 20 2019 | 12:25 pm
Hmmm... afraid no other ideas off top of my head... Maybe the Cyclists will come to the rescue!
Share
James Howard Young
Nov 20 2019 | 8:00 pm
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).
Share
Dan Nigrin
Nov 20 2019 | 8:05 pm
Excellent, great work James!
Share
James Howard Young
Nov 22 2019 | 5:55 am
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!
Share
Ben Bracken
Nov 22 2019 | 8:20 pm
@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.
Share
James Howard Young
Nov 22 2019 | 8:26 pm
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.
Share
James Howard Young
Nov 27 2019 | 5:39 pm
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.
Share
Dan Nigrin
Nov 27 2019 | 6:23 pm
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.
Share
James Howard Young
Nov 27 2019 | 8:48 pm
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.
Share
SSingh
Jan 02 2020 | 10:22 pm
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?
Share
Josh Stovall
Jan 02 2020 | 10:44 pm
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!
Share
James Howard Young
Jan 03 2020 | 12:11 pm
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.
Share
Dan Nigrin
Jan 03 2020 | 1:14 pm
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
Share
SSingh
Jan 03 2020 | 9:43 pm
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.
Share
Dan Nigrin
Jan 19 2020 | 10:24 pm
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?
Share
James Howard Young
Jan 20 2020 | 5:58 am
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!
Share
António Florença
Jan 20 2020 | 9:07 am
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.
Share
James Howard Young
Jan 20 2020 | 9:47 am
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.
Share
Dan Nigrin
Jan 20 2020 | 12:25 pm
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?
Share
James Howard Young
Jan 20 2020 | 12:27 pm
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
Share
António Florença
Jan 20 2020 | 12:47 pm
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...
Share
James Howard Young
Jan 20 2020 | 12:48 pm
Are you referring to the sandboxing or the hardened mode that they will be implementing?
Share
Dan Nigrin
Jan 20 2020 | 12:48 pm
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?
Share
James Howard Young
Jan 20 2020 | 12:50 pm
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
Share
António Florença
Jan 20 2020 | 1:43 pm
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.
Share
Dan Nigrin
Jan 20 2020 | 4:07 pm
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?
Share
James Howard Young
Jan 20 2020 | 5:13 pm
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.
Share
Dan Nigrin
Jan 20 2020 | 9:36 pm
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?
Share
James Howard Young
Jan 21 2020 | 6:01 am
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.
Share
Dan Nigrin
Jan 21 2020 | 11:57 am
OK thanks James, very helpful. If I get to that point I will report back if I have the same issue...
Share
Dan Nigrin
Jan 23 2020 | 4:55 pm
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).
Share
James Howard Young
Jan 23 2020 | 5:09 pm
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.
Share
Dan Nigrin
Feb 16 2020 | 6:49 pm
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...
Share
James Howard Young
Feb 16 2020 | 7:23 pm
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.
Share
Dan Nigrin
Feb 16 2020 | 8:30 pm
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!
Share