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=0×0(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=0×0(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=0×0(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=0×0(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=0×0(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=0×0(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 6 months 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 3 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.
Forums > Dev