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
