
How Apple Cheats - libovness
http://marksands.github.io/2014/05/27/how-apple-cheats.html
======
dilap
It's totally reasonable for Apple to use APIs internally that it's not ready
to make public -- making an API public is a serious decision with lots of
downsides! You've got to support the API forever, and future design directions
are constrained.

To expect Apple to make all code it uses internally available publicly is
silly.

(If you want some great examples of the extreme amount of work it can be to
support legacy APIs, and why it's really important to prevent devs from using
private APIs, check out Raymond Chen's blog.)

~~~
jacquesm
When Microsoft did the same thing in Windows it was grounds for anti-trust
lawsuits to be brought against them:

[http://www.pcpro.co.uk/news/101947/microsoft-used-
undocument...](http://www.pcpro.co.uk/news/101947/microsoft-used-undocumented-
windows-apis-iowa-testimony)

The idea here is that if you are supplying both the operating system _and_ the
applications that your applications should not benefit from being made by the
same company as the OS, in other words, that it should be a level playing
ground without you having an unfair advantage.

~~~
dilap
Yeah, in a monopoly situation I see where you're coming from, but Apple has
very healthy competition from Android. It's not currently in Apple's interest
to hobble 3rd party apps; quite the opposite.

~~~
sheetjs
On a side note: I wonder why they hard coded the 4 names rather than grant
access to all apps with bundle identifiers starting with "com.apple."

~~~
fleitz
Because it's technically possible to create an app with a com.apple bundleID.

------
matthewmacleod
Like others, I'm fairly convinced that this is simply not enabled because
Apple haven't done the necessary amount of work to ensure that the
UIPopoverController on an iPhone is stable, API-compliant, and well-tested.

Specific use-cases under their control can be extensively tested, and it may
be the case that e.g. iBooks only uses a subset of the functionality.

More to the point, there's nothing to be gained from this example.
UIPopoverController is a relatively boring UI element which it's not too
complex to implement by hand, and there are a bunch of open replacements. It
was also only relatively recently (Lion?) introduced into MacOS. If they are
trying to find a competitive advantage here, they're not doing a good job of
it…

~~~
craigching
> Apple haven't done the necessary amount of work to ensure that the
> UIPopoverController on an iPhone is stable, API-compliant, and well-tested.

And, to add to what you're saying, maybe this is how they're testing it, by
using it in their own widely used apps.

I agree with the "nothing to see here" crowd, if I wanted the feature I'd
develop it myself in this case. Doesn't seem like it would be that bad.
Microsoft has always had their own controls too that they never exposed to the
world leaving it up to applications developers to replicate if they wanted the
functionality.

------
martinnormark
This reminds me of how Microsoft added specific code to Windows 95 to ensure
SimCity would run.

This is from Joel Spolsky's Strategy Letter II: Chicken and Egg Problems
[http://www.joelonsoftware.com/articles/fog0000000054.html](http://www.joelonsoftware.com/articles/fog0000000054.html)

So Windows 3.x on Intel 80386s was the first version that could run multiple
DOS programs respectably. (Technically, Windows 386 could too, but 80386s were
rare and expensive until about the time that Windows 3.0 came out.) Windows
3.0 was the first version that could actually do a reasonable job running all
your old software.

Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit
software perfectly. Microsoft obsessed about this, spending a big chunk of
change testing every old program they could find with Windows 95. Jon Ross,
who wrote the original version of SimCity for Windows 3.x, told me that he
accidentally left a bug in SimCity where he read memory that he had just
freed. Yep. It worked fine on Windows 3.x, because the memory never went
anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity
wasn't working in testing. Microsoft tracked down the bug and added specific
code to Windows 95 that looks for SimCity. If it finds SimCity running, it
runs the memory allocator in a special mode that doesn't free memory right
away. That's the kind of obsession with backward compatibility that made
people willing to upgrade to Windows 95.

~~~
scrabble
My understanding is that Raymond Chen (
[http://blogs.msdn.com/b/oldnewthing/](http://blogs.msdn.com/b/oldnewthing/) )
was a huge part of ensuring that everything was backwards compatible. If you
like that kind of thing, he's got a book: [http://www.amazon.com/The-Old-New-
Thing-Development/dp/03214...](http://www.amazon.com/The-Old-New-Thing-
Development/dp/0321440307)

~~~
martinnormark
Amazing. Thanks, I didn't know of him specifically but I do remember seeing
his book somewhere.

------
gioele
Let's contrast with Android's take on a private API: private Content
Providers.

> The problem is, there are more Content Providers in the system than are
> documented in that package, and while you can use them, you probably
> shouldn’t. They’re there because some of the Google-provided apps use them
> internally to access their own data resources. Because Android is an open-
> source project, it’s easy enough to find them just by running shell commands
> like find and grep over the source tree.

> [...]

> Back to Content Providers. For example, there’s one inside the built-in
> Messaging (A.K.A. texting or SMS) app that it uses to display and search
> your history. Just because it’s there doesn’t mean you should use it. The
> Android team isn’t promising that it’ll be the same in the next release or
> even that it’ll be there in the next release.

> So, go ahead and look at the undocumented Content Providers; the code is
> full of good ideas to learn from. But don’t use them. And if you do, when
> bad things happen you’re pretty well on your own.

[http://android-developers.blogspot.de/2010/05/be-careful-
wit...](http://android-developers.blogspot.de/2010/05/be-careful-with-content-
providers.html) [http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-
AP...](http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-APIs)

The main point here is that you are on the same level of Google: if you want
you can use those private APIs, but be ready to do a lot of work to keep your
application working fine.

~~~
collyw
Why is it whenever there is a criticism of Apple, we always have to turn it
into an Apple vs Windows, or Apple vs Android type competition? Just because
One party is behaving like a twat, doesn't mean there is justification for the
other to do the same.

~~~
abhigupta
I find that such relative comparison put things in perspective.

~~~
vanderZwan
My problem with it is that it tends to put things in the _wrong_ perspective.
Should we judge things by comparing them to other crappy products, or by a
reasonable expectation of what things should be like independent of that? If
it's the latter, then what's the point of comparing it with the former? It
just gives a false sense of "it's not so bad after all."

~~~
abhigupta
I see both approaches as merely tools to achieve what you want. I don't see
any of those approaches as good or bad. If one wants to make only Apple's
decision and practice look bad, then yes they could do absolute comparison.
Alternatively, you could do a relative comparison to see that this is a
standard practice followed by all major platforms providers, that compete with
their customers.

~~~
vanderZwan
Neither is good nor bad except one is supposedly singling out Apple to make it
look bad? Besides, I was talking about holding ALL involved to the absolute
standard, compared to a purely relative comparison.

------
chrisdevereux
This is a fairly straightforward, boring UI class which you could easily
implement yourself, or use one of the many open source replacements[1].
Whatever the reasons for making this API private on the iPhone, I seriously
doubt that it's because they are trying to give their own apps an unfair
advantage.

If that was their game here, I can think of many other parts of the iOS
frameworks that would be kept private before UIPopoverController.

[1]:
[https://www.cocoacontrols.com/search?utf8=✓&q=popover](https://www.cocoacontrols.com/search?utf8=✓&q=popover)

~~~
craigching
> I seriously doubt that it's because they are trying to give their own apps
> an unfair advantage.

Yes, that hits the nail on the head. Great point.

------
callumjones
Isn't the argument that Apple makes use of private APIs as a beta test? That
is, Apple will first introduce these private API restrictions, build apps
around them and release the API as public once they are confident on its
reliability. My understanding this is the approach with XPC and TouchID.

Maybe Apple aren't confident with UIPopovers on iPhone and are awaiting its
maturity until they let it loose. I highly doubt holding back a popover would
be malice on Apple's part.

EDIT: Imagine if Apple released APIs as soon as they used them, we'd see more
blog posts complaining about the reliability of an API they were promised.

~~~
andyjohnson0
The Apple apps that use these private APIs are publicly available. They're not
beta versions. If the APIs are unstable then why are Apple releasing apps that
use them?

~~~
callumjones
Yep I know, you could consider these production apps as beta tests of the API.

If they mess up the API calls, they can sidetrack the review process and
deliver a swift update.

------
rjknight
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.

~~~
cookiecaper
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?

~~~
coldtea
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.

~~~
danford
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.

~~~
coldtea
> _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?).

------
zackboe
Google does a similar thing with Chrome and the Hangouts extension[0].

They have two APIs that are available behind a flag or in a dev branch.
Panels[1], the always-on-top type windows Hangouts uses, and the notification
area icon[2].

Google hardcodes Hangout's extension id in Chromium to allow it to use these
features before they're available to the public.[3]

[0][https://chrome.google.com/webstore/detail/hangouts/nckgahada...](https://chrome.google.com/webstore/detail/hangouts/nckgahadagoaajjgafhacjanaoiihapd?hl=en)

[1] [http://www.chromium.org/developers/design-
documents/extensio...](http://www.chromium.org/developers/design-
documents/extensions/proposed-changes/apis-under-development/panels)

[2]
[https://code.google.com/p/chromium/issues/detail?id=142450](https://code.google.com/p/chromium/issues/detail?id=142450)

[3]
[https://code.google.com/p/chromium/codesearch#chromium/src/c...](https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/panels/panel_manager.cc&q=file:panel_manager.cc%20nckgahadagoaajjgafhacjanaoiihapd&sq=package:chromium&type=cs&l=128)

------
poolpool
Too many people here are way too furious at anything apple/closed source to
discuss anything.

1) you still own your phone. Don't be silly. Jailbreak and builds apps to your
hearts content. Vendors can choose who and what they allow in their store.
Physical or otherwise.

2) apple makes virtually all the profits on consumer hardware, but has Tiny
market share. Really. It's no an abuse of a monopoly if 20 percent of people
can't use a private API on their telephone.

3)equating access to private APIs in a private store with morality is a truly
warped view of the world and a disservice to actual issues with morality
society faces.

~~~
danford
>equating access to private APIs in a private store with morality

Well, I think there is a lot more to it than this. I think people are just
using this as one example. Personally I don't think it's a very good example,
but you won't see a thread on HN about Apple purposely breaking X so Y is more
difficult (for example the android imessage fiasco), or the fact that many
'innovations' by Apple, like thunderbolt or retina, are really just 'one-
upping' the competition and attempting to lock the consumer in to something
that's no more than a gimmick.

Sure thunderbolt is fast, but it's not something that any tech company
couldn't design, it's just something to break compatibility between systems.
Microsoft and many other tech companies are guilty of the same thing. Maybe
google could make lighteningBolt on their chromebooks that goes just a little
faster then thunderbolt, and then MS can make FTLBOLT on the surface that goes
just a little faster than lighteningBolt, and then we can have no universal
standards.

Next every company can come up with their own formats for their devices to
make cross-compatibility impossible!

Like I said, Apple isn't the only company that's guilty of this, but they
certainly seem to be the worst offender, especially when it comes to the
consumer. If you're an investor it's great though, because they do everything
they can to hook the consumer and make sure they can't go back.

Personally I'm not a fan of the Apple ecosystem. I had a lot of issues with
sound going in and out on my MBP and bad multi-monitor support and I kind of
felt mislead my the Apple community because I foolishly believed that OS X
would have no issues out of the box.

I think the fanbase needs to be more open and accepting to criticism of the
brand, because acting like Apple is some kind of flawless tech company does
more harm than good.

~~~
csixty4
> many 'innovations' by Apple, like thunderbolt or retina, are really just
> 'one-upping' the competition and attempting to lock the consumer in to
> something that's no more than a gimmick. Sure thunderbolt is fast, but it's
> not something that any tech company couldn't design

Definitely. For example, Thunderbolt was designed by Intel. Apple had an
exclusive license for a while, but it's available on Windows laptops[1] now,
albeit sometimes with their own proprietary connector[2].

> Personally I'm not a fan of the Apple ecosystem

It shows.

[1][http://en.wikipedia.org/wiki/List_of_Thunderbolt-
compatible_...](http://en.wikipedia.org/wiki/List_of_Thunderbolt-
compatible_devices)

[2][http://www.pcworld.idg.com.au/article/391755/sony_adopts_int...](http://www.pcworld.idg.com.au/article/391755/sony_adopts_intel_light_peak_technology_new_laptop)

------
nateabele
I think it's a little silly to make a vast conspiracy about this.

When you put yourself in the shoes of the people on the product teams building
the apps and maintaining the APIs, it's easy to see this for what it's much
more likely to be: a hack that was implemented so that someone could leave the
office at a reasonable hour.

------
mitosis
Those of us old enough to remember the early days of the Macintosh know that
this is nothing new. Apple programs used undocumented calls to QuickDraw and
did all kinds of yucky stuff with the upper 8 bits of the address (in the
early days, the Mac processor used 24-bit addresses but the registers were
32-bit), which lead to the "32-bit clean" problems that plagued the first Macs
to use 32-bit addressing.

Apple also did this in the Apple II days, calling undocumented ROM monitor
routines from their own programs and operating systems. In fact, several
companies made a list of those entry points and considered them "semi-
official", the reasoning being that Apple wouldn't change entry points used by
their own programs.

------
yalogin
I would not consider the default applications on the iphone "apps" even. They
are written by Apple to provide a certain functionality and that is what they
do. They can use any API they need. Why should they not use private API? I
would not consider iBooks to be somehow different from say the phone or system
preferences "app". They are there because they are provided by the system.

~~~
praptak
Funny how Microsoft got pitchforks & torches for using this argument for
bundling IE with Windows.

~~~
eddieroger
Bundling IE was never the problem. Using private APIs to give IE a noticeable
advantage over other, more popular browsers in an effort to gain marketshare
for IE was the problem. Having a monopoly isn't illegal, and is part of
capitalism. Using a monopoly in one market (say, operating systems) gain share
in another (like, browsers) is.

------
xuki
This is how to use this on iPhone -
[https://gist.github.com/xuki/f66e4d77b682dbb0960d](https://gist.github.com/xuki/f66e4d77b682dbb0960d)

This won't pass Apple's automatic check for private API, but you could do some
clever swizzle. IMO it's ok to use this in production (if you can get pass the
app review), Apple is using them in their app anyway.

~~~
k-mcgrady
>> "This won't pass Apple's automatic check for private API, but you could do
some clever swizzle. IMO it's ok to use this in production (if you can get
pass the app review), Apple is using them in their app anyway"

Private API's shouldn't be used in production. When Apple changes them they
can update their apps to support the changes. They won't document these
changes, you won't know about them, and your app is now broken for your users.
You have to work out how to fix it, then submit it for review, and if they
catch your private API use this time around you've screwed your users.

------
ehurrell
Of course Apple 'cheats' with regard to its own closed product, it's hardly
surprising. Interesting to read about the exact mechanisms by which they do,
but I'm always reminded of Jeff Atwood's article 'Serving at the pleasure of
the king'[0]. It's Apple's party and they can define the rules however they
like. Enough people seem to be okay with this that it's a viable method of
doing business, even if it isn't desirable.

[0]: [http://blog.codinghorror.com/serving-at-the-pleasure-of-
the-...](http://blog.codinghorror.com/serving-at-the-pleasure-of-the-king/)

------
DanielBMarkham
Might be time for the Apple PR machine to crank up some more stories about
developers making millions writing apps. As every casino in Vegas knows,
watching some guy hit it big is a great way to take your mind off how many
resources you're losing.

I wonder, though, if there's going to be an end-game to this walled-garden
nonsense. On one hand, people (tech-minded people) seem to be slowly getting
it.

On the other hand, industry has somehow set up this insane legal system where
the product you buy? You don't actually own it. So I go to the store and buy
an iPhone. I give them money and I leave. This process is the same as if I
bought a regular, land-line phone. Only with the iPhone, I don't own the box,
the software, the O/S, or control what the phone does. Carrier wants me to
have new software? It pushes it out and I have it. Apple wants to get rid of a
favorite app I use? Poof, it's gone. They seem to be doing this without any
major push-back from the user community.

I am prone to think both the "educated tech user" community and the "Joe
Sixpack" community are going to meet up at some point, but I'm not sure. Maybe
the strategy with this and all the other dystopian bullshit we're seeing is to
try to run out the clock; keep things the way they are long enough so that the
argument can then be made "but it was always like this!"

It's weird. I keep reading these articles about how various services suck, but
it only seems like tech people know/care about it. That can't go on.
Something's gotta give somewhere.

~~~
poolpool
Maybe nerds, sorry, educated tech users, will eventually accept that Jobs
vision of computers as appliances is what many (most?) people want.

------
S_A_P
I can't really call this cheating. It maybe slightly inelegant or inconvenient
but there are many reasons to keep an API private. There could be security
implications, un finalized functionality. The fact is that there are probably
hundreds of API calls in iOS that can be used improperly which can harm ux or
security is a damn good reason to disallow them.

------
nemasu
Interesting, couldn't we document the private APIs and use them ourselves? Or
would Apple just reject the app then?

~~~
libovness
Apple systematically rejects apps that use private API's

~~~
xuki
Only if you let them find out ;).

~~~
andyjohnson0
How would you prevent them from finding out?

~~~
xuki
[https://speakerdeck.com/steipete/taking-advantage-of-the-
run...](https://speakerdeck.com/steipete/taking-advantage-of-the-
runtime?slide=12) \- see 2nd line

Peter Steinberger
([https://twitter.com/steipete](https://twitter.com/steipete)) shipped this in
his PSPDFKit, which is used for Box/Dropbox/Evernote.

~~~
j_s
Here is the full video of that presentation:

[http://www.youtube.com/watch?v=frgnVhBcIFA](http://www.youtube.com/watch?v=frgnVhBcIFA)

------
ant_sz
It is strange that Apple allows this API on iPad but not iPhone. What if you
want to write an iPad/iPhone universal app? Although there are many 3rd party
replacement, I prefer a native API anyway.

As for this popover API, I don't think it's a trick of anti-competive, It
matters not so much. But there are no official explanation at all, the same as
many other questions about Apple. It will be better if Apple becomes more open
-----not nessesary open source, but be open to these questions to avoid
guesses.

------
DanBC
I'm not trying to suggest any kind of equivalency here, but what's the
difference between hidden api functionality for Apple and Microsoft's
undocumented function calls?

~~~
Ensorceled
Microsoft's undocumented function calls gave a massive increase in
performance, making competing applications in multiple domains essentially
uncompetitive on the platform.

Apple is hiding a minor piece of functionality that can be implemented in
another way and, indeed, has.

I find many of Apple's iOS business practices abhorrent, but trying to even
suggest they are in the same league as 80's and 90's MS is an insult to all
the companies MS destroyed in those decades.

------
interpol_p
I don't think it's a big deal that Apple reserves some API functionality for
their own apps — you can always re-create this from scratch, after all. They
just aren't ready to fully support the popover controller API on iPhone. I'd
rather that Apple be committed to every public API they publish (they aren't,
but anything in that direction is a good thing).

What I don't like about this is _how_ they chose to implement the restriction.
Messy, hacky and inelegant.

------
taumhn
That's a pretty boring way of preventing someone from using the API. You could
easily swizzle the _popoversDisabled method and get away with it.

I remember trying to use a private API on Mac OS X and having my app receive a
SIGKILL prompty after calling the function. It took me a while to find the
fix: my app had to be signed. Mind you, it could be codesigned by a self-
signed certificate and the system would be fine with it... these were fun
times :)

------
0x0
I don't mind this particular example. They could have shipped a copy-pasted
reimplementation of the class in the app and nobody would have bat an eye.

------
eli
The way the check is implemented _looks_ bad, but this doesn't tell us
anything we didn't already know.

If you're surprised that Apple can use non-public APIs in its apps, you'll be
shocked to learn that Apple actually controls the whole ecosystem and can
block apps that compete with its own apps regardless of what APIs they use.

------
ninininini
Almost everyone on here is defending Apple. For any other company there would
be crying that someone is planting these Apple supporters or its Apple's
marketing department making these comments or a hundred other reasons why
these supportive comments shouldn't be trusted.

~~~
eli
What are you implying?

------
lepunk
It perfectly makes sense for me for this API. It is an element which could
result in bad user experience if used on the small phone screen. So their
choice was: "We either a, restrict it for iPad only or b, rejects apps using
it badly on the ground of bad user experience"

------
bluesign
I don't think this is something new, actually there are plenty of places in
UIKit code checking for bundle identifier prefix for "com.apple". Also it may
be possible for them to plan this APIs public but not yet matured
enough/finished to release.

------
whyleym
It's understandable that Apple locks down private API's, however given that
developed these often they move from the private state (beta testing for their
own apps?) to public and available for developers to develop against once they
are happy with them.

------
fpgeek
This is old news, especially with regards to iBooks:
[http://www.marco.org/2010/04/06/ibooks-and-private-
apis](http://www.marco.org/2010/04/06/ibooks-and-private-apis)

------
ksec
Apple using Private API is cheating?

Are these Dev Apple new comers? Apple has a history of dogfooding its own API
internally until it think it is good enough before releasing it to the public.

------
goblin89
One of the things why Firefox OS looks appealing to me: Mozilla is being so
open about every part of its architecture that situation such as this one is
hard to imagine.

------
tlrobinson
So who will be the first to override "bundleIdentifier" to inspect the stack
and return @"com.apple.iBooks" if UIPopoverController is calling it?

~~~
ctdonath
None, because developers have learned that lying to the OS is a fast track to
App Store rejection.

------
jasallen
As others are pointing out, yes, it's reasonable to not publish an API that
you've chosen not to invest in supporting forever.

But it still feels like this is wrong even though we know the above. The
reason it feels wrong comes back, as it always does, to Apple's walled garden.
If we could 'use it at our own risk' as we might with an unpublished Android
API or an unpublished Windows API, everyone would be fine with it.

But when 'unpublished API' means 'if you go near it your app is dead' that is
a much less reasonable thing.

~~~
ctdonath
How that "use at your own risk" is working out for Android is one notable
reason why iOS is successful: everyone isn't fine with it - customers don't
like getting the fallout of risks developers choose to make with APIs the OS
provider won't stand behind. The walled garden approach succeeds for a reason.

------
wsgeek
This seems to be the same anti-competitive behavior that Microsoft was often
found guilty of and chastised for. Come on Apple, please don't become an Evil
Empire.

------
xuesj
Good job!

------
chj
Mozilla can't port their browser to iOS, isn't that a bigger issue than this?

------
tempodox
That's not cheating. And every other shop would do it the same way. You don't
give away anything for free. Ever.

------
siphr
I am surprised that this is so shocking to the author. Stuff like this is
expected and only logical, as wrong as it may be. Apple has been desperately
trying to tie people into their eco-system and every move the company makes is
a step in that direction whether it may be immediately obvious to other people
or not. Also I should mention that I believe Apple is probably not the only
company that promotes the use of its own apps on its own platforms.
Regardless, it is nice to see some concrete indicators like this article to
actually show how that is being done.

~~~
probably_wrong
As someone who is not an iDeveloper and has no idea what the
UIPopoverController does: couldn't you make a case that Apple is deliberately
crippling the competition and, therefore, make a case for abuse of a dominant
position?

If it were so it then it wouldn't be about being shocking, expected or
logical, but about being against the law.

~~~
mantrax5
Apple has no dominant position in smartphones, so you may at best argue they
have a dominant position specifically in their own iPhones.... But if Apple
making design decisions for their iPhone product line constitutes an "abuse of
dominant position" where do we draw the line exactly?

\- Should Apple be forced to open all internal APIs to third party developers?

\- Should Apple be offering iPhones with alternative operating systems?

\- Should there be an open standard so people can build compatible iPhone
clones?

No. iPhone is Apple's product, and they decide how far they will go in opening
up their platform.

Third party developers are _not_ fully trusted to do the right thing, and as
you can see with Android's malware situation, it's a good thing Apple is not
letting random developers do whatever they want.

Since Apple is held responsible by both developers and users to have a
reliable product, when they decide to make an API public this is a huge
commitment.

Apple has to guarantee said API will be supported in a reasonable way in
future OS releases, it has to guarantee to users that calling said API won't
result in poor UX or security vulnerabilities.

The situation is much different for Apple's own apps, as Apple can then make
the personal guarantee it won't be abusing its own APIs to create poor UX and
implement malware.

~~~
username42
> Apple has no dominant position in smartphones

Where do you live ? Inform yourself
([https://www.comscore.com/Insights/Press_Releases/2014/3/comS...](https://www.comscore.com/Insights/Press_Releases/2014/3/comScore_Reports_January_2014_US_Smartphone_Subscriber_Market_Share)).
Apple has 41.6% when the second one, Samsung has 26.7%

