All the external private APIs referenced by iBooks.app version 1.2.1 | Hacker News Reader

All the external private APIs referenced by iBooks.app version 1.2.1

gist.github.com

44 pointsmikecane12 comments

I think it's probably within Apple's rights to use their own private APIs.

People don't seem to get too upset about Facebook or Twitter not providing access to their own internal APIs, yes it's limiting as a developer but them's the breaks. You get to choose between system-level access (Android) or money (iOS).

WebOS doesn't give you access to private APIs either, which I suspect will actually be a really big benefit to their ecosystem.

> I think it's probably within Apple's rights to use their own private APIs.

Sure, but it's a bit annoying that they do use that right for applications distributed through the AppStore (and that their own applications aren't subject to the normal validation process — again within their right).

On the other hand, it may also point to APIs which will become public/documented in the next revision(s) of the SDK.

It is probably worth noting that even though iBooks is distributed via the AppStore it is a free download. This may put it in the same category of system apps as Safari and Mail. That is to say an optional install of an OS component.

No.

This does not matter... compare with Microsoft including a web browser as part of their operating system.

> I think it's probably within Apple's rights to use their own private APIs.

Only if it doesn't provide applications produced by other parts of their company (say, iBooks) an unfair advantage over other e-Readers on the platform (GoodReader, Kindle, etc.). Otherwise, how is this situation any different from Microsoft's exposure of internal APIs for the Office team that Novell was not aware of? I only ask this question in a structural sense, not legally, as IANAL and there's probably a monopoly position test or two that people could argue about for another 200 comments.

http://www.internetnews.com/bus-news/article.php/3435371/Nov...

Apple has no monopoly on digital book readers or digital books. It doesn’t even have a dominant position in the market. That’s what matters.

The idea is that they might use a controlling interest in another market (mobile application sales and distribution; despite the fact that Android is or at least will soon be the dominant hardware platform, its application market sucks) in order to gain an unfair advantage in another market (digital books). The fact that Apple is not already leader in digital books is almost a prerequisite to make this claim.

One difference is that Microsoft may have kept some clumsy APIs undocumented, but fundamentally had no power over distributers with respect to their usage of those same APIs, nor did they ever claim their public development tools were under NDA. Microsoft has a bad rap, but Apple is just downright bad.

One of the benefits of this could be allowing them to drive-test private APIs in order to eventually make (or not, or alternative ones) them public eventually.

Note that this isn't even all their private APIs: Just the private classes.

They also use tons of undocumented, private APIs on public classes -- some of which are very useful.

There's also nothing keeping someone from writing their own versions of these private APIs. Though I do keep the thought that Apple is effectively nerfing the competition in the back of my mind. Very far back.

Reply on news.ycombinator.com