Have you let Marco know about this, Oliver?
Yes
Thanks for doing that…
Just made a quick simple app to check if an app has QT dependency.
Seems a lot of things are using QT.
http://www.osxbytes.com/qtdependecycheck.zip
Drag’n’drop any app on it to scan.
Guess my MAS app isn’t gonna get it’s update I’m working on for a while…
So who is left holding THAT baby now … looks like this unpleasant surprise comes in a very bad moment. Xojo is heading toward the next hurdle, probably soon starting Alpha,Beta for iOS builds etc. - and now many get MAS stuck because plenty of stuff in the Xojo framework seems to be built on QuickTime.
I’m not expecting a quick solution to this. At least if Xojo wants to come up with a clean, solid and reliable replacement to those QuickTime calls. Sounds like a lot of work to me. Merry Christmas …
We’re not the only ones caught by Apple suddenly rejecting the use of QTKit, Apples previously recommended API.
Other dev environments are seeing similar issues with the use of QTKit.
Unfortunately policy changes like this are unannounced & this is not the first time Apple changed policy without notice.
QTKit is Apple’s 32 bit wrapper that calls into QuickTime - hence the QuickTime dependency.
This one is a surprise:
RBShell.xojo_plugin_0.dylib -> QT dependency
Not sure why using a shell needs to be QT depended.
I presume they use some shared code for this libraries and part of it may be a call to initialize quicktime.
Maybe Apple is getting OS X ready for 64bit only. Wouldn’t be surprised if OS X 10.10 will only run 64bit apps.
So if others are drowning, you too? Never look at your neighbour but stay in front of everyone.
Just my two cents though …
I see no sign that Xojo is sitting back and treating this as an unimportant development. I read Norman’s post as simply saying that the problem was caused by Apple’s abrupt implementation of a decision to exclude apps that use APIs that have been deprecated for Mac OS X 10.9, not by Xojo’s lack of attention to detail…
No - I stand on top of them & push them under so I can get out 
Apple made no noise about requiring AVfoundation or that they would start reject apps using QTKit
They just suddenly did it and its caught us & several other tool vendors by surprise.
This isn’t the first time a policy change has been announced by rejecting applications though.
True, and I am convinced Xojo will adapt very soon. 
BTW but I am a bit more worried about 64bit. As I am said before, I wouldn’t be surprised Apple is going to leave 32bit in a next OSX version. Now THAT would hurt Xojo a lot. (I know 64bit is planned for Q3 though)
Just to be clear, QTKit is available to 64-bit applications and QuickTime itself is not. We transitioned entirely over to QTKit a while back, sans one call to the QuickTime C API.
It’s also hit us at a bad time in terms of release cycles. We’re very close to shipping r4 and transitioning is a job that has to be done by the beginning of beta testing.
[quote=51854:@Christoph De Vocht]Just made a quick simple app to check if an app has QT dependency.
Seems a lot of things are using QT.
http://www.osxbytes.com/qtdependecycheck.zip
Drag’n’drop any app on it to scan.[/quote]
Great. Now we have a diagnostic tool. Thank you !
You do realize that Geoff considers this a violation of his EULA?
Same for that.
I am surprised that neither Norman nor Geoff hasn’t pointed out this yet. Both did so multiple times when I did less.
Now I have checked my app with the “QT Dependency Checker”:
dtPlugins.rbx_0.dylib -> QT dependency
RBAppearancePak.rbx_0.dylib -> QT dependency
rbframework.dylib -> QT dependency
RBHTMLViewer.rbx_0.dylib -> QT dependency
RBInternetEncodings.rbx_0.dylib -> QT dependency
RBREALSQLDatabase.rbx_0.dylib -> QT dependency
I send this application to the MAS. It was not rejected and it is waiting for review. So not all QT dependencies are critical.
No I didn’t, in which case I need to private conversation with Geoff as App Wrapper already does a lot of exploration of the rbframework.dylib, and with this Quicktime fiasco, it may do more!