If Electron fixes their usage of private APIs then this whole storm blows over.
Now if Apple introduces a rule that specifically says “non-AppKit apps are not welcome on the store” then let’s panic. But that is not happening here.
(I’ll be the first in line to admit that private APIs and App Store rules are mostly limiting creativity and competition )
Your app now hinges on the ability of developers-that-are-not-you that you are not paying to maintain a private API free fork of Chromium and in the process not break such essential things like display composition where these APIs are used.
* I understand the prviate API was about reducing power-consumption.
* Apple sells itself on superior battery-life compared to Windows laptops.
* Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in.
* Despite the fact most of those apps are nominally free (Slack, Skype, etc), if they weren't available in the Mac App Store it would mean users would stop seeing the Mac App Store as the place to go for Mac software - thus damaging the brand.
In short: if Apple doesn't document this power-management API and make it public then significantly fewer _important_ apps will be available in their Store which is bad for Apple's current long-term vision. If these apps do modify themseles to not use the battery-life API then they'll reduce the computer's battery life which then makes Apple look bad.
Similarly, it is using internal functions to map mach ports onto file descriptors because their cross-platform bits do not understand mach ports.
How are Firefox and Chrome not competitive given that Safari isn't the overwhelmingly dominant browser ?
https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
Before using those private APIs, with no other options to reach the same performance as Safari, both Chrome and Firefox were in a completely different league.
https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-fr...
Your own article says that Firefox only recently started using them.
So you’re basically just talking out your ass, saying that Apple should open up APIs that have always been private for the sole purpose of helping a competitor who knowingly adopted them in violation of platform rules.
“Yes, officer, I broke the law. But I think, now that I’ve broken it, you should just abolish the particular laws that I broke because some people think I’m a big deal.”
Spotify and co will care more of getting into that 30% of the mobile market (and the more lucrative 30% at that) by doing whatever they can, than Apple would worry about them leaving because no Electron is allowed...
Since they need to have them there, and don't use Electron there already, they can have them in macOS without it trivially.
The worst case scenario is that apple loses some revenue and major players avoid the mac app store for desktop apps.
Apple who gets most of their money from mobile will not care. App developers will lose some convenience but negligible money and they wont care.
I personally don’t care. In fact I grow tired of the throw everything in a webview cause we’re lazy mentality. Build a proper app that looks like it’s a mac app. Also I grow tired of the crap performance these “apps” have. I say remove the lot of them and force people to build a proper app. Electron is Flash 2.0
Radar goes nowhere, going public does.
I don't know about radar. Never tried it.
Given my own experiences in the past, I would doubt that radar goes much of anywhere either. Apple just doesn't seem like they move unless and until they want to. But again, I can't say for sure about radar, as I said, I've never gone that route.
By far the best route to go is to be in a position where Apple was about to make the change you wanted anyway. But you probably have to get pretty lucky for that to happen.
Where does it state this?
The question is whether there is merit from Apple's perspective in making these APIs public.
Because often we find out at WWDC a year later why they didn't make it public and it's because of some foundational rearchitecture.
It's just that the world doesn't revolve around one particular issue. If your particular issue doesn't have lots of duplicates (i.e. common) or it isn't strategically important to Apple then it just doesn't get prioritised.
Not only that, but if Apple didn’t ban the use of private APIs then they would be blamed whenever one of their updates broke all these popular Electron apps.
In a sense it’s like letting squatters onto your land. If you ignore them long enough then at some point society decides they have the right to be there, and then you become the bad guy for deciding to enforce your own property rights.
- Chrome explanation: https://www.chromium.org/developers/design-documents/chromiu...
- Firefox explanation: https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
Windows has public APIs for doing those things. It's pretty clear that there's a need for them. Apple should absolutely design a stable solution for those, since there's a clear demand.
Apple does not want to do this for business reasons. Microsoft does, but they have a different business model than Apple. Apple is in the business of selling their own hardware which means they want exclusive apps. If everything is cross platform then Macs become an overpriced commodity. Why even develop macOS at that point?
If you think the only way to achieve that is inevitable pursuit of "exclusive apps" then fine. But I would say, a user who gets the apps they want and isn't artificially constrained in that goal is a happy user, who will be satisfied with Apple letting them achieve that.
Cross platform UI toolkits have their own internal "logic" that clashes with the native UI, frustrating user expectations.
And one app not being on there isn't going to change that.
If they need to drop Electron to get into the more lucrative 30% of the mobile market, iOS users, they'll do it as fast as they can...
There's no such thing as a "free" app from a for-profit company -- except some neglected side project.
Spotify is only free because they want to hook people and then sell premium subscriptions to those that are up for it, others are monetized by ads, private info (eyeballs), etc.
From Google's perspective, Chromium-based apps being booted from the iOS App Store is probably a fantastic thing if it leads to articles like the one linked up top here.
"Apple makes it hard to use the web" is a much better message for Google than "Apple doesn't let users install Chrome so we can't collect as much data from iOS users as we do everywhere else." Even though the latter is the truth behind their push to get Chrome natively onto iOS.
Uh, if that's the case then I think they're barking up the wrong tree. Just given. How that's going for them.
... my third and fourth cents.
I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it.
You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow.
The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it.
Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code.
Edit: Added MacOS or iOS for clarification since my point is the same for both.