Re: Mac App Store Refusal because of QTKit API's

[Dr. Michael Paus]

Am 09.10.15 um 13:43 schrieb Scott Selvia:


So my question now, Is there a JavaFX application in the Mac OSx Store?

There still is the Ensemble 8 app in the OSX store. But it is already more
than a year old.


com.apple.security.temporary-exception.files.absolute-path.read-write

—>

Thanks,

Scott


On Oct 9, 2015, at 6:32 AM, Scott Selvia  wrote:

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 
.

See App Sandboxing  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 
.

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 .

For information on how to symbolicate and read a crash log, please see Technical Note 
TN2123 - CrashReporter 
.

Here is my entitlements, so it must be somewhere, I just don’t know where:


http://www.apple.com/DTDs/PropertyList-1.0.dtd 
">


com.apple.security.app-sandbox
 
com.apple.security.files.user-selected.read-write
 





On Oct 2, 2015, at 2:36 PM, Scott Selvia mailto:ssel...@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 mailto:chris.ben...@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 mailto:ssel...@gmail.com>> wrote:

See you at JavaOne, hopefully I’ll have good results to pass along.

Again thanks to ALL, there are two Apple 

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

I also found that the temporary-exception in Apples response was in my Inherit 
entitlements file however, it was commented out.  This was added after the 
first submission did not upload by using the App Loader application because it 
complained about missing entitlements.  After doing some research on the ITunes 
Connect site it said that OSx apps also needed the temporary exception.  Once 
that was set in the Inherit entitlement our application was able to be 
uploaded, which then resulted in a rejected because of the deprecated API’s 
used within the JRE.  At this point I’m updating my bug on the apple bug report 
system and going to use one of my code tech support requests to get some 
answers that will get me past this point.  To summarize I updated the JDK/JRE 
Bundle ID to prevent a collision and I removed the JavaFX WebKit dylib that the 
Apple review team complained about last time.

I’ve attached the AppLoaderAPIAnalysisFile just in case someone at Oracle can 
see something that Apple is complaining about.

So my question now, Is there a JavaFX application in the Mac OSx Store?

com.apple.security.temporary-exception.files.absolute-path.read-write

—>

Thanks,

Scott

> On Oct 9, 2015, at 6:32 AM, Scott Selvia  wrote:
> 
> 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 
> .
> 
> See App Sandboxing  
> 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 
> .
> 
> 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 
> .
> 
> For information on how to symbolicate and read a crash log, please see 
> Technical Note TN2123 - CrashReporter 
> .
> 
> Here is my entitlements, so it must be somewhere, I just don’t know where:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> 
> 
>   com.apple.security.app-sandbox
> 
>   com.apple.security.files.user-selected.read-write
> 
> 
> 
> 
> 
>> On Oct 2, 2015, at 2:36 PM, Scott Selvia > > 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

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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 
.

See App Sandboxing  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 
.

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 
.

For information on how to symbolicate and read a crash log, please see 
Technical Note TN2123 - CrashReporter 
.

Here is my entitlements, so it must be somewhere, I just don’t know where:


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


com.apple.security.app-sandbox

com.apple.security.files.user-selected.read-write





> On Oct 2, 2015, at 2:36 PM, Scott Selvia  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  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  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 b

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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  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  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  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  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  
>> 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  
> wrote:
> 
> Hi Scott,
> 
> Those APIs are for the text system ICU.

Re: Mac App Store Refusal because of QTKit API's

[Chris Bensen]

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

Re: Mac App Store Refusal because of QTKit API's

[Donald Smith]

I agree with Phil.  Apple loves to hear from developers and this is 
*their* sandbox that *they* completely control.  If you're aware of 
sticks I can use over Apple, I'd love to know what they are! :) Mostly 
it's just keeping an open dialogue and the more people that point these 
things out the better.


 - Don


On 30/09/2015 3:15 PM, Scott Selvia wrote:

I will and thanks to all for you help

Sent from my iPhone


On Sep 30, 2015, at 3:11 PM, Phil Race  wrote:

It may still be worth you following up as they at least ought to
answer why they identified these as QTKit symbols when they
demonstrably are not ..

-phil.


On 09/30/2015 12:05 PM, Scott Selvia 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  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  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  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  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 
entitle

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

I will and thanks to all for you help

Sent from my iPhone

> On Sep 30, 2015, at 3:11 PM, Phil Race  wrote:
> 
> It may still be worth you following up as they at least ought to
> answer why they identified these as QTKit symbols when they
> demonstrably are not ..
> 
> -phil.
> 
>> On 09/30/2015 12:05 PM, Scott Selvia 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  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  
> 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  
 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  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 
> pa

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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

Re: Mac App Store Refusal because of QTKit API's

[Phil Race]

It may still be worth you following up as they at least ought to
answer why they identified these as QTKit symbols when they
demonstrably are not ..

-phil.

On 09/30/2015 12:05 PM, Scott Selvia 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  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  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  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  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 submission

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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

Re: Mac App Store Refusal because of QTKit API's

[Phil Race]

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  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  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  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., 
-, --entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
 Pro.entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
 Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
/

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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  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  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  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., -, --entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
>  Pro.entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
>  
> Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
>  
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]
> 

Re: Mac App Store Refusal because of QTKit API's

[Donald Smith]

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  
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  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., -, --entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT 
Pro.entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT 
Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib] 

/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]

Re: Mac App Store Refusal because of QTKit API's

[Phil Race]

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  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  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., 
-, --entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
 Pro.entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
 Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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  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  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., 
>> -, --entitlements, 
>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
>>  Pro.entitlements, 
>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
>>  
>> Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]
> 

Re: Mac App Store Refusal because of QTKit API's

[Chris Bensen]

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  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., 
> -, --entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
>  Pro.entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
>  
> Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]

Mac App Store Refusal because of QTKit API's

[Scott Selvia]

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., 
-, --entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
 Pro.entitlements, 
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
 Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
/var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/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]