Hacker News new | past | comments | ask | show | jobs | submit login

It’s just like with private APIs. It’s functionality that they don’t know (¿yet?) whether they want to support it in the future, but they do provide calls that use them indirectly.

There also could be bugs in the hardware that they carefully programmed around.




Why do people act as if “private APIs” (which is somewhat of a contradiction in terms) is nefarious? An API is something that is publicly documented that the vendor promises to support where the behavior won’t change.

Raymond Chen has been blogging for close two decades about all of the hacks that MS had to put into Windows because vendors used undocumented APIs.


There are two ways of dealing with apps using private APIs though: Microsoft indeed goes out of its way to maintain backwards compatibility, sometimes at the expense of sanity, but Apple breaks stuff — this API is private for a reason, you had to reverse engineer how to call it, and you knew your risks when you decided to use it, so if your app breaks, you get to keep both pieces.


Yes, and I suspect this is informed by Apple historically having APIs that were much more open and prone to what we would know call abuse by developers — but was then just cleverly taking advantage of the environment — during the Apple II/early Mac era.


I agree that people tend to get a bit too worked up about it, but I don’t think it’s a contradiction in terms as such - an API is really just any interface where two distinct pieces of software interact in some way. It doesn’t need to be formally described or published or anything like that, and the idea of a private API is pretty common generally.

Where it starts to piss people off though is where those private APIs are used to allow first-party software access to platform features that third-party software doesn’t get. For some applications that’s not so bad, but in the case of a general-purpose operating system platform or similar it’s kind of an anticompetitive move and we should complain when companies do it.


Once you make an API public, no matter how badly designed it is, you have to support it forever.

I would much rather an API be private, let the company dog food it and let their internal employees use it, and then make it public. It also gives them the freedom of completely changing the internal workings.

The extensions API and the Siri integration for third parties are great examples. The Siri intent based API is very usable and reminds of the Amazon Lex based API - the AWS version of the consumer Alexa skills SDK.


>Once you make an API public, no matter how badly designed it is, you have to support it forever

That's simply not true.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: