The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update.<p>This is conceptually no different than calling something in the sun.* packages in Java. For years it was ok, and then ... it wasn't.<p>This, however, is draconian:<p>> 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.<p>"Keep trying to submit, and we might just ban you forever" is insane. Every program of any complexity depends on third party libraries, and many people wouldn't be able to tell what arcane APIs their dependencies (or their dependencies' dependencies) call. "If you continue to have an upstream dependency that violates our terms, we might permaban you" is bullshit.<p>It's also completely unsurprising. Apple has no love nor concern for their developers anymore. It used to be the premier development platform in the world. Now it's ... I don't even know anymore.
> 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<p>Yeah. So? By linking a framework that's using private APIs, this becomes your problem now. And Electron's problem, by extension. Go bug them, not Apple.
Putting it together:<p>This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while.<p>It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.)<p>It’s a little painful for the developers for this to suddenly pop up like this, but it’s better than all Electron apps suddenly crashing one day, which would have happened sooner or later when one of these APIs changed or was dropped.<p>The solution is a Chromium fix to avoid using these APIs, and an associated Electron release to incorporate the new version of Chromium.
As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words:<p><a href="https://imgur.com/a/XnCOHUD" rel="nofollow">https://imgur.com/a/XnCOHUD</a><p>And mind you, GitHub Desktop is taking that much <i>just for showing a mostly empty window!</i> while Fork and Tower are displaying a lot more UI, more controls, trees, custom drawing, more text, and have overall more features (best of all: spell checking for commit messages because all native text fields get it for free.) You can try it on your own machine and compare them.<p>Now yes Electron has made life very easy for some developers and some apps wouldn't even exist if not for Electron, but why, as a user, should I pick an Electron app over native alternatives?
Tracked over at:<p><a href="https://github.com/electron/electron/issues/20027" rel="nofollow">https://github.com/electron/electron/issues/20027</a>
Good. It’s time app developers began to treat Electron like the Goliath of a dependency that it is rather than a cost-free shortcut to launching a cross-platform GUI product.<p>It’s no different than any other library or toolkit you would link against normally. You wouldn’t be hearing these complaints from a “native” app developer that intentionally picked any other library or runtime that (ab)used private frameworks.
There's no drama here.<p>The oldest copy of the current app store guidelines I could find goes back to 2014:<p><a href="http://web.archive.org/web/20140903022336/https://developer.apple.com/app-store/review/guidelines/" rel="nofollow">http://web.archive.org/web/20140903022336/https://developer....</a><p>"2.5 Apps that use non-public APIs will be rejected"<p>However this has been known dating back to 2010, so I'm sure someone can dig up an older version of the agreement that says as much.<p>The fact that Electron is a much easier way to build apps than Swift, Obj-C, etc has nothing to do with the enforcement of these long-standing rules.
On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.
It seems mostly reasonable to me for Apple to reject apps that use those features assuming their own apps have to obey the same rules.<p>Unfortunately if you're popular they seem to let you bend the rules. AFAICT Slack has not been rejected and I believe Slack is electron based.<p>The issue is in Chromium. I have no idea if removing the API usage will be easy or hard but it's been<p><a href="https://github.com/electron/electron/issues/20027" rel="nofollow">https://github.com/electron/electron/issues/20027</a>
I'm curious as to how Slack was/is still able to get updates out despite clearly relying on electron. Setting aside whether one agrees with Apple on this move or not, I would be outraged if they are playing favorites with a select few high-impact electron apps that they don't want off their store due to the associated bad press it would garner them.
At least Apple in this case actually provided a reason and list of APIs it is unhappy with. Armed with this you could either in theory or actuality chase through the maze of your app's dependencies. If this happened to me I'd then have a fighting chance of moving forward.<p>On the other hand, plenty of rejections I've anecdotally encountered are far less obvious and boil down to "we say so". Then you get banned while you still wonder. Google have done this a few times to others I know.<p>Strange times.
Off topic: this is the first time I see Latin Modern Roman used on a web page. Doesn't look that great on low-DPI screens (13" at 2560x1440) but looks good on high-DPI (530 DPI Pixel 4 XL).
While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers.<p>Here on HN we hear constantly of developers dropping out of the Mac app store. If we cobsider the premium (justified or not) of apple laptops, and thus the relatively limited audience they target, we can easily predict a steeper decline in interest to develop for the Mac platform.<p>Having said that, we should also consider that Electron is indirectly owned by Microsoft, and is based on tech by Google. So I don't see much incentive on their part to fix this quickly, and one could even argue that they have some interest in not fixing at all this.
Electron apps can be submitted to the Apple store...
Slack has recently been updated for example.
This seems to only affect some developers, especially electron <= 5
Well to be honest and at the risk of getting down voted I think a fair amount of readers will agree that you shouldn't submit Electron apps not only on the Apple store but also elsewhere, it may be a good way to get a prototype out of the office but that's about it
I was able to submit my app after an upgrade to Electron 6 with no issue whatsoever.<p>Only issue was first with the signature of the app, got fixed with later updates.<p>My app is up in the AppStore with latest Electron 6.
Apple does not like platforms that make it easy to publish lowest common denominator apps for iOS. It makes for garbage apps that look the same on iOS and Android and presents a false equivalency. They know most companies care about iOS customers than Android so this forces companies to spend more making the iOS app better than the Android app.
So there goes one of the primary reasons to use Electron...<p>Cross-platform comparability always promises so much, and falls down in the implementation.
Apple could just not have private APIs. At the very least, they could be impossible to access. If they have to exist at all, they could be in a separate library with permissions that prevent it from being read or mapped into memory.<p>If the APIs didn't exist, then there would be no need for Apple to check and there would be no developers tempted to use anything private.
Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy.<p>As someone else pointed out, not using private APIs would put some applications at a disadvantage against first party software: <a href="https://news.ycombinator.com/item?id=21437673" rel="nofollow">https://news.ycombinator.com/item?id=21437673</a><p>Firefox is often criticized for it's power consumption on the mac because it is not on par with safari. Chrome/electron uses private APIs to reduce power consumption to be more competitive with Apples browser. Apple bans the use of private APIs.<p>Monopoly laws need to be updated.