max standalone crash on mac 10.8.2 after codesigning with entitlements
Scratch that, I see the test you’re referring to now in the link you provided above, thanks..
How did you do this test? I can try with my application and see what happen.
you can use the nm command-line tool for this:
I did the test and I found the same possible files. Now, I don’t know. But can it be possible to open unix file in some way and delete some line commands?
Hi, I’m having a very weird issue with code signing process: I’m using C74 .mxo in my app to communicate with iPhone and this has always worked fine, BUT now my app doesn’t want to communicate with iOS AFTER code signing my app, before code signing works perfect. Any idea?
(by the way, the C74 app designer doesn’t know anything about it and doesn’t want to waste his time figuring this out..)
I am also being rejected by AppStore because of Quicktime API in my project. Although I do not use QT myself, the traces seem to be in Max Runtime and there’s probably not much to do about it. Can we binary hack the runtime so that Apple’s scripts wouldn’t recognize QT calls?
That would be an awesome hack if someone could figure it out…
Would it be possible to strip out 32bit code from Runtime? If yes, it should help as 64bit Max uses QTKit instead of QuicTime APi.
Gave it a try but unfortunately didn’t work. I removed 32 bit architecture from my app using Xslimmer which got rid of some 15.5MB after which my app runs fine. Then re-signed everything, created new .pkg and resubmitted. Response from Application Loader is still the same: Deprecated API Usage being Quicktime API.
Nice attempt! I think we’re just going to have to hope that Cycling can address this…
So has anyone communicated with Cycling 74 on this topic? It’s a pretty big deal in regards to how I would like to be using their software.
Yes, I’ve let them know about it.
Can someone give me the exact step by step procedure they are using to determine whether their app still has QuickTime calls? I wasn’t successfully able to do the test that is in the Apple link provided above. Thanks.
If I understand correctly, no one has had any success in sending an app to the Apple App Store so far? (I mean after the reportedly denied apps with Quicktime API calls)
Don’t give up hope guys – I have a good feeling about this. ;-)
I tried the "nm" command that TIMETOY suggested and it returned no results.
Does that mean that I do not have any QuickTime or QTKit API included ?
I tried yesterday to upload an app, after testing it with nm, and it was rejected because of QuickTime API usage!
So i guess we wait!
I used the full path of the app.
Where should i put the app to use the command without the full path ? Does it make any defference ?
I don’t think it makes any difference. Hmm. Makes me wonder why you are getting refused still.. Anyway, I’m optimistic that Cycling will come through for us..
I hope so! Well, I will post if anything new comes up.
I hope Cycling will do something for this problem..
Just an FYI,
Tried using this, instead of the "nm" command:
otool -L /Path/MyApp.app/Contents/Mac/MyApp
It returns the libraries that are linked to the binary.
Although there was no QuickTime linked in my app, it showed this line (among others!):
"/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)"
Interesting, thanks – I’ll report to the folks at Cycling.
Max 6.1.7 released – from the release notes:
"Quicktime: removed API calls from Max kernel"
Someone who’s got an app ready to submit to Apple, please give it a test! In my testing, standalone’s now pass the "nm" test, but still not the "otool" test. Hopefully the latter will not be as important? I just don’t have an app ready to submit to Apple yet to try…
Rejected for "Deprecated API Usage" again.
The "otool", finds the QTKit. I tested even an empty patcher build, and it still finds the QTKit, so I think the problem remains…
Will try out again and post if something changes!
Thanks for the report. Have you manually removed the qtimage extension from the standalone? That would also be necessary.
Yes, I have removed all extension but polybuffer.mxo and setplugpath.mxo.
Any news on the matter ?
I don’t know anything. I think that this problem can be solved only by Cycling. We can’t do anything I think..
Hi guys, any updates on the horizon? A word from Cycling about the state of things in regards to this issue would be much appreciated.
This seems to be good news in Max 6.1.8 !
• kernel: removed QtKit and Quicktime Frameworks for Mac App Store compatibility
I’ll try to resume work in my long pending updates and comment here.
If anyone else can test with an app ready to send to Apple and report too, it’ll be appreciated, thx!
I don’t have an app ready to go for the App Store, but I’ve tested with an empty patch to see if it now passes the otool test, and it does…
Hi guys, I’m sorry but for now I don’t have any App ready to test the upload. I hope that now we can upload applications, I’m very excited. ;)
I am trying to submit an app, but I get a bunch of warning like "Invalid Signature – The nested app bundle PATH/Contents/Frameworks/MaxAPI at path PATH/Contents/Frameworks/MaxAPI.framework/ is not signed"
I think the warnings refer to every framework and .mxo that needs code signing.
I also get an error like the warning above, referring to the .app itself.
Does anyone knows if something has changed for the code signing process?
Thank you in advance,
Nikolas, I presume when you codesigned all that stuff as per usual, there were no errors reported in the Terminal? I’m not aware of any codesigning changes with Apple, but then again, it’s been a while since I submitted anything..
No errors in the Terminal. I will try out different approaches and report back for any news.
I got an email from Apple a few days ago warning all developers about codesigning and Gatekeeper changes:
With the release of OS X Mavericks 10.9.5, the way that OS X recognizes signed apps will change. Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures).
If you build code with an older version of OS X, use OS X Mavericks 10.9 or later to sign your app and create v2 signatures using the codesign tool. Structure your bundle according to the signature evaluation requirements for OS X Mavericks 10.9 or later. Considerations include:
Signed code should only be placed in directories where the system expects to find signed code.
Resources should not be located in directories where the system expects to find signed code.
The –resource-rules flag and ResourceRules.plist are not supported.
Make sure your current and upcoming releases work properly with Gatekeeper by testing on OS X Mavericks 10.9.5 and OS X Yosemite 10.10 Developer Preview 5 or later. Apps signed with v2 signatures will work on older versions of OS X.
For more details, read "Code Signing changes in OS X Mavericks" and "Changes in OS X 10.9.5 and Yosemite Developer Preview 5" in OS X Code Signing In Depth.
@Nikolas: might these new rules be getting in your way? I haven’t read the guides yet but there might be some answers there.
My app is waiting for review…
The code-signing must be done with the –deep option like this:
"codesign -f -s "3rd Party Mac Developer Application: YOUR NAME" /path/to/MyApp.app/Contents/…" –deep"
You must code sign all the frameworks and mxos like that.
Other than that, everything else done as before (i.e. the installer package).
For any other news on the subject, I will make a post!
thank you very much. this is a very good information. I’ll try it.
Great work Nikolas! And thanks to Cycling for listening and getting the Quicktime related fixes in as well.
Also Nikolas, did you codesign everything on a 10.9 machine, as mentioned in Juan’s post?
Thank you guys,
and yes, the code signing (as well as the development) is done on a 10.9.4 machine.
Good to know, thanks.
You know, there’s been a lot of changes since I wrote the original Your Max Standalone on the Mac App Store article a few years ago, together with Oli Larkin and James Howard Young. Would any of you be interested in collaborating on an update to that article? This stuff is unfortunately complicated, and there are several bits of knowledge spread across various places now, making it hard to keep up.
Would be great to have a new guide, count on me.
… By the way I could translate to Spanish if you like.
i think that a new guide is very useful, so if you want count on me. I can translate it in Italian ;) I was thinking also to create a max based free application all of command lines to sign the application, principally for beginners, simply with a "drag and drop".
OK cool – I will begin (in my spare time – yeah right!) to work on an updated first draft, then will pass it by you guys (and whomever else is interested to help) for revisions/translation/etc..
An update on the App Store guide will be very convenient, I’m in for helping too.
I would also like to work on the new guide!
okay, I was all optimistic about 6.1.8 and tried to submit my app to the app store, but now I’m getting "App sandbox not enabled" messages for [myapp].app/Contents/MacOS/[myapp] even though as far as I can tell I’ve included all the proper entitlements and codesigned properly. (No QT messages though, which is a relief because maybe that means this is something I can fix myself.)
I’ve read the updated security info from Apple but since I’ve been working in 10.9.4 the whole time it doesn’t seem to apply to me.
are you sure the entitlements you use are correct? Have you enabled the sandbox entitlement? The codesigning must be done with the –deep flag.
I know these sound like "noobie" problems, but that is what one may forget easier!
Also, you have to codesign the bundle itself with the entitlements last.
I recently submitted an app (SampleBox) and it passed through yesterday. So it is doable!!
My suggestion, start over the codesinging. Generally the terminal tells you what is not codesigned inside the bundle. If the problem persists, maybe post your entitlements file.
Thanks Nik, it’s good to hear that your SampleBox app made it through. Means there must be something I’m missing.
I tried again from scratch but still get the same error. Can’t figure out what I’m doing wrong. My entitlements file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
all help is tremendously welcome
Can you post the codesigning commands you are using?
this is the latest set of codesigning commands I used. I know it’s more than what’s strictly required, but it was late and I was getting desperate.
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAPI.framework --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Info.plist --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/MacOS/[myapp] --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/MacOS/[myapp].entitlements --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/PkgInfo --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/Max.icns --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/[myapp].icns --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/[myapp].rsrc --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/support/ad/ad_coreaudio.mxo --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/support/ad/ad_portaudio.mxo --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/[myapp].mxf --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/[myapp].entitlements --deep codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app --deep productbuild --component /Applications/[myapp].app /Applications --sign "3rd Party Mac Developer Installer: [developer]" --product /Applications/[myapp].app/Contents/Info.plist [myapp].pkg
A few things wrong here.
* You don’t need to sign the Info.plist, the contents inside the MacOS folder, the .icns file, or the entitlements file
* For each of the codesign commands, you have to include the entitlements file as an option to the command. Like this:
codesign -f -s "3rd Party Mac Developer Application:[developer]" /Users/USERNAME/Desktop/[myapp].app --entitlements /Users/USERNAME/Desktop/[myapp].entitlements --deep
I see now that Nikolas didn’t add that in in his last example above, not sure if that was a mistake, or if it’s no longer a requirement? It certainly was before.
* I’ve never tried signing the app and its contents while within my actual Applications folder. It may work, but I also wonder if there may be some permissions issues. I usually just put the app on the Desktop and sign it while there.
Hope this helps!
firstly the framworks must be codesigned like so:
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework/versions/A –deep
also the bundle must be signed with entitlements like so:
codesign -f -s "3rd Party Mac Developer Application: [developer]" –entitlements path/to/entitlements/myapp.entitlements /Applications/[myapp].app –deep
you dont have to include the file in the bundle.
sorry I cant be more helpful now. Try it and post again your results!
oh this is great, Dan & Nik you guys rock. Going to try this later, wish me luck…
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Users/MiniNew/Desktop/[myapp].app/Contents/MacOS/[myapp] --entitlements /Users/MiniNew/Desktop/[myapp].entitlements --deep
I get the error:
unsealed contents present in the root directory of an embedded framework In subcomponent: /Users/MiniNew/Desktop/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework
I had signed the MaxAudioAPI.framework beforehand just as Nik had suggested.
optimism fading, but I will persist…
scratch that last post… I just started over and now it works! submitting now…
promising message from Apple:
"The status for the following app has changed to Waiting For Review"
One more little bit of advice: don’t be discouraged if you get denied once they review the app – there’s all sorts of pitfalls still ahead, but hopefully the collective wisdom of those of us who’ve been lucky enough to make it through will help you make it all the way through!
Hi guys I have a new problem. When I send my .pkg file, App Store refuse my app for this reasons:
Invalid Signature – the main app bundle at path Music Book.app is not signed. The following error(s) were reported from codesign:
/tmp/mz_4123270847529686120dir/mz_6270106668677812673dir/com.robertoattanasio.musicbook.pkg/Payload/Music Book.app: code object is not signed at all
In subcomponent: /private/tmp/mz_4123270847529686120dir/mz_6270106668677812673dir/com.robertoattanasio.musicbook.pkg/Payload/Music Book.app/Contents/Music Book.mxf
The problem is that I signed everything. I signed frameworks and .mxo files, and the entire application. I used also –deep flag. So I don’t know where is the problem.
I had that error too, and traced it to a PkgInfo file which for some reason was inside the Frameworks folder. Make sure that MaxAPI is the only file inside the MaxAPI.framework folder. I just deleted the PkgInfo file and my app still worked fine.
PS: what is the usual wait time to get a response from Apple after an app’s status is Waiting for Review?
Thank you I’ll try it. If I remember well, it takes 3/5 days.
unfortunately the app store gives me always the same error..
ok, I’m ready to give up on this altogether.
My app came back from the review needing a couple of small things that I could easily change.
Now I’ve codesigned the app using EXACTLY the same procedure as before and this time I’m getting the same Invalid Signature error as Roberto. It seems like something has changed at Apple, but what that is is a mystery. They recommend reading this technote (https://developer.apple.com/library/mac/technotes/tn2206/_index.html) but that offers no discernible help.
Same problem here.
after a few minutes I upload the pkg file I get the exactly same error.
I wonder if something has changed on the Apple side in just the last few weeks, between when Nikolas submitted and when you guys (Marvin and Timetoy) did? I’m afraid I can’t help as I have nothing to submit currently…
so, the problem here is that on the email it says to us that the main .mxf is not signed at all.
here’s what I’ve noticed so far:
when I do the codesign I’ve always been asked to confirm the utilisation of the key (I didn’t choose "always confirm") twice, but for some reason for the .mxf file it ask me only once.
On the tech note linked you can see this:
OS X v10.9 Mavericks introduced a number of significant changes to the code signing machinery. Most of these changes apply to the resource envelope of a code signature, where the signature keeps a list of files in a bundle. The pre-Mavericks version, version 1, recorded only files in the Resources directory and ignored the rest. The Mavericks version, version 2, makes the following changes:
It records substantially all files by default. There are no default "holes".
It records nested code (frameworks, dylibs, helper tools and apps, plug-ins, etc.) by recording their code signature for verification.
It records symbolic links. Version 1 resource envelopes ignore symlinks.
A signature may contain multiple versions of resource envelopes. Mavericks generates, by default, both version 2 and version 1 resource envelopes.
I don’t have enough knowledge about this but I think it may be the reason, somehow the .mxf file doesn’t get the 2 signatures versions. but I might be wrong.
also, if you use codesign -f -s "3rd Party Mac Developer Application: [developer]" [path]/[myapp].app –deep, the deep option already sign all the other files inside the bundle (for some reason it doesn’t sign the files inside the ad folder, but that’s it), on the other hand here’s what Apple suggests:
When verifying signatures, add –deep to perform recursive validation of nested code. Without –deep, validation will be shallow: it will check the immediate nested content but not check that fully. Note that Gatekeeper always performs –deep style validation.
Important: While the –deep option can be applied to a signing operation, this is not recommended. We recommend that you sign code inside out in individual stages (as Xcode does automatically). Signing with –deep is for emergency repairs and temporary adjustments only
I’ll keep try but is getting really annoying.
I’m almost sure that the problem for me is the signature version of the mxf file, if Timetoy and Roberto can please try this and see if it’s the same it would’ve be a starting point to fix the issues.
in the terminal type: codesign -dv [path to signed file]
you should see a report on the signature status for that specific file.
this is what I have got:
codesign -dv [path to signed file].app
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=72887 flags=0x0(none) hashes=3635+5 location=embedded
Signed Time=12 Sep 2014 18:14:06
Sealed Resources version=2 rules=12 files=51 <———- !!!!
Internal requirements count=1 size=204
codesign -dv [path to signed file].mxf
CodeDirectory v=20200 size=148 flags=0x0(none) hashes=1+2 location=embedded
Signed Time=12 Sep 2014 18:15:02
Sealed Resources=none <———- !!!!
Internal requirements count=1 size=204
codesign -dv [path to signed file]/Contents/Frameworks/MaxAPI.framework/versions/A
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=3924 flags=0x0(none) hashes=189+3 location=embedded
Signed Time=12 Sep 2014 18:13:01
Sealed Resources version=2 rules=12 files=2 <———- !!!!
Internal requirements count=1 size=200
that "Sealed Resources=none" it must be the problem
Hi Marvin, this my result:
Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music Book.app/Contents/MacOS/Music Book
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=72894 flags=0x0(none) hashes=3635+5 location=embedded
Signed Time=04/set/2014 21:01:13
Sealed Resources version=2 rules=12 files=25
Internal requirements count=1 size=216
Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music Book.app/Contents/Music Book.mxf
CodeDirectory v=20200 size=194 flags=0x0(none) hashes=1+5 location=embedded
Signed Time=04/set/2014 21:01:12
Internal requirements count=1 size=196
Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music Book.app/Contents/Frameworks/MaxAPI.framework/Versions/A/MaxAPI
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=3964 flags=0x0(none) hashes=189+5 location=embedded
Signed Time=04/set/2014 21:01:09
Sealed Resources version=2 rules=12 files=2
Internal requirements count=1 size=204
I’m sorry but I don’t know hot to help you, this is an unknown world for me. But if need some other tests let me know.
sounds interesting Marvin, you might be on to something. The signature status on my app looks similar to yours.
Executable=[...] Identifier=[...] Format=bundle with Mach-O universal (i386 x86_64) CodeDirectory v=20200 size=72885 flags=0x0(none) hashes=3635+5 location=embedded Signature size=4353 Signed Time=Sep 10, 2014, 10:22:52 PM Info.plist entries=24 TeamIdentifier=[...] Sealed Resources version=2 rules=12 files=31 Internal requirements count=1 size=204 Executable=[...].mxf Identifier=[...] Format=generic CodeDirectory v=20200 size=192 flags=0x0(none) hashes=1+5 location=embedded Signature size=4353 Signed Time=Sep 10, 2014, 10:22:52 PM Info.plist=not bound TeamIdentifier=[...] Sealed Resources=none Internal requirements count=1 size=188
when I have time to tackle this again I’m going to contact an apple engineer and see what he says.
I think version 2 code signatures will never work for apps made with Max, because the .mxf file has to be in the /Contents directory for the app to run, and I’m afraid that apple sees the .mxf file as an "arbitrary data file" and not as code:
"These places [ie, /Contents/] are expected to contain only code. Putting arbitrary data files there will cause them to be rejected (since they’re unsigned)."
so if it is possible to move the .mxf file into another folder, can that solve the problem?
Does somebody knows which file contains the pointer that locate the main .mxf?
I don’t think you can change where Max expects that file to be.
What I’m struggling with here is that Nikolas was able to sign and submit his app (and have it make it all the way through), and Timetoy you were successful at least once. So I don’t think there’s something fundamentally wrong with the structure of the Max app bundle or anything, and rather that the detailed approach to signing (e.g. what you sign, and what order you sign those things) must have become a bit more complex with the v2 signatures.
Hopefully I’ll soon have something to upload to Apple, so I can chime in with my own experience…
- This reply was modified 1 year by Dan Nigrin.
I think the reason my app made it through the first time is that the version 2 signature wasn’t a requirement yet, and then when I got around to re-submitting my app it was. Just unfortunate timing on my part.
Hi mates, do you know if apple allow us to write an aiff sound file to hard drive (sfrecord) without opening the dialogue message of "open"? I’m trying to write a sound file in the same location of my app BUT when I make the bundle the recorded files are lost…, I can not find then neither inside /Contents, or MacOS… Any idea? Should I preset an absolute location? like MacintoshHD? would be possible?
sorry, I move the message to a new Topic.
I’m having the same problem about .mxf being "not signed at all". Tried to move my .mxf to /Contents and create an alias in .app root but Max does not load the .mxf this way. So I’m quite unhappy as I have a previous version of my app in App Store and need to upload an updated version.
So is this the end of Max apps in App Store? I can’t update existing apps or create new ones. I guess the only option is to recreate my apps currently pulbished on some other platform. I wonder whether I’m alone in this.
You’re not alone Lasseron. I’ve not made any comments myself because I simply haven’t gotten to the point yet of needing to update one of my apps on the store. I have communicated with Cycling in the past about the App Store issues we have had, and they’ve been responsive when we have had something specific for them to address. So far, I think we have had hunches as to what the current problem is, but it would be great if we could come up with the definitive cause of the current problem, along with the definitive solution. Then Cycling I’m sure would take a close look at it…
- This reply was modified 11 months by Dan Nigrin.
We should have a fix for this in a forthcoming update. Thanks for your patience — the App Store is a moving target. We do our best to keep up with the changes and enable publication of standalones built with Max.
Thanks for the update, I’m really glad to hear you’re working on it!
Ditto, thanks Jeremy!
Great news!! :)
cannot express how grateful I am.
Anyone tried uploading an app with Max 7.0.2 ?
It will probably fail, but a try doesn’t hurt! I do not have currently any app for uploading, but I will soon.
If anyone beats me to it, please post your try’s results!
I tried with 7.01, and got through to full app review, but was then rejected at that point with these complaints:
We found that ‘/Applications/General MIDI Player.app/Contents/MacOS/General MIDI Player’ links against : ‘@executable_path/../Frameworks/Chromium Embedded Framework.framework’ which appears to be missing.
We also found that the app links against: ‘/usr/local/lib/libplugin_carbon_interpose.dylib’ in a non standard manor which can cause stability problems.
I had removed the Chromium Embedded Framework.framework file from the app bundle because my app didn’t need it, and it was huge, but of course I could add it back in if necessary. But the other libplugin_carbon_interpose.dylib problem I did not have a way around.
Cycling knows about these issues, and is trying to address the problem.
Following up on this error that Timetoy reported:
unsealed contents present in the root directory of an embedded framework In subcomponent: /Users/MiniNew/Desktop/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework
I was getting that too, and the solution was to remove the
PkgInfo file from the root directory of that framework.
See this tech note from Apple for more on that, to quote:
* Do not put files or directories into the top directory of an app or framework bundle
* All content must be inside Contents or Versions respectively as described earlier
Timetoy I saw where you mentioned later on about removing
PkgInfo to solve a different error, but perhaps this clears up the "why" of it a bit more. (A
PkgInfo file, in case you’re wondering, is not required by Apple.)
Hey Leigh and others,
My Apple Developer membership ran out recently, and I asked myself if it would be worth the hundred bucks to renew it. I found this article by Steve Jobs talking about why Flash is not allowed on mobile devices:
"We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen."
This all seems to apply to Max as well. If the app store is a ‘moving target’ for C74 then Apple is playing a game that I don’t really think we’ll win.
My conclusion: I donated the $100 to charity (UNICEF) and switched over to developing custom apps for individual clients.
Still love Max and use it every day, but in terms of using it to develop for the App Store I think the writing is on the wall unfortunately.
Thanks Leigh for the info on PkgInfo. My $0.02, for whatever reason, I did not get that error without removing the PkgInfo, and was able to upload and get all the way to App Review…
Timetoy, don’t disagree with your assessment. But honestly, it’s been an uphill battle from the beginning with Apple for Max and the App Store, and I for one like the challenge! For me, the appeal has always been that I don’t have the time required to get schooled enough in Objective C or whatever other language to get to the level of building a standalone app, and Max gives me the ability to rapidly get there. There’s certainly pain at this last stage, but I’m optimistic that Cycling will come through for us yet again!
Hi guys. I’m exactly in the same situation of Dan. But I can’t also disagree with Timetoy. In fact, I’m thinking about to sell my applications privately, only because I don’t like to stop working on my applications because App Store gives to Cycling too many problems on every version they release. With this post I just want to thank you to Cycling staff for their job and I’ll continue to use Max/MSP for my applications, with or without the App Store.
Happy Patching ;)
Also remember that you can export a gen patch in C language and later implement the dsp code into Xcode, is not a solution but it is something.
Still hopping to finally get to the app store, my thanks to all Max developer for their work.
For the record, I have an Apple developer account for (for OS X apps, not iOS stuff), but I haven’t submitted anything to the Apple Store. I only distribute software through my own website. The signing I was doing was to make Gatekeeper not complain about running software from an "unknown developer".
Marvin brings up a good point, that Max is still an excellent environment for prototyping, and if you develop your signal processing with gen~, it’s easily ported to C++ code later.
Couple Max as a prototype environment with Apple’s new "Swift" language, and you may have an easier path to Apple-compliant OS X apps than trying to shoehorn Max to do the job. (Not to mention opening up the option of developing for iOS.)
Just FYI that the new version 7.0.6 that is now available once again allows for Mac App Store Max application success!
I’m trying it out now but get stuck. I sign the components and the whole app like this:
codesign -f -s "3rd Party Mac Developer Application: My Name" my.app/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle
codesign -f -s "3rd Party Mac Developer Application: My Name" my.app
productbuild --component my.app /Applications --sign "3rd Party Mac Developer Installer: My Name" --product my.app/Contents/Info.plist my.pkg
The package gets through Application Loader but then I get an email response from Apple stating that the components are already used by another app:
"CFBundleIdentifier Collision – The Info.plist CFBundleIdentifier value ‘com.cycling74.MSPReWireDevice’ of ‘my.app/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle’ is already in use by another application."
Not sure whether I should remove Info.plist files from each component or replace CFBundleIdentifier by my own app indentifier or something else? Googled did not give a definite answer.
First, I would ask whether you are using ReWire in your standalone – if not, you can safely remove that file from your app bundle and solve your problem that way.
I’ve never included that file in any of my App Store standalones so I’m guessing, but I would go the route of modifying the Info.plist for that bundle, changing the CFBundleIdentifier to something like "com.YOUR-COMPANY-NAME.MSPReWireDevice"
Please let us know how you make out.
Thanks for the tip, Dan! It worked. I will post a full list of steps I had to make once I’ll get through to Apple.
Right now, I seem to have one last obsticle: the good old Quicktime API. Apple reports: "Deprecated API Usage – Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs."
I have not slimmed my app and have pretty much all subcomponents in the package. I started by removing /Contents/Resources/C74/extensions/max/qtimage.mxo which clearly had QT calls inside. Any hints where to look next? Probably Jitter components?
First – I would strongly suggest slimming down your app – the less stuff in there, the fewer places for you to run into an issue with Apple.
Along these lines – have you used the new options in the standalone object Inspector to remove things? Specifically, you’ll need to uncheck CEF Support, and I would also strongly recommend unchecking Gen Support and Include C74 Resources. Try again after you do those.
Dan, thanks again! I did not notice these new options in standalone object myself. After your tips and lots of trial and error I got my app successfully uploaded!
Here’s how I got my app submitted to App Store with Max 7.0.6:
1. Uncheck "CEF Support" and "Include C74 Resources" from standalone object’s attributes.
Otherwise I get the error "Deprecated API Usage – Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs." I did not uncheck "Gen Support" as my app uses it.
2. Build Application.
3. Edit /Contents/Info.plist file with your own app info: version numbers and "Application Category" seem to be at least mandatory.
4. Change "Bundle identifier" value from "com.CYCLING74.component" to "com.MYAPP.component" in Info.plist files inside:
Otherwise I get "CFBundleIdentifier Collision" errors.
5. Sign components:
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/libmozjs185.dylib --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/JitterAPI.framework/Versions/A --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/JitterAPI.framework --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAPI.framework/Versions/A --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAPI.framework --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAudioAPI.framework/Versions/A --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAudioAPI.framework --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxLua.framework/Versions/A --entitlements MYAPP.entitlements codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxLua.framework --entitlements MYAPP.entitlements
My app is using microphone, so I have to use entitlements.
6. Sign the whole app and create package to be uploaded using Application Loader:
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP --entitlements MYAPP.entitlements productbuild --component MYAPP /Applications --sign "3rd Party Mac Developer Installer: DEVELOPER NAME" --product MYAPP/Contents/Info.plist MYAPP.pkg
Few optional steps:
– Tweak application menus by following Dan Nigrin’s slides at https://cycling74.com/toolbox/making-a-slick-max-standalone-presentation-from-expo-74-workshop
– Change the app icon which has to include both normal and retina versions: https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html.
– I could probably slim my app more by removing unnescessary components.
Good news that you got it uploaded successfully! On quick look at your post above, one thing I wouldn’t recommend is including the C74 resources – it adds size to your app bundle, and I’ve found it to not really be necessary, but your mileage may vary. But if you do exclude those, then that will eliminate some of the work that you then have in your step #4.
I am now at the stage of signing my app before submitting it.
I get some mistakes, that I can not understand why.
I follow Lasseron’s guide, changing the "bundle identifier"and signing all that needs signing.
But, when signing "MyApp.app" bundle from the terminal I get the following 2 lines:
"path/to/app/MyApp.app: replacing existing signature"
"path/to/app/MyApp.app: code objects not signed at all in subcomponent : "path/to/app/MyApp.app/Contents/Icon"
The same happens with "path/to/app/MyApp.app/Contents/MacOS/MyApp".
I get two errors if I build the .pkg and try to upload it through the Application Loader. Once about "MyApp.app" and once about the MyApp.app/Contents/MacOS/myApp", for not being signed properly, and two more errors:
"Your package contains a file ‘MyApp.app/Contents/Icon" with a name that contains invalid characters. Avoid using control characters in the file names."
"Your package contains a file ‘MyApp.app/Contents/MacOS/Icon" with a name that contains invalid characters. Avoid using control characters in the file names."
I have no files named "Icon" in either directory.
Does anyone have an idea why these errors appear?
Well, as it seems, "Google Drive" was responsible for this.
First I rebuilt the app (in my Google Drive folder), did all from scratch, same problem.
Another clean build to desktop, no problem at all.
So, don’t sign and (google) drive…
Anyway, the pkg is now uploading fine, so the signing steps by Lasseron above are very correct.
Glad you solved it Nik! That makes sense; Google Drive was probably modifying the file icon (I know that Dropbox does the same thing, to indicate the sync status of the file)….
Good luck with the approval process!
For those of you who get your apps approved, please post to this thread so I can keep the list of Max apps on the store updated!
Forums > Dev