Hacker News Reader

Comment by roblabla | Hacker News Reader

Well, why the hell is electron/chromium using private APIs? That seems like the real problem here...

I started searching for the private identifiers listed in the blog post and ran across this document describing Chromium's Mac compositor:

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.

IANAL, so I would need someone to explain to me how this differs from Netscape's claims against Microsoft in the 90s.

Because it seems pretty similar.

Also, I wonder if this was code inherited from WebKit, possibly even from Apple engineers.

Netscape’s claims had nothing to do with MS not allowing private APIs. MS forbid OEMs from shipping Netscape of they wanted to license Windows.

The definition of anti trust is not “a company does something I don’t like”.

It's possible electron team isn't even aware chromium is doing that.

Its looks as if the Electron team had the assumption that developers would be unlikely to distribute their Electron Mac apps via the App Store, but instead as a DMG or zip which doesn't require Apple reviewing private APIs.

But they had to know it was happening at some point right?

true and the Notarization of the DMGs works fine with electron. Perhaps this is also why Atom is not on the apple store.

Mozilla recently published a good write up on why they started using these undocumented CALayer API's in Firefox 69. The TLDR is that that these private API's allowed them to get up to 3x better battery usage in Firefox. The article also mentions that Chrome uses these same Core Animation API's.

https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

I just wonder they bump major releases very quickly --now is 7.0.1 and basically a lot of stuff you find, including courses are obsolete and a lot of deprecation -- and yet they didn't take this seriously enough.

This is not an Electron issue as Apple has deprecated these APIs and the issues go back for the past few years worth of Electron releases. We just bumped our Electron version from 4.0.5 to 6.0.12 and we just needed to add a single line of code.

Another interesting question is how Chrome itself gets approved for the Apple web store then, right?

https://apps.apple.com/us/app/google-chrome/id535886823

Presumably the iOS Chrome is not using Apple's private APIs.

Or it's using other private APIs that have they've managed to got through App Store review…

iOS Chrome isn't Chromium. It's wrapped mobile Safari.

I am aware.

Then it's an off-topic discussion which has nothing to do with Chromium's use of private APIs.

Then why suggest that the reason Chrome is approved is because they sneak in private API usage?

Popular applications often get passes for private API usage.

Private APIs they don’t need to use because it’s just a wrapper for Safari, as you’re aware?

Sure. Not all private API needs to go into the web renderer.

Has nothing to do with the article, which is about Electron (and by extension, Chromium)

Right, we veered off of that the moment Chrome on iOS was brought up.

That's the mobile version of chrome, which as required of all browsers on iOS, is using the Safari web renderer under the hood.

Aha, you're right!

Is the desktop version of chrome not in the app store? Maybe not.

That's not Chromium. That's wrapped mobile Safari.

Chromium and Chrome aren't in Apple app stores.

Reply on news.ycombinator.com