Mac App Store Refusal because of QTKit API's
Scott Selvia
sselvia at gmail.com
Fri Oct 9 10:32:37 UTC 2015
Same results…Apple just does not like API’s used within the JRE
October 8, 2015 at 9:10 PM
From Apple
2.5 - Apps that use non-public APIs will be rejected
2.31 - Apps that are not sandboxed appropriately may be rejected
2.5
The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application:
com.apple.security.temporary-exception.files.absolute-path.read-write: True
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
2.31
Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary.
ubrk_getRuleStatus
ubrk_setUText
ucnv_getCanonicalName
ucnv_reset
ucol_strcollIter
For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues <https://developer.apple.com/library/mac/#qa/qa1773/_index.html#//apple_ref/doc/uid/DTS40013260>.
See App Sandboxing <https://developer.apple.com/devcenter/mac/app-sandbox/> for links to essential video and documentation to learn how to sandbox your application.
As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed will be rejected. Updates to non-sandboxed apps may be submitted if they only addresses bug fixes and new OS X feature adoption provided that your app was on the Mac App Store prior to June 1st.
Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support <https://developer.apple.com/membercenter/index.action#techSupport>.
If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you're doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions <https://developer.apple.com/library/mac/#qa/qa1778/_index.html>.
For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter <https://developer.apple.com/library/mac/#technotes/tn2004/tn2123.html>.
Here is my entitlements, so it must be somewhere, I just don’t know where:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
</dict>
</plist>
> On Oct 2, 2015, at 2:36 PM, Scott Selvia <sselvia at gmail.com> wrote:
>
> Chris,
>
> The app is in "waiting for review" state again. Last time it sat there for about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I hope I will hear something soon. The bugs, I plan on updating them with a status note ??? This weekend.
>
> I thinking Apple has some integration issues between OS X apps and iOS apps. My current bundle has a note the it does not include beta testing entitlement. From our understanding of the apple docs, that is for iOS apps only. We do not have that option enabled in iTunes connect
>
> Scott
>
> Sent from my iPhone
>
>> On Oct 2, 2015, at 1:53 PM, Chris Bensen <chris.bensen at oracle.com> wrote:
>>
>> Hi Scott,
>>
>> Let me know what happens with this because we are tracking it with two bugs on our end — one in the packager and one in WebKit. I’ve spoken with a couple friends at Apple and they don’t think it’s right either but none of them have control over the AppStore. At this point there’s really nothing we can do. With regards tot he CFBundleIndentifier collision, that’s another problem on their end as far as I can tell.
>>
>> Thanks,
>> Chris
>>
>>
>>> On Sep 30, 2015, at 3:41 PM, Scott Selvia <sselvia at gmail.com> wrote:
>>>
>>> See you at JavaOne, hopefully I’ll have good results to pass along.
>>>
>>> Again thanks to ALL, there are two Apple bug reports: 22751708 - CFBundleIdentifier Collision for JavaFX Application because of the embedded JRE Info.plist and 22923832 - Rejection of App based on Deprecated API’s used by JavaFX webkit and component and API’s not reference by App.
>>>
>>> I’ll update the thread once I here back from ITunes Connect on the App submit or when Apple gets back to me on the bug reports.
>>>
>>>> On Sep 30, 2015, at 5:43 PM, Chris Bensen <chris.bensen at oracle.com> wrote:
>>>>
>>>> I’ll be doing the JavaOne Packager talk and will include any information I can on the subject of the App Store that’s relevant.
>>>>
>>>> Chris
>>>>
>>>>
>>>>> On Sep 30, 2015, at 12:09 PM, Scott Selvia <sselvia at gmail.com> wrote:
>>>>>
>>>>> I'll update the thread when I get a response from Apple on my latest submission. I believe someone is doing an App Store talk or packager talk at JavaOne. They can include the information in the thread
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Sep 30, 2015, at 3:05 PM, Scott Selvia <sselvia at gmail.com> wrote:
>>>>>>
>>>>>> Phil,
>>>>>>
>>>>>> Yes I've done that and I've re-submitted the app again
>>>>>>
>>>>>> I agree that I should not be penalized by the JRE one would hope that Oracle and Apple worked out the JRE do's and don't when it was decided that Java applications can be posted to the OS X App Store. However I don't think it will do much good for me to open Apple bugs. Oracles stick is much bigger than mine!!!
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On Sep 30, 2015, at 2:54 PM, Phil Race <philip.race at oracle.com> wrote:
>>>>>>>
>>>>>>> It looks like there may be something to this :-
>>>>>>>
>>>>>>> On mac fx in 8u60 is linking webkit against the system icu library to find these symbols.
>>>>>>>
>>>>>>> $ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus
>>>>>>> U _ubrk_getRuleStatus
>>>>>>> $ otool -L libjfxwebkit.dylib | grep icu
>>>>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0)
>>>>>>>
>>>>>>> webkit has as "undefined" a much longer list than what Apple complained about
>>>>>>> so it is not clear if they regard the entire library as off-limits or just some subset.
>>>>>>>
>>>>>>> So I don't think this is anything to do with QtKit but is a webkit problem.
>>>>>>> Removing that dylib is the apparent workaround, assuming you don't need it.
>>>>>>> If the packager can't handle that for you I suppose you need to manually
>>>>>>> get rid of it out of your JDK directory before packaging.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>> On 09/30/2015 10:44 AM, Scott Selvia wrote:
>>>>>>>> Will do
>>>>>>>>
>>>>>>>> It seems Apple is not distinguishing the difference of who is using the APIs. Just like the jfx media qt dylib filtered out of the Java packager process when building a Mac store app. I guess at this point they feel the WebKit dylib falls into the category.
>>>>>>>>
>>>>>>>> I had an apple issue with the embedded info.plist bundle ID that is part of the jre packaged with the Mac application package generated with the packager. I had to hack the jdk update 60 info.plist file and change the bundle ID with a hashcode suffix. This I opened an apple bug for stating that embedded frameworks should not trigger a bundle collision ID error when uploading an application. I have not had any additional responses
>>>>>>>>
>>>>>>>> I guess I'll add another bug for embedded frameworks (in this case the JRE) using deprecated APIs
>>>>>>>>
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On Sep 30, 2015, at 12:45 PM, Donald Smith <donald.smith at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Please let us know what you hear back with Apple on this given the information below we hope they will see this as an oversight.
>>>>>>>>>
>>>>>>>>> - Don
>>>>>>>>>
>>>>>>>>>> On 30/09/2015 12:28 PM, Phil Race wrote:
>>>>>>>>>> Yes, these look like ICU functions which so far as I know FX only
>>>>>>>>>> references from its *own* internal copy of webkit which in turn has a copy of ICU.
>>>>>>>>>>
>>>>>>>>>> What is very odd is that Apple is essentially then objecting to referencing
>>>>>>>>>> functions that are internal to your app. ie referenced by your app and also
>>>>>>>>>> fulfilled by your app, whereas I assume the app store checking should be
>>>>>>>>>> against deprecated Apple APIs that you reference in your app and that
>>>>>>>>>> are fulfilled by OSX (or iOS).
>>>>>>>>>>
>>>>>>>>>> So something seems wrong here.
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>>> On 09/30/2015 09:19 AM, Scott Selvia wrote:
>>>>>>>>>>> Chris,
>>>>>>>>>>>
>>>>>>>>>>> I'll update iTunes connect with that information and ask them to clarify
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the additional information, Danno explained they are used in the WebKit dylib
>>>>>>>>>>>
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>>> On Sep 30, 2015, at 12:08 PM, Chris Bensen <chris.bensen at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Scott,
>>>>>>>>>>>>
>>>>>>>>>>>> Those APIs are for the text system ICU. I believe the App Store team may be in error. Perhaps they accidentally copied the wrong forbidden APIs when writing the message.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Chris
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 29, 2015, at 3:15 AM, Scott Selvia <sselvia at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I’m using JDK 8 update 60 and I just received an email from Apple saying that my application is using deprecated QTKit API’s. I’ve reviewed Danno Ferrin’s JavaOne session from last year; it says that Update 40’s libjfxmedia_qtkit.dylib or Update 20’s libjfxmedia.dylib should be removed and are by the packager. I have this line in my packager output from the packager, as you can see the libfxmedia.dylib is in my app and pkg. Is this an oversight by the packager and the libfxmedia.dylib should also be removed from my packaged application?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The original message from ITunes Connect said that these API’s are referenced, when I questioned Apple as to what code was referencing these they said it was the JavaFX Media library.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ITunes Connect Responce:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.31
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ubrk_getRuleStatus
>>>>>>>>>>>>> ubrk_setUText
>>>>>>>>>>>>> ucnv_getCanonicalName
>>>>>>>>>>>>> ucnv_reset
>>>>>>>>>>>>> ucol_strcollIter
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dear developer,
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have discovered one or more issues with your recent delivery for "Examine-IT Pro". To process your delivery, the following issues must be corrected:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Deprecated API Usage - Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once these issues have been corrected, you can then redeliver the corrected binary.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The App Store team
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit., -vvvv, --entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/macosx/Examine-IT Pro.entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
>>>>>>>>>>>>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib: signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia]
>>
More information about the openjfx-dev
mailing list