Seems like this rejection is a little unfair, no prior warning, just rejection, damn!
I was beginning to think it might be how Xojo loaded images, I haven’t spoken with Joe yet to confirm my theory or not.
if that is the case, then fret not my dear fellows, for there are plenty of alternatives. Use CGImages (via MacOSLib or MBS) or NSImages (again via MacOSLib, MBS or Retina Kit), then either convert these to Xojo images or use them natively.
That seemed to work for me as well using the carbon. At least xojo knows now. I wonder when apple started checking for this… Thanks to all of those who commented on this thread.
Carbon will not work perfectly with Sandboxing. I think Xojo Inc will need to check this as soon as possible.
So they can make sure they don’t link to the deprecated frameworks.
Still functions could be loaded in case app runs on older system or needs deprecated methods.
Thanks @Christian Schmitz I guess I will just wait to upload it if it’s going to cause sandboxing issues. Hopefully it will be an easy fix for them. I appreciate you creating the bug report for us.
Yeah, Carbon’s not an option for me. Our apps have been modify so much for Cocoa that reintroducing Carbon would cause our code to go on strike. 
Question does “folderItem.OpenAsPicture” use the Quicktime API’s in Xojo Cocoa?
Well at least the bug is marked as fixed hopefully that means it will be in the next release - <https://xojo.com/issue/31107>
If so, hopefully it gets fixed in a possible Xojo 2013 Release 3.4 maybe.
The 4th app that we submitted has now been approved without getting this Quicktime error.
I think folderItem.OpenAsPicture uses CoreGraphics or NSImage.
.OpenAsPicture has been deprecated for quite some time, according to the docs…
http://documentation.xojo.com/index.php/FolderItem.OpenAsPicture
[quote]This item has been DEPRECATED since version 2010r3 and should no longer be used.
Please use Picture.Open as a replacement.[/quote]
Probably a stupid question but is there a way to see if an app uses the Quicktime framework?
Well, the question is what Apple tests.
So loading it dynamically at runtime may not be detected by Apple.
App Wrapper does allow framework inspection (to some degree), select “Libraries used by Application” from the “View” menu.
Sorry, it shows what libraries are being linked to.
Hi,
My app has been rejected because of this issue right now. I have a simple app with no backdrops, only three icons to embellish my toolbar. I am disappointed. Is there no quick solution?
Regards,
Payam
I know that Xojo are working on it, we’re all a bit disappointed and frustrated - Apple gave no warning and they give no indication as to what or where exactly is linking to Quicktime, which is making the whole thing difficult to nail.
I opened a few RB dylib files with TextEdit only to see what is in there. There are in fact references to Quicktime. Can they be removed safely just through deleting those lines? Just questioning.
Nope! I wouldn’t recommend using a text editor to edit a an executable file at all. Even if you pull the linking out of the library, you may cause the application to become unstable when it needs to access a Quicktime function (as the library is no longer loaded).
Some people have had success in submitting a Carbon application to the App Store, I wouldn’t recommend that as Carbon is a PITA to Sandbox (isn’t Sandboxing anyway), but if you need to ship then that’s what I would suggest.
I need the cuetext for my text fields, and I want a text field in the toolbar. That does not work with carbon.
But what if I change the word QuickTime to TimeQuick in all those files. So Apple won’t detect anything. I don’t think that my app uses Quicktime functions anyway. I guess I have just to try it. I want the app uploaded tonight, otherwise I can’t sleep…