There is definitely a need for private APIs that normal apps cannot use - they might have security implications, for instance. The App Store or Settings apps clearly need to be able to do things that other apps cannot do - for instance, any app that had the same privileges as the App Store would be able to install/uninstall other apps.
Further, Apple's position is that the App Store, Settings etc. are akin to natural monopolies - it only ever makes sense to have one of each. The fact that it's not possible to implement a third-party Settings app isn't a problem because nobody should ever need to do this. This is arguable, but it's an easily defensible position for Apple and most iOS users would be happy with this (and those who aren't can jailbreak).
Having private APIs that are available to apps like iBooks, when competitors to iBooks exist, seems a bit shadier and much closer to the example of Microsoft Office using hidden/unpublished Windows APIs in the 90s. iBooks isn't some essential system service, and should be replaceable by a third-party app according to user preference. If Apple are making it even slightly more difficult for a third-party app to replace iBooks then this would appear to be anti-competitive.
IANAL, but I doubt that there is a legal case to answer. However, there does seem to be a moral case to answer. Sure, it's Apple's product and they can do what they like, but we have seen what happens when essential software vendors do what they like, and it's generally not pretty.
There would be a moral case to answer if this class exposed OS functionality that is otherwise unavailable. This is a convenience class that could easily have been copy-pasted between apps. I don't think that there is a moral case to answer.
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
Open-source operating systems seem to have pretty secure applications without depending on secret or undocumented API calls. aptitude and pacman are just normal Linux programs. How come App Store can't be a normal OS X program?
But it does require the user to be vigilant and not give every app all permissions (i.e. the root access aptitude et. co require). Do you really think that is reasonable to expect from every mobile phone user?
First, this isn't about "secure". It's about an API not being ready for prime time, so only used in a controlled manner.
Second, open source projects have private APIs too. And if you use them, you risk breakage of your app, as soon as the API gets changed (which can at any time, under for a minor version update -- after all, it was meant to be private).
Also, there's another, laxer platform called Android. It has around double the market share, but (according to studies) 98% share of all mobile malware.
Even though they're called 'private' they're not really private though. So saying
> open source projects have private APIs too
Is misleading (and unethical).
As far as APIs go, most project have a system to rate features called a stability index. Developers should take note and me aware of it. If something looks like it's going to be broken in the future, don't use it.
I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
Stability: 0 - Deprecated
This feature is known to be problematic, and changes are
planned. Do not rely on it. Use of the feature may cause warnings. Backwards
compatibility should not be expected.
Stability: 1 - Experimental
This feature was introduced recently, and may change
or be removed in future versions. Please try it out and provide feedback.
If it addresses a use-case that is important to you, tell the node core team.
Stability: 2 - Unstable
The API is in the process of settling, but has not yet had
sufficient real-world testing to be considered stable. Backwards-compatibility
will be maintained if reasonable.
Stability: 3 - Stable
The API has proven satisfactory, but cleanup in the underlying
code may cause minor changes. Backwards-compatibility is guaranteed.
Stability: 4 - API Frozen
This API has been tested extensively in production and is
unlikely to ever have to change.
Stability: 5 - Locked
Unless serious bugs are found, this code will not ever
change. Please do not suggest changes in this area; they will be refused.
>Even though they're called 'private' they're not really private though. So saying "open source projects have private APIs too" Is misleading (and unethical)
I call BS. And I'm offended by the "unethical" part.
First, they are totally private. Private is a well defined term in software engineering. It's a specific designation of code as a "you should not bypass this" by the developers.
Some languages have specific keywords for this very purpose (such as, well, the keyword "private"). Others use some tricks like "_" prefix to mark functions for internal use. In any case, you are not supposed to use those and mess with it.
And while you might get away with not obeying that in an open source program (if you consider your app breaking when that API changes upstream "getting away with it"), that's not the case in close source, long term supported platforms, where you don't want to have paid users shouting at you, or having to maintain some half-written, immature version of your API just because some idiot used it before it was ready.
>As far as APIs go, most project have a system to rate features called a stability index.
Private APIs are supplementary to the "stability index" contract. It means "this is subject to change and/or this is meant for internal use only".
There's not a large project that doesn't have private APIs. Including Open Source ones, like Java or Mono or Boost, etc etc.
>I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
Not sure where you got that from. That doesn't even make sense, computing wise. Apps run at the same speed at all times for the same inputs. The only time you might need to update them is when the OS and underlying libraries change incombatibly. Surely not to make them "go faster".
(Whereas a programmer has made the new version faster is beside the point. He might as well made the new version slower and more bloated. The thing is, apps do not get "slower" as time goes by. Perhaps you conflate them with something like disk fragmentation?).
Private API is not the same as API permissions. If there is a private API, it means only "selected" can give best experience to the users. IMHO It's not fair and work against Apple in long term.
Further, Apple's position is that the App Store, Settings etc. are akin to natural monopolies - it only ever makes sense to have one of each. The fact that it's not possible to implement a third-party Settings app isn't a problem because nobody should ever need to do this. This is arguable, but it's an easily defensible position for Apple and most iOS users would be happy with this (and those who aren't can jailbreak).
Having private APIs that are available to apps like iBooks, when competitors to iBooks exist, seems a bit shadier and much closer to the example of Microsoft Office using hidden/unpublished Windows APIs in the 90s. iBooks isn't some essential system service, and should be replaceable by a third-party app according to user preference. If Apple are making it even slightly more difficult for a third-party app to replace iBooks then this would appear to be anti-competitive.
IANAL, but I doubt that there is a legal case to answer. However, there does seem to be a moral case to answer. Sure, it's Apple's product and they can do what they like, but we have seen what happens when essential software vendors do what they like, and it's generally not pretty.