Mac App Store Private API Rejection: Electron 5.0.10

[thomasdao]

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.

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]

I downgrade Electron to 5.0.9 and still get rejection email.

[JustinPierce]

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.

[MarshallOfSound]

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]

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]

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

[MarshallOfSound]

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]

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

[ffflorian]

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

CAContext
CALayerHost
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

[iwodoudou]

Electron 5.0.11

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

CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

[JCBsystem]

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]

electron 3.0.2

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

CAContext
CALayerHost
NSURLFileTypeMappings

[JCBsystem]

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

[JCBsystem]

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

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]

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

[JCBsystem]

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

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]

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

[jacoolee]

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]

Apple change their private api strategy
i have been doing weekly updates for the last month without problems

we need to fix this
sadly i don't have the skills to fix it myself
i have been some digging and looks like these files have private api calls

https://chromium.googlesource.com/chromium/src/+/HEAD/components/remote_cocoa/app_shim/native_widget_mac_nswindow.h
https://chromium.googlesource.com/chromium/src/+/master/net/base/platform_mime_util_mac.mm
https://chromium.googlesource.com/chromium/src.git/+/72.0.3626.80/content/browser/ns_view_bridge_factory_impl.mm
https://chromium.googlesource.com/chromium/src.git/+/62.0.3178.1/content/browser/compositor/gpu_output_surface_mac.mm
https://chromium.googlesource.com/experimental/chromium/src/+/lkgr/ui/base/cocoa/remote_layer_api.h
https://chromium.googlesource.com/experimental/chromium/src/+/lkgr/ui/base/cocoa/remote_layer_api.h

and here's how to do a patch file :)
https://www.youtube.com/watch?v=QtXj9tt-RUE

now we only need to set up the dev environment and
try to remove / comment out the apis

sounds easy ..........

[alicerunsonfedora]

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]

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

[gurugeek]

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

Sure, you can download it here.

[JCBsystem]

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

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

[buu700]

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

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]

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]

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]

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

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]

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]

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]

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]

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

[mifi]

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]

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]

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