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!
Nikolas, you’re using this format for the nm command?
nm -m "YOUR-APPLICATION.app/Contents/MacOS/YOUR-APPLICATION" | egrep "QuickTime|QTKit"
If so, that’s weird that you’re not showing any QuickTime usage if so…
- This reply was modified 4 months by Dan Nigrin.
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!