Hacker News Reader

Comment by stefan_ | Hacker News Reader

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.

View on HN

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.

Radar goes nowhere, going public does.

Radars don't go nowhere. Each one is read and triaged by the product managers.

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.

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.

No they always stay there.

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.

The largest ash pile does get addressed eventually.

> The App Store Developer guidelines state that “going to the press won’t get you anywhere”

Where does it state this?

https://developer.apple.com/app-store/review/guidelines/

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:

- 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.

I don't think Firefox actually uses those private APIs. Do you have proof of this? That post only mentions CALayer and IOSurface, which are public.

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 wonder if “these private APIs are about to change in the next release” is part of why they decided to stop giving Electron apps a pass on this.

Apple will probably have to.

* 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.

Let’s be clear: they are important APIs that would allow non-Safari (WKWebView based really) browsers be competitive on macOS.

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.

This comment makes no sense to me.

How are Firefox and Chrome not competitive given that Safari isn't the overwhelmingly dominant browser ?

They are now because they both use those APIs. You can read about the impact of this specific one here:

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.

It is ridiculous to say that Chrome/Firefox are only popular now because they use private APIs.

Your own article says that Firefox only recently started using them.

CALayer and IOSurface are not private...

CALayerHost and CAContext were listed in the offending apis in this rejection of an electron app https://github.com/electron/electron/issues/20027

Firefox does not use CALayerHost. It uses the public IOSurface and CALayer.contents APIs.

https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-fr...

Are those mentioned in the Mozilla post?

“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.

Even so, there is a halo-effect - and customers’ expectations to meet.

This isn’t about the mobile market...

The apps mentioned (Spotify, Slack) are also available on the mobile market.

Since they need to have them there, and don't use Electron there already, they can have them in macOS without it trivially.

Mobile market? Electron is a framework for desktop apps...

> 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

They'll just stop distributing versions through the Mac App store and the Mac App store will become even more irrelevant.

They're putting their apps out for the money, not for some principle.

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...

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.

>Many of the apps in question are free apps...

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.

Electron doesn’t run on iPhone?

it does with cordova

Nope, Electron is a platform that Cordova runs on.

App Store will always be relevant since it's such a popular distribution channel.

And one app not being on there isn't going to change that.

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.

1: https://webkit.org/wpe/

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.

This is about macOS not iOS. Electron and Chromium on iOS is not a thing.

> 4) use private APIs to be competitive with Safari on things like power consumption.

Uh, if that's the case then I think they're barking up the wrong tree. Just given. How that's going for them.

Makes me think this is a move by Google to make Android more appealing.

Reply on news.ycombinator.com