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 3 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.