Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Why should Chromium be allowed to use private APIs that native developers already knew "should NOT be allowed" especially those coming from iOS where its known using those would simply have your app rejected.

Why should apple apps like Safari be allowed to use private APIs if they're not allowed?

This is blatantly non-competitive.

Also, they sit on these APIs for YEARS with no alternative.



I think every single platform is struggling with this. Even Electron or Chromium itself. They all have internal or private APIs or things that are not ready for prime time or just plain internal details.

Opening up private APIs is a commitment that you will support those. Which is no light decision.

Personally I think it is fine for any platform to have these.

But I do wish that the App Store rules around them were more permissive.

From Apples perspective: look at all the shit they are getting for dropping 64-bit support. This was known for a decade and they still are pictured as the bad guys who don’t support developers. A decade!

So you can imagine what happens when apps relying on private APIs suddenly break.


To be fair, Apple struggles with maintaining their existing APIs. Who cares about the private ones, they probably break or change just as unexpectedly as the public ones.


False equivalency. Changing private APIs without warning is not the same as actively breaking clients.

You know all the talk about Google or Facebook or Comcast both owning the platform and competing on the content layer with self-dealing is anti-competitive monopolistic behavior? Same goes for Microsoft Windows in the 1990s (actually litigated these very issues) and Apple today.


False equivalency. Changing private APIs without warning is not the same as actively breaking clients.

This distinction does not matter in the public sphere. When Apple releases an update — any update — that breaks a popular app, they are blamed for it. By putting their foot down, Apple is putting the onus back on developers to play by their rules.

This situation is essentially the normalization of deviance [1]. If you do not enforce a rule, that rule becomes invalid and unenforceable. Apple does not want to lose control of their platform. If they give away all of their private, low level APIs, then cross platform frameworks like Electron will render their platform a commodity.

[1] http://danluu.com/wat/


Do you mean 32 bit support instead?


Safari doesn't use private APIs. WebKit does.

And WebKit is a fundamental OSX library used for many purposes.


Safari totally uses private APIs, just not for web rendering.


Also every "browser" on iOS has to be based on their webkit. So there is only a single browser implementation. And worse even, they purposely prevent royalty-free (WP9, AV1) codec support (they receive money from HEVC licensing fees), among other things. I remember days where they didn't even support file uploads.


Yeah sure technically correct. But both ship with macOS and both are built by the same trillion dollar company who owns the whole ecosystem.


Electron could in theory use WebKit as well, and the main reason it doesn't is because Google decided to fork WebKit.


I don’t think it actually can because WebKit on macOS has been replaced by WKWebView which has a severely limited API surface that without doubt is way too shallow for Electron.


Because you don’t pay Apple to perform the necessary engineering investment to expose SPI as API. And the people who do pay Apple don’t care about this.


Where is the price sheet for the SPIs Electron is using?


Because they are not a monopoly so those laws don't apply to them.


This has never been a good argument if you look at what happens inside an ecosystem owned by a trillion dollar business.


So in that case the Amazon Fire tablet is a “monopoly” since it’s owned by a 1 trillion dollar company....


You do not have to be a monopoly to be in violation of anti-competitive business practice regulations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: