Forums > Dev

max standalone crash on mac 10.8.2 after codesigning with entitlements

January 8, 2014 | 1:08 pm

Scratch that, I see the test you’re referring to now in the link you provided above, thanks..


January 13, 2014 | 4:35 am

How did you do this test? I can try with my application and see what happen.


January 14, 2014 | 7:28 am

you can use the nm command-line tool for this:

https://developer.apple.com/library/mac/technotes/tn2300/_index.html#//apple_ref/doc/uid/DTS40012852-CH1-NM


January 17, 2014 | 8:58 am

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?


February 7, 2014 | 12:45 am

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


February 15, 2014 | 3:58 am

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?


February 15, 2014 | 5:36 am

That would be an awesome hack if someone could figure it out…


February 15, 2014 | 6:49 am

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.


February 15, 2014 | 7:29 am

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.


February 15, 2014 | 9:50 am

Nice attempt! I think we’re just going to have to hope that Cycling can address this…


February 19, 2014 | 5:38 am

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.


February 19, 2014 | 7:41 am

Yes, I’ve let them know about it.


March 16, 2014 | 4:43 am

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.


April 4, 2014 | 2:07 pm

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)


April 4, 2014 | 2:29 pm

Unfortunately no..


April 5, 2014 | 8:10 am

Don’t give up hope guys – I have a good feeling about this. ;-)


April 8, 2014 | 7:41 am

Hi everyone,
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


April 8, 2014 | 7:55 am

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.

April 8, 2014 | 9:50 am

Hi Dan,
I used the full path of the app.
/Users/nikolas/Desktop/My-app.app/etc…
Where should i put the app to use the command without the full path ? Does it make any defference ?


April 8, 2014 | 9:55 am

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


April 8, 2014 | 10:07 am

I hope so! Well, I will post if anything new comes up.
Nikolas


April 9, 2014 | 2:01 am

I hope Cycling will do something for this problem..


April 9, 2014 | 10:23 am

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


April 11, 2014 | 6:57 am

Interesting, thanks – I’ll report to the folks at Cycling.


April 23, 2014 | 3:39 am

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…


April 23, 2014 | 4:54 am

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!

Nikolas


April 23, 2014 | 9:45 am

Hi Nikolas,

Thanks for the report. Have you manually removed the qtimage extension from the standalone? That would also be necessary.

-Joshua


April 26, 2014 | 6:15 am

Hi Joshua,
Yes, I have removed all extension but polybuffer.mxo and setplugpath.mxo.

Nikolas


May 26, 2014 | 11:24 am

Hello!

Any news on the matter ?


June 13, 2014 | 3:30 am

I don’t know anything. I think that this problem can be solved only by Cycling. We can’t do anything I think..


July 2, 2014 | 11:41 am

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.


Viewing 31 posts - 151 through 181 (of 181 total)