Apps Built With Electron 6 and 7 Are Currently Being Rejected From the Mac App Store ⇥ david.dev
“David Dev” (sic):
Allright, as a follow up to the previous chapter in this odyssey I can now state that, apparently, you cannot submit an electron 6 or 7 app to the apple store:
The first refusal from apple states:
Your app app links against the following non-public framework(s):
CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings
I am not the only one having this issue and I did write back to Apple trying to explain that I am using Electron and I can’t really change any of these public-framework usage (I assume is something from Chromium) […]
I’m seeing a lot of anger directed at Apple over this, including accusations of monopoly practices and allegations that this is some sort of plot to neuter computing except for the ways in which Apple says you can use your Mac. This is ridiculous. These apps are being rejected from the Mac App Store, but can be distributed elsewhere; the Mac is not a closed platform. I get why this is frustrating: the lack of communication by Apple when changes are made to the App Review process may come as a surprise, and Electron is a popular framework upon which entire apps rest, so changing it would require a lot of work.
If anything, though, the main culprit here is whichever part of Electron — either Electron itself, or Chromium, upon which it is based — decided to use private APIs in the app. Apple has been wildly inconsistent with many aspects of its App Stores, but on private APIs the company has stood firm: they may not be used. It would have been useful for Apple to announce this change if it knew the revised App Review process would prevent Electron apps from being accepted into the Mac App Store, but it is by no means a death sentence for these apps, nor is it their responsibility to ensure that every intermediate app layer made by a third-party is compliant.
Update: Michael Tsai:
So there are a multiple problems here:
It’s (apparently) impossible for Chromium to get competitive performance and battery life without using private API, which Safari freely uses.
Apple probably has good reasons for keeping these APIs private.
Private API has always been banned, but Apple has been accepting these apps for years and then abruptly stopped without any notice.
Apps using Electron probably didn’t know that they were even using private API. Neither Xcode nor Application Loader reports this, and App Review was accepting the apps.
The rule is not being enforced equally.
The first point is relevant, but does not make a difference in whether the apps should be approved, hence Tsai’s second point. The third and fifth points are yet another entry in Apple’s biggest problem with the App Review process, which is its inconsistency and opacity.
But the fourth argument here is critical: private APIs are risky to use in any case, but it’s absurd to use them in a software platform. In this case, it’s layers of dependencies failing developers: apps are built on top of Electron, which is built on Chromium, which uses private APIs to help its atrocious battery and CPU consumption. It isn’t as though Slack — to use a notorious example — actually needs a 200 MB app to run its glorified IRC client.