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.
I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance.
That was mostly made up and even if such APIs existed, any program could have used it.
Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs.
Apple seems intent on becoming more evil than Microsoft ever was.
At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action.
I'm just hoping it'll happen sooner rather than later.
The prehistory is that developers for the Apple ][ had access to third party documentation, and made extensive use of unofficial system variables and entry points. The result was that it became impossible for Apple to update their own system without breaking popular apps and getting blamed for doing so. It turned Apple ][ technology into a dead end.
The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.
IBM had a different approach, which was to make things more open like the Apple ][, and they paid the price for it. For instance, a lot of the weird limitations of the IBM PC were caused by developers bit-banging hardware registers and video memory rather than going through "official" BIOS calls that were less efficient.
I don't personally know the right answer, but this is just the history as I recall it. At the time I preferred the IBM approach, because I could do some friendly bit banging and get stuff done, but my programs were mostly for a severely limited audience and lifespan. Today I try to do things in a way that insulates me from knowing anything about the platform that I'm using.
I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap.
Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows.
Microsoft was pretty evil.
Apple, or Microsoft for that matter, would do the same thing here, because the locked down platform is more valuable/profitable then an open platform.
Developed for Android - at least you can have your app sideloaded if the platform owner decided to remote you.
Or better, make your app a progressive web app. Don't use hardware api not available to the browser and you cannot be removed!
In a completely fair world a substantial number of executives would probably be in jail.
Giving up software freedom for "ease of use" seemed like a fine deal at first but then Apple started making decisions that don't quite align with what neither users not developers want. Apple has already started taking advantage of their position as the gatekeeper of the platform.
The fact is that all of MS’s Office competitors early on wrote horrible GUI apps whether it be fir Windows or the Mac.
Apple is within their rights here, but please, let's not pretend this is about user experience.
It's about the Apple machine doing what it wants, and rolling over who it wants, because it can.
That would explain why Apple developer relations (read: humans) had previously backpedalled after the same rejection in the past:
https://github.com/electron/electron/issues/20027
Most likely these rejections were not intentionally resumed, but because the machine that is app stores these days is completely non-deterministic, this could still be a big problem.
This time the wrong developer could reach out to the wrong channel and trip some sort of trap that turns this into a "known issue: won't fix + always send automated reply", instead of someone with the right connections getting to the right person and having them go and flip a switch that fixes everything with their pinky finger.
By Apple, or the Electron developers?
If you can't avoid Apple's stores then make damn sure you fall in line as they effectively own you.
I mean, did Electron or Google just refuse to fix this? Are these private APIs things that actually get exercised in the apps being threatened?
It's not so much about culpability or Apple's right to control their app deployment environment, it's that the response seems really disproportionate to the offense and pretty badly misdirected.
A more conspiratorially minded poster might wonder if the real goal here was to dissuade developers from using cross-platform frameworks...
Thank you Apple for keeping things clean!!
And mind you, GitHub Desktop is taking that much just for showing a mostly empty window! 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.
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?
I used Electron apps on Linux and typically memory usage doesn't get below 250-500 Mb.
Here is an example for Skype: 220 Mb of swap + 388 Mb of PSS (Proportional set size).
Yikes.
Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week.
I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think it's better.
Where else would users complain about undesirable developer trends if not on a developers' community?
Say a somewhat below-average user has 6GB of memory (I'm being generous here; plenty don't have more than 4GB). Today is a worse-than-usual day, and 4GB are taken by everything that isn't Electron because 40 tabs are open for a research paper due tomorrow. That leaves three gigs to spare. Now the user starts up some Electron apps.
- Music player? +400mb
- Note-taking? +300mb
- Messaging? +500mb (thanks, Slack!)
- News? +300mb
- Editor/IDE? +500mb
That's it. No more space. And that's before we even begin talking about what we're putting that dual-core CPU through. Battery life is a joke at this point.
A comparison: My OS, window manager, mail client, password manager, taskbar, music player (mpd+ncmpp+clerk.pl), file manager, system monitor, RSS reader, podcast player, IRC client, and editor/IDE (neovim+language servers with diagnostics, gotos, floating documentation, and refactoring all running) barely use over 1GB of memory, combined. Let that sink in. Essentially, a single electron app using 500mb of memory would increase my memory usage by 40%.
People shouldn't have to throw away/upgrade their computers every four years. I'm still rocking a 2013 HP Elitebook G1 with a Haswell i5 as my secondary machine. It runs just as well as my desktop for anything except heavy websites with JS enabled, compiling, and graphics-intensive work. I plan to either continue using it for another few years or donate it and switch to a more lightweight \$199 Pinebook Pro. Using less powerful hardware forces me to empathize with users who are using tech from the past rather than the future, because that's my job. I build tools for people besides myself to use.
If you must use the web, consider making your "app" start a local web server and launching the users' preferred browser for a more lightweight solution.
I'd pick the native version every time, but there is no native VSCode, Atom, Slack, or Whatsapp.
I use Sublime because it's native and I don't use too many plugins but a lot of people prefer VSCode.
I cannot fathom the indignity required to care about that difference.
Your failure to empathize seems like an odd thing to brag about. Even if you have plenty of memory available, you should be capable of empathizing with people who are short on it.
This is conceptually no different than calling something in the sun.* packages in Java. For years it was ok, and then ... it wasn't.
This, however, is draconian:
> 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.
"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.
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’m not sure why the process was so complicated either. A couple of steps involved Apple calling me, and my superior, to verify that we were real. Except they didn’t actually verify that, because it was a simple conversation and I could have just lied with a buddy of mine... Even adding developers from our suppliers was a tedious process, and of course Apple has no way of integrating with our IDM or local security setups.
They sure are lucky to have a monopoly on iOS devices.
This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.
It's not like this app developer is intentionally using private APIs. "Resubmitting the same thing and hoping that it doesn't get caught" seems to be a strawman.
"use"
If this was "don't conceal or we'll ban you for life", it would be somewhat understandable.
But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.
I was under the impression that if you're being annoying and keep trying to submit a build with private API, making App Store Review's life hard, they're going to ban you. In general, you should be reviewing your dependencies yourself to make sure it's doing things that you approve of; if you can't do that after Apple has warned you that it's doing something that's not allowed I don't really have much sympathy for you.
There is also no apparent way to scan your own app to make sure that you are not in violation of this issue. So you're in a position where the only way to see if you are in compliance is to submit to Apple, but that may result in your account being banned.
Because Apple knows it doesn't need to attract developers to iOS. They will come no matter what because that's where the mobile market is.
On macOS it's different. There are very few macOS exclusive developers so most of the popular apps are either cross platform (Office, Photoshop, Sublime Text, Chrome, Firefox, Maya, Cubase, Cinema4D, Resolve, etc) or are from Apple. In both cases the Apple dev experience is irrelevant. There are plenty of boutique devs making small products exclusively for macOS (eg: Panic, Bjango, Bohemian) but these are a drop in the ocean. Apple knows this which is why it's making Catalyst to attract iOS devs to macOS. AFAIK the only big developer making macOS exclusive products is Apple itself.
Wait a second. When was this exactly? Are you talking about the Apple II era?
When has Apple ever been developer friendly?
Their ecosystem always had more money for app developers, but I can't think of any point in time when developers weren't shouting to anyone who will listen about Apple's rules.
Yes electron comes with some overhead. But what you get from paying that price are products that otherwise likely wouldn't exist. Some of these are bad indeed, but some of them are also really good and provide real value.
I think that describes the attitude of electron developers toward their users, you're putting your time and convenience over them.
and then the app is never written
Don't use anything that provides portability like C or Objective-C, that's not really "native" to the CPU architecture.
.. I know that sounds silly, but you're advocating for that one layer up. It's a very good analogy I think.
People use electron in order to "compile to" native apps for linux and windows and mac without having to write the app 3 times.
https://www.chromium.org/developers/design-documents/chromiu...
Technical details aside, it describes two methods of performing delegated rendering on Mac. One uses public APIs and causes a "reduction in performance and increase in GPU power consumption." The other uses the reverse-engineered CAContext API.
Because it seems pretty similar.
Also, I wonder if this was code inherited from WebKit, possibly even from Apple engineers.
https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
Chromium and Chrome aren't in Apple app stores.
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.
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.)
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.
The solution is a Chromium fix to avoid using these APIs, and an associated Electron release to incorporate the new version of Chromium.
I wonder if it has been that way in Chromium since Blink was WebKit and maintained largely by Apple with priority on performance on Apple platforms.
Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.
So, feel free to use Electron, just understand that your so easy to develop desktop app now hinges on the ability of a few unpaid developers (that's probably not you, or the "full-stack" people at Slack) to continuously keep track with the Chromium source and maintain their no doubt massive patches to its code to remove use of these private APIs.
Indeed, and the article's title is confusingly wrong, as "Apple Store" refers to Apple's retail and online store that sells hardware.
However, this is not really about unsigned binaries. These APIs are from OSX itself. This is about access to private APIs. These have no contract and can be changed at any time, as they were not intended for public consumption.
But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is inviting antitrust scrutiny or new laws.
Apple had better make sure it is squeaky clean on this.
In some cases, private APIs are used as implementation details of public APIs. For example, the symbol "NSNextStepFrame" sounds like it might be part of the implementation of NSWindow. In some other cases, Apple has made early versions of some APIs private before later releasing them publicly -- for example, the Catalyst APIs (UIKit on macOS) was a private API for a while before being publicly released, allowing Apple to test the APIs (and potentially make backwards-incompatible changes) before external developers started using it.
It's only anticompetitive if they selectively apply those rules.
The oldest copy of the current app store guidelines I could find goes back to 2014:
http://web.archive.org/web/20140903022336/https://developer....
"2.5 Apps that use non-public APIs will be rejected"
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.
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.
Is this another case where you can break the rules but only if you're rich enough?
1) wxWidgets
2) QT
3) Delphi with Firemonkey
4) Lazarus
Whole bunch of other which you are welcome to Google and explore
Also it depends on your type of application but I am seriously considering using 3D rendering library as a basis for multiplatform GUI. This one does not look too native but it looks like it may be the leanest, fastest option. This would require some groundwork first.
WebKit on macOS doesn’t have the limitations that its iOS cousin does… cutting edge API support is a bit spotty but if one looks at how old the versions of Electron being shipped are, that clearly isn’t a problem. More web wrappers should opt for the locally available engine instead of bringing their own.
Electron always uses Chrome whether it is on MacOS or Windows. There was a node-webkit project before Electron, I don't know its status.
That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.
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.
If you have a public function “A” that is implement using private methods B,C,D. The implementor is free to change B, C, D or completely get rid of them to implement A. This is software engineering 101. Apple was able to make multiple cpu transitions doing this. Back in the PPC days, non native apps could run at near native speeds calling public APIs that were implemented by changing the private interface.
Most obviously, they can go in the kernel. They can go in a separate process, using the Mach messaging that Apple so loves. There are other designs, as seen in Multics and VMS, with semi-privileged libraries. One could implement semi-privileged libraries on ARM by switching to a different page table when an attempt is made to run the library code.
For secured forms of code like WebAssembly and the JVM, simply validate at load time that there will not be calls to non-whitelisted library functions.
As someone else pointed out, not using private APIs would put some applications at a disadvantage against first party software: https://news.ycombinator.com/item?id=21437673
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.
Monopoly laws need to be updated.
An API by definition is the public interface that a platform promises developers will not change without notice. The vendor has every right to change a private API. Once you start letting third party developers use private APIs either you are stuck with them forever or when you change it, users will blame you not the developer when applications break.
I suggest working on your comprehension skills.
Apple breaks apps CONSTANTLY that use only public APIs, and the users DO NOT BLAME APPLE.
Do you even work in the iOS ecosystem? Because everyone who does knows this. Users don't blame Apple when things break, they blame 3rd party developers.
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.
The issue is in Chromium. I have no idea if removing the API usage will be easy or hard but it's been
I personally prefer using MAS for such apps, since that means updates are installed automatically overnight without having to deal with other people’s annoying auto-updating software. Wish Chrome itself was in the MAS, so I didn’t have to deal with Google Autoupdater.
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.
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.
Strange times.
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.
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.
Only issue was first with the signature of the app, got fixed with later updates.
My app is up in the AppStore with latest Electron 6.
Cross-platform comparability always promises so much, and falls down in the implementation.
