MAS Build rejected with: Apps that use non-public APIs will be rejected #5618

Closed
slaskis opened this Issue May 20, 2016 · 13 comments

Projects

None yet

4 participants

@slaskis
slaskis commented May 20, 2016
  • Electron version: 1.1.1
  • Operating system: Mac OS X 10.11.4

After the entitlement fixes to the MAS builds in Electron 1.1.1 we now got this rejection message:

From Apple
2.5 - Apps that use non-public APIs will 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:

: AXTextMarkerCreate
: AXTextMarkerGetBytePtr
: AXTextMarkerRangeCopyEndMarker
: AXTextMarkerRangeCopyStartMarker
: AXTextMarkerRangeCreate

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.

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.

And after running some commands to try to figure out where the private API:s might come from:

$ find dist/Example-mas-x64/Example.app/ -type f -perm -111 -print -exec strings {} 2> /dev/null \; | grep AXText
$ find dist/Example-mas-x64/Example.app/ -type f -perm -111 -print -exec otool -ov {} 2> /dev/null \; | grep AXText
$ find dist/Example-mas-x64/Example.app/ -type f -perm -111 -print -exec nm {} 2> /dev/null \; | grep AXText

We found that it is to be found in Electron Framework:

Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
                 U _AXTextMarkerCreate
                 U _AXTextMarkerGetBytePtr
                 U _AXTextMarkerRangeCopyEndMarker
                 U _AXTextMarkerRangeCopyStartMarker
                 U _AXTextMarkerRangeCreate

And a quick google search takes us to this chromium code.

I'm guessing there will have to be some update to libchromiumcontent which skips these in the case of a MAS_BUILD?

But we're getting closer to be able to get Electron apps up on the App Store!

@zcbenz zcbenz added bug osx labels May 20, 2016
@zcbenz
Contributor
zcbenz commented May 20, 2016

Thanks for reporting this back, those calls seem to be introduced by Chrome 50, I'll patch them out.

@mcfedr
mcfedr commented May 21, 2016

I have the same rejection

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:

In framework '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices':

AXTextMarkerCreate
AXTextMarkerGetBytePtr
AXTextMarkerRangeCopyEndMarker
AXTextMarkerRangeCopyStartMarker
AXTextMarkerRangeCreate

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.

@zcbenz zcbenz referenced this issue in electron/libchromiumcontent May 21, 2016
Merged

Comment out AXTextMarker* APIs for MAS build #212

@zcbenz zcbenz added a commit that referenced this issue May 21, 2016
@zcbenz zcbenz Update libchromiumcontent for #5618 363ab20
@mcfedr
mcfedr commented May 23, 2016

@zcbenz do you know when a new release will be made?

@mmm117
mmm117 commented May 23, 2016

Anyone confirm this fix work for MAS?

@slaskis
slaskis commented May 23, 2016

I currently have an app waiting for review. I'll ping here when it's reviewed.

@slaskis
slaskis commented May 24, 2016

It got through! Thank you @zcbenz, I believe we have a winner

@zcbenz
Contributor
zcbenz commented May 24, 2016

@slaskis Awesome, thanks so much for testing the MAS build!

@davemackintosh davemackintosh added a commit to Floato/electron that referenced this issue May 31, 2016
@zcbenz @davemackintosh zcbenz + davemackintosh Update libchromiumcontent for #5618 b32a21f
@mmm117
mmm117 commented May 31, 2016

@slaskis , did you submit a copy of U.S. Encryption Registration (ERN) approval when submitting your app to MAS?

As mentioned on this page, it seems we need to do it for all Electron built apps:
https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

Cryptographic Algorithms Used by Electron
Depending on the country and region you are located, Mac App Store may require documenting the cryptographic algorithms used in your app, and even ask you to submit a copy of U.S. Encryption Registration (ERN) approval.

@slaskis
slaskis commented Jun 1, 2016

@mmm117 actually I don't think we did, we selected "no" the first time and any updates only ask if we changed anything regarding encryption since the last release which we technically didn't :P

our app has no network communication though so maybe since we don't actually use TLS they let it pass? but who knows what happens behind the wall of app store reviews...

@mcfedr
mcfedr commented Jun 1, 2016 edited

👍 I have done exactly the same thing

My app does use TLS

@mmm117
mmm117 commented Jun 1, 2016

@slaskis @mcfedr So Apple doesn't check actually and they just trust us? Since it mentioned if the app contains or incorporate cryptography, not necessarily use, we will need to answer "YES" then...

@mcfedr
mcfedr commented Jun 1, 2016

I recently read that any app, even native and using apple http libraries, has to answer yes, just for using https

@mmm117
mmm117 commented Jun 1, 2016 edited

As I know, France also need this kind of approval, developer need to apply another approval from them if you sell your app in France too..

Good to read:
https://carouselapps.com/2015/12/09/mac-ios-applications-breaking-rules-removed/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment