Instead of raging at Apple, what all these people shipping Electron apps seem to not have realized yet and are about to learn is that 1) the private API use is not in Electron, its in Chromium 2) and Google won't fix it because they 3) do not distribute through the Mac App store and 4) use private APIs to be competitive with Safari on things like power consumption.
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.
The right thing to do for the IOSurface or CALayer API is to file a radar and start a discussion with Apple to make it official. They do listen and this has happened plenty before. Rage tweets or Medium postings probably won’t help much though.
The App Store Developer guidelines state that “going to the press won’t get you anywhere”, but there has been countless examples of this just not being the case.
And I'm sure the managers do a very tasteful ceremony where they read the radars out loud before they print and burn them on the sacred pyre at the end of the month.
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.
I hate to be "that guy", but I can tell you of at least one instance in our case where going public went nowhere. It was more like, case dismissed with prejudice.
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.
I don’t think Apple sees it as in their best interests to support Electron apps that use a private API to which they intend to make breaking changes. Effectively, this hampers their own ability to refactor and rearchitect their own products, all for the benefit of a competitor.
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.
What your parent is suggesting is to make those private APIs public, or at least make a public replacement. It's not calling into question the ban, but instead saying that there's a hole in the public API Apple provide and that they should bring in new public APIs to fix that hole. The last time this came up I asked why those APIs were being used, and was sent two interesting links by users skymt and Humphrey, explaining why both Chrome and Firefox use those private APIs:
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.
I am not completely familiar with these APIs but from what I gather they are primarily intended for low level rendering and to support them means supporting frameworks that bypass all of Apple’s native APIs.
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?
Ultimately Apple wants to make users happy and I suppose therefore buying more Apple stuff.
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.
I am all in favour of exclusive apps. I've been using Macs since the early 90s and I have long sought out the apps which show the most care and attention to detail by developers, conforming to all of the user interface guidelines. These apps feel so much better because they are predictable in a way that cross platform apps aren't.
Cross platform UI toolkits have their own internal "logic" that clashes with the native UI, frustrating user expectations.
* 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.
It isn't a power management API. AFAIK Chrome is bridging in its cross-platform rendering at a late stage into CALayer, and the internal functions override CoreAnimation's handling of redrawing dirty layers.
Similarly, it is using internal functions to map mach ports onto file descriptors because their cross-platform bits do not understand mach ports.
If GP is correct, that’s not the case. They are important APIs for someone who wants to maintain their cross-platform abstraction layer without muddying up their codebase.
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.
“On macOS” is the important part. Safari is by far the most battery friendly browser there and quite possibly has significant market share too. Mozilla has recently managed to reduce their consumption significantly using these APIs: https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
Which Apple may keep private for any number of reasons, none of which have to do with hobbling competitors, nor is it proven that Safari uses these particular APIs to gain a performance advantage for itself in any way whatsoever.
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.”
> 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.*
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...
Electron is a tool for the desktop/laptop market where apple has a smaller share yet. It's more like 10%. It's also a market where people are used to manually installing apps.
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.
> 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.
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
Many of the apps in question are free apps... I tend to have Spotify and VS Code open most of the day. Then again, I replaced Mac on my home desktop with Linux, and getting rid of my rmbp in a few weeks.
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.
"Free" means the app isn't charged for, not revenue generating directly... so jumping through hoops to satisfy Apples whims is not productive. Context matters, and I'm pretty sure you understood the context.
Or perhaps fork Electron to provide a version which uses Safari or even WPE [1]. I’m using WPE in an embedded device since it has better memory and GPU usage than chromium.
I don't see why Google would be inclined to fix anything related to iOS because they seem to be currently deploying a multi-channel strategy to put pressure on Apple to let Chrome be loaded as a native app alternate browser.
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.
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.