Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac App Store Private API Rejection: Electron 5.0.10 #20027

Closed
2 tasks done
thomasdao opened this issue Aug 29, 2019 · 143 comments · Fixed by #20965
Closed
2 tasks done

Mac App Store Private API Rejection: Electron 5.0.10 #20027

thomasdao opened this issue Aug 29, 2019 · 143 comments · Fixed by #20965

Comments

@thomasdao
Copy link

@thomasdao thomasdao commented Aug 29, 2019

Issue Details

  • Electron Version: 5.0.10

Rejection Email

ITMS-90338: Non-public API usage - The app contains or inherits from non-public classes in Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework: CAContext, CALayerHost, NSAccessibilityRemoteUIElement, NSNextStepFrame, NSThemeFrame, NSURLFileTypeMappings . If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

@thomasdao
Copy link
Author

@thomasdao thomasdao commented Aug 29, 2019

I downgrade Electron to 5.0.9 and still get rejection email.

@JustinPierce
Copy link

@JustinPierce JustinPierce commented Aug 29, 2019

I got this rejection this morning for Electron 5.0.4, and also for 5.0.10. I think something has changed on Apple's end.

@lubo08

This comment was marked as off-topic.

@MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Aug 29, 2019

List of private APIs detected:

  • _fileport_makefd
  • _fileport_makeport
  • CAContext
  • CALayerHost
  • NSAccessibilityRemoteUIElement
  • NSNextStepFrame
  • NSThemeFrame
  • NSURLFileTypeMappings

Please only comment on this issue if your rejection email has APIs that are not in the list above. If you just comment +1 your comment will be removed. If you are also experiencing this rejection please react to this issue with 👍 to indicate so.

@mytran
Copy link

@mytran mytran commented Sep 2, 2019

Developer relations responded and stated that they believe that the problem was on issue on their end and they will look into it. I checked tonight and my previously rejected builds are available now in App Store Connect.

@ogi1982
Copy link

@ogi1982 ogi1982 commented Sep 2, 2019

I just checked as well and my previously rejected build (Electron 4.2.9) is also available on store.

@MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Sep 2, 2019

Thanks @gaodeng , @mytran and @ogi1982 for that new information. It sounds like apple got a few reach-outs and either corrected their system or whitelisted the framework temporarily. Still waiting to hear back as to what exactly happened.

I'll leave this open till at least next week where hopefully we'll have more info

@thomasdao
Copy link
Author

@thomasdao thomasdao commented Sep 2, 2019

I can now upload my build with Electron 5.0.10 to the Store as well. I'll probably leave to @MarshallOfSound to close this ticket :)

@sofianguy sofianguy added this to Unsorted Issues in 5.0.x Sep 18, 2019
@ffflorian
Copy link
Contributor

@ffflorian ffflorian commented Oct 30, 2019

My app using Electron 4.2.12 was just rejected because of the following APIs:

CAContext
CALayerHost
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

@iwodoudou
Copy link

@iwodoudou iwodoudou commented Oct 31, 2019

Electron 5.0.11

Your app uses or references the following non-public APIs:

CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Oct 31, 2019

electron : 6.0.10

Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:

CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

@aydogankaragoz
Copy link

@aydogankaragoz aydogankaragoz commented Oct 31, 2019

electron 3.0.2

Your app app links against the following non-public framework(s):

CAContext
CALayerHost
NSURLFileTypeMappings

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Oct 31, 2019

@MarshallOfSound is there anything we can do to help ?
i don't have the skills to fix this my self

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Oct 31, 2019

@zcbenz looks like you have done patches before can you do a new one for these ?

sorry for stressing but i have important update to my app that needs to be deployed

@mytran
Copy link

@mytran mytran commented Oct 31, 2019

Try appealing and state that you're using Electron and those APIs are internal to Electron:
https://developer.apple.com/contact/app-store/?topic=appeal

@yegor-slate
Copy link

@yegor-slate yegor-slate commented Nov 1, 2019

Updated to latest electron v7.0.0 and got rejection again.

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Nov 1, 2019

@mytran
don't think do an appeal will help more than maybe once
better try to fix this

i see its a patch file in the code base
patches\chromium\mas_no_private_api.patch

if we somehow can add the APIs there
I have not figure out yet how to do it

and for those that know how to do this.
If they don't have time to fix it maybe we can sponsor them?
time is money :)

If everyone that needs this to be fixed donated some $
I guess it will stack up and maybe will speed up this fix

@gurugeek
Copy link

@gurugeek gurugeek commented Nov 1, 2019

rejected today electron 6.0.12 and also with 7.0.0

Your app app links against the following non-public framework(s):

CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

does it work with Electron 5 ?

@gurugeek
Copy link

@gurugeek gurugeek commented Nov 2, 2019

I informed Apple about my app using electron etc. and received this:

"Hello,

Thank you for providing this information.

Regarding 2.5.1, your app uses or references the following non-public APIs. If you do not have access to your binary or unsure how to remove the APIs in question, please contact your service provider for technical supports."

@ForU
Copy link

@ForU ForU commented Nov 3, 2019

3.0.0-beta.5 mas version rejected as well for private apis:

CAContext
CALayerHost
NSURLFileTypeMappings

Just a week ago, we just successfully pass apple's audit using the same mas version. I am wondering does the old electron-v3.0.0-beta.5-mas-x64.zip file got rebuild on the download server side or zip file never modified while Apple changes their private api strategy or both? any hints you guys, coz this is really frustrating and annoying.

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Nov 3, 2019

@alicerunsonfedora
Copy link

@alicerunsonfedora alicerunsonfedora commented Nov 3, 2019

Also am getting the same issue with 6.0.11 when attempting to build hyperspacedev/hyperspace:

Your app includes a version of an SDK from Electron that violates the App Store Review Guidelines. The version of the Electron SDK you are using in your app attempts to hide the use of private APIs. This is a violation Section 2.5.1 of the App Store Review Guidelines.

Found private class usage:
CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

I don't know if this is related, but I think this is also causing a crash on the app as well with an "Operation not permitted" error.

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [3221]

Application Specific Information:
dyld: launch, running initializers
/usr/lib/libSystem.B.dylib
Could not set sandbox profile data: Operation not permitted (1)

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Nov 3, 2019

@nornagon can you help us with this ?
i see you have done similar stuff before

@gurugeek
Copy link

@gurugeek gurugeek commented Nov 3, 2019

@JCBsystem and all. I would be very careful in changing anything just to get through Apple. Their latest message said:

"Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store."

I don't want to see any of my other apps compromised so I hope in an official fix ini the future (if possible at all).

May be one of the moderators/maintainers can escalate this (and relabel since it effects Electron 6 and Electron 7 too, tried with 7.0.1 too).

@buu700
Copy link

@buu700 buu700 commented Feb 19, 2020

Sure, you can download it here.

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Feb 19, 2020

@buu700

you have a "app.asar.unpacked" include in you resource folder.
Theres a electron.app in it thats the one that triggers the API warnings

remove "app.asar.unpacked" an try again
before submitting dubble check you app
open app and navigate to the resource folder see pic.

see picture here
https://imgur.com/a/dYWxq5d

@buu700
Copy link

@buu700 buu700 commented Feb 19, 2020

Thanks @JCBsystem! I'll look into removing that today; sounds like it most likely is a Cordova issue.

buu700 added a commit to buu700/cordova-electron-tmp that referenced this issue Feb 19, 2020
buu700 added a commit to buu700/cordova-electron-tmp that referenced this issue Feb 19, 2020
buu700 added a commit to buu700/app-builder-lib-tmp that referenced this issue Feb 19, 2020
@buu700
Copy link

@buu700 buu700 commented Feb 20, 2020

@JCBsystem @MarshallOfSound @erisu

Good news! My update was just accepted!

It seems that app.asar.unpacked is generated by the Electron build toolchain. I don't know the point at which it's generated, but I ended up having to patch app-builder-lib as a temporary workaround:

Screen Shot 2020-02-19 at 9 42 04 PM

What I'm confused about is how no one else seems to have run into this issue, given that as far as I can tell it's a happy path Electron bug. Is there maybe something that Cordova (or my app) is doing differently that might cause app.asar.unpacked to be unexpectedly created (or unexpectedly populated with the electron module)?

@MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Feb 20, 2020

app.asar.unpacked is completely unrelated to this error, deleting it actually will render parts of your app unusable. Your issue was due to using the wrong darwin/mas build, maybe some other change you made in your build scripts fixed the underlying issue but deleting that unpacked folder will have 0 postive impact and will break most apps

@JCBsystem
Copy link

@JCBsystem JCBsystem commented Feb 20, 2020

but there is 2 Electron apps in his app
one on there normal place
and one in the app.asar.unpacked .

thats not right

@MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Feb 20, 2020

@JCBsystem Sorry if I wasn't clear, I'm saying their issue is unrelated to #20027 (the current issue we are in). Their build system is incorrectly packaging their app either using or accidentally including the non-mas version of Electron and having that information / solution in this thread is poor context for folks reading this thread in the future. I was just making it clear that as their issue is completely different any solution they reference will not solve this issue.

@buu700
Copy link

@buu700 buu700 commented Feb 20, 2020

app.asar.unpacked is completely unrelated to this error, deleting it actually will render parts of your app unusable.

Ah, thanks, that's good to know. Would deleting just app.asar.unpacked/node_modules/electron/dist/Electron.app cause issues?

Your issue was due to using the wrong darwin/mas build

Can you be more specific? You've said this several times and I don't understand what other kind of mas build you mean to suggest I'm using. Does the build config not look right?

maybe some other change you made in your build scripts fixed the underlying issue but deleting that unpacked folder will have 0 postive impact and will break most apps

Not sure what to tell you, there are literally no other changes. It passes with app.asar.unpacked removed and fails otherwise.

@MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Feb 20, 2020

Ah, thanks, that's good to know. Would deleting just app.asar.unpacked/node_modules/electron/dist/Electron.app cause issues?

Probably not if you delete just that app, but you should figure out why it's being put there instead of hacking around it.

Can you be more specific? You've said this several times and I don't understand what other kind of mas build you mean to suggest I'm using. Does the build config not look right?

The build config appears correct but as I said either using or accidentally including the non-mas version of Electron. In this case you were "including" the non-mas version of Electron by accident in that folder, although your build config was targeting mas by default the electron npm package will use the normal darwin build which was what was ending up in the app.asar.unpacked folder.

You should figure out why that electron npm package was included in app.asar.unpacked but that
should be resolved off this issue thread, we've gone off topic here 😄

@buu700
Copy link

@buu700 buu700 commented Feb 20, 2020

Got it, thanks for clarifying that! So some of the node modules in that folder are definitely needed at run-time, but just electron typically wouldn't be?

In that case, I think we've narrowed down what it is that Cordova needs to fix (as well as an improvement for my hacky workaround). I'll go report this in the cordova-electron issue thread.

@briandk
Copy link

@briandk briandk commented Feb 20, 2020

Sorry if this is answered elsewhere, but:

Are Electron versions 7.x, 8.x, and 9.x also problematic users of private APIs? Or have there been updates in the latest versions of Electron to address this issue?

I ask because I'm trying to figure out whether it's more work to undo the breaking API changes I made and revert back to Electron 5.x, or if I can just get a later version of Electron that's also fixed.

@james-criscuolo
Copy link

@james-criscuolo james-criscuolo commented Feb 26, 2020

@briandk 8.0.2 and v9.0.0-beta.3 released yesterday and the release notes mention the fix, so those versions should be good for the app store. I do not believe a v7 release has come with the fix yet, but I assume the next one (so anything > 7.1.13) will have it, as the PR was ported to the v7 branch.

@sofianguy sofianguy added this to Fixed in 8.0.2 in 8.2.x Feb 26, 2020
@sofianguy sofianguy added this to Fixed in 9.0.0-beta.3 in 9-x-y Feb 26, 2020
@sofianguy sofianguy added this to Fixed in 7.1.14 in 7.2.x Mar 6, 2020
@mifi
Copy link
Contributor

@mifi mifi commented Apr 2, 2020

I just released my app losslesscut with electron 8.2.0 and can confirm I did not get any private API issues during review.

@kalachevmax
Copy link

@kalachevmax kalachevmax commented Apr 20, 2020

Guys, do you know, is there a way to use the autoUpdater module in MAS build? Maybe this question is related to the current discussion.

@fsproru
Copy link

@fsproru fsproru commented May 1, 2020

@kalachevmax Mac App Store should handle the updates on its own. Without the Electron app auto-updating itself. That being said, there may be a way to do both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
5.0.x
Unsorted Issues
7.2.x
Fixed in 7.1.14
8.2.x
Fixed in 8.0.2
9-x-y
Fixed in 9.0.0-beta.3
Linked pull requests

Successfully merging a pull request may close this issue.