How Apple Cheats

http://marksands.github.io/2014/05/27/how-apple-cheats.html

by libovness • 12 years ago

348 228 12 years ago

marksands.github.io

nemasu3• 12 years ago

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

libovness• 12 years ago

Apple systematically rejects apps that use private API's

xuki3• 12 years ago

Only if you let them find out ;).

siphr2• 12 years ago

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.

username424• 12 years ago

I agree that stuff like this is expected but I am still shocked. I think that this kind of revelations means you never really own the iphone you have bought. It is more like a leasing. The only way to own what you buy is to switch to open alternatives.

mantrax54• 12 years ago

Oh yeah. Without UIPopoverController on iPhone, it's like you lease your phone, and at any moment Apple may pull the string to that UIPopoverController and take their phone back.

Do you even read what you write or you just mash the keyboard and hit "reply"?

probably_wrong• 12 years ago

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.

matthewmacleod4• 12 years ago

UIPopoverController is a trivial UI element which allows an app to display a kind of tooltip-style contextual view above the app. It would be hard to argue that the exclusion of this API would constitute "crippling" anything, given the number of alternatives which are available.

mantrax54• 12 years ago

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.

mantrax54• 12 years ago

I like how your rant about "trying to tie people into their ecosystem" has absolutely nothing with the situation here, which is the fact Apple's apps use some harmless private APIs before they finalize them to a degree to make them public.

Tell me, what other "expected and only logical" things did you encounter while reading the article? I'm sure there's an alien invasion conspiracy theory in there somewhere.

FireBeyond• 12 years ago

Bleh. Come on, this is just apologist. So much spin here about how "it might not be production ready, so of course they're just 'testing' it internally before making it widely available".

Except...

As noted elsewhere, "it's a trivial component, almost akin to a tooltip".

And iBooks, one of the apps, was introduced in January 2010, and requires iOS 4.3 or later.

People who, with a straight face, claim that Apple has needed nearly four-and-a-half years (more, really, since there was pre-release testing), and since iOS 4.3 to make sure a "trivial component" was ready for the public are really grasping at straws.

w0utert• 12 years ago

> Stuff like this is expected and only logical, as wrong as it may be

Maybe it's just me, but I really don't see what's "wrong" about Apple using private API's and workarounds that are not available to 3-rd party apps. I also don't see how this is different from about every other piece of commercial software in existence, the Windows API is well known to be full of undocumented API's that are only used by Microsoft, for example.

The only way I could interpret a commercial vendor using private API's unvailable to third party applications as 'wrong' is if they secretly use them to gain a competitive advantage over third-party vendors of competing applications. This is clearly not the case on iOS, because the whole system is already locked down, and publishing applications directly competing with Apple stock apps is explicitly disallowed in the submission guidelines. Whether you agree about that is a different thing, but there's nothing secret about it.

As far as I can tell, there also is no pattern whatsoever of Apple applications somehow using magic killer unicorn features that are unvailable to third-party apps. Did anyone ever get the impression that third-party apps on iOS are second rate compared to stock apps? I surely haven't, I'd even go as far as saying it's the opposite. Also the list of app bundle exceptions that can use UIPopoverController is so small, I expect there's a much simpler explanation here. Most likely UIPopoverController does not work reliably on iOS, except in some restricted use cases, and Apple chose to disable it for third-party apps to prevent applications with broken user interfaces or having to support UIPopOverController use cases they didn't intend to be used on smalls screens.

ehurrell• 12 years ago

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

chrisdevereux2• 12 years ago

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

craigching2• 12 years ago

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.

wsgeek• 12 years ago

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.

callumjones2• 12 years ago

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.

andyjohnson02• 12 years ago

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?

callumjones2• 12 years ago

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.

matthewmacleod4• 12 years ago

With first-party apps being under Apple's control, it's possible to test them extensively, or make sure that they only use a working subset of the API, etc.

antimagic• 12 years ago

Exactly. I rather suspect that there are some parts of UIPopoverController that have problems with the different screen sizes on say an iPhone 4S and an iPhone 5S. Apple trust themselves not to call the parts that don't work, but have not yet ironed out all of the bugs for third-party use.

Unless I've missed something about UIPopoverController, it's implemented using public APIs, so I'm curious as to what the author thinks Apple's motivation is for holding back this API - it's not like you can't create the same functionality yourself using existing APIs, it's just a bit more work. My guess would be that maybe they don't want to see people using popover controllers all over the place on the phone, so they made the bar higher for implementing such functionality.

yalogin• 12 years ago

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.

praptak2• 12 years ago

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

poolpool3• 12 years ago

Funny how Microsoft owned 90%+ of installs globally. Just because everyone copies apple doesn't mean everyone uses apple and needs to bend to their will. It's the opposite actually.

eddieroger• 12 years ago

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.

Tyrannosaurs• 12 years ago

To me the issue with IE and Windows was that MS went from a position where IE basically didn't exist (but other browsers did and worked fine on it's OS) to "it couldn't possibly not be tightly integrated into Windows" in no time at all.

DCKing• 12 years ago

That should only go as far as the app store and the settings app. The rest of the applications on the system have no reason to be special for they don't need special system administration tasks to function.

Android even functions where nothing is a 'special' app. (Although no phone is actually released that way, but it can be achieved with custom ROMs).

smackfu• 12 years ago

You need to download iBooks, it does not come pre-installed.

xuki3• 12 years ago

This is how to use this on iPhone - 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• 12 years ago

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

matthewmacleod4• 12 years ago

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…

craigching2• 12 years ago

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.

jcl• 12 years ago

What I find confusing is why the API would be acceptable on an iPad and not on an iPhone. It seems unlikely that Apple would be willing to devote the resources to testing the element on one and not the other, or that the software behind the two implementations is different enough that testing would not carry between the two. And, if that were the case, surely it would have been easier to just not release the API at all?

Rather, it sounds like someone at Apple decided that popover widgets provide a poor user experience in small form factors unless they are carefully designed, so they disabled the API on the iPhone to discourage careless use. Obviously, the same restriction would not apply to Apple... which is unfair but understandable, given that "We know design better than you" is basically Apple's value proposition.

JamesSwift• 12 years ago

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

I was with you until here. I'd much rather just use the same 1st party component on a universal app, rather than a 2nd or 3rd party approximation.

dilap2• 12 years ago

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

jacquesm7• 12 years ago

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

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.

chaz72• 12 years ago

Microsoft had a monopoly position at that time, and Apple does not.

dilap2• 12 years ago

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.

greedy_buffer• 12 years ago

Does this apply to the same extent to phones as it does to an operating system? Apple has made devices that don't even have an app store - nobody cries foul that the Nokia 1100 only runs Nokia software.

icantthinkofone2• 12 years ago

The difference may be that Microsoft used the private APIs to give itself (and select partners) advantages over competitors while being a monopoly. I don't know if Apple is using those APIs to give themselves an advantage over competitors but they certainly are not a monopoly as Microsoft is.

coldtea9• 12 years ago

Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party.

Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here.

But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.

GrinningFool3• 12 years ago

Those rules apply in a monopoly - when a business is not a monopoly it has considerably more freedom.

frik• 12 years ago

The Windows system control, Explorer UI, Internet Explorer UI, Office UI all use undocumented APIs since Win98/2k and Office 95.

It's called Windows "DirectUser" UI and it's in violation of the antitrust settlement.

sources:

* http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/52952...

* http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US...

  Internet Explorer's use of DUSER.DLL is only temporary. 
  The final version of Internet Explorer will not use it.
  -- Raymond Chen [author of "The Old New Thing"]

* yet, IE 7+ uses DirectUser UI: http://blogs.msdn.com/b/ie/archive/2006/02/01/a-new-look-for...

fab13n• 12 years ago

[it's reasonable not to commit to long-term API support lightly]

Another dimension, which I think primes here, is potential for abuse: things either likely to be used for scammy features, or leading to 99% of results in very poor tastes (think of those as the descendants of the <blink> tag from the 90's). It's simpler and creates less outrage to block those APIs than to reject most of the applications misusing them.

I think that's one of the reasons why they disallowed compatibility layers: it would have encouraged poor UX as, by definition, they only offer the common denominator of all the targeted platforms (I'm not naive about other motives, but they're off-topic).

What Apple sales is great user experience. App developers are only welcome as long as they're improving that experience. They're currently useful to Apple as a whole, but they aren't Apple's customers.

And of course Apple trusts itself to respect its own sense of taste, so doesn't need any self-limitation. They're your host in their personal walled garden, they can't even imagine that you'd ask to "compete with them on equal grounds".

As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. They're intended for serious alerts requiring immediate action from the user, and they're often used as a substitute for a usable notification UI.

madeofpalk• 12 years ago

As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent.

This is for a popover like this http://i.imgur.com/ItDZQRL.png

Not a popup like this (known as an alert in iOS) http://i.imgur.com/3U2Tq2e.png

jamra4• 12 years ago

The situation you're describing is not the same situation as described in the article. This API is not private. It's a public API for the iPad. There is a check that detects if you are running an iPad or iPhone. If you are running an iPhone, your program will crash.... unless it is one of the internal apple apps.

Nothing here is private.

matthewmacleod4• 12 years ago

I think you've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.

eli3• 12 years ago

I think you are just being pedantic here. It's private in the sense that it is not usable by the public on this device.

danford5• 12 years ago

You've got to support the API forever

Not really. Many APIs have features that are put in and removed all the time. The key to managing this is having a good API that tags features as things like 'experimental', 'deprecated', 'locked', etc to indicate if features are permanent or could be changing.

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.

taumhn2• 12 years ago

I'm actually rather happy with the Apple philosophy of not opening APIs early and supporting them as long as possible when they've been made public, rather than having to check my app against 6 levels of API stability... thank you very much.

danudey• 12 years ago

You've got to support the API forever, and future design directions are constrained.

Actually, I think part of the reason for Apple's reluctance is that they don't do this; they'll gladly deprecate APIs and remove them in future versions, but that's about as bad because now you're breaking apps (which admittedly are unable or unwilling to update).

This is especially a problem in corporate environments with custom iPad apps; if the customer doesn't want to pay the developer to update for newer iOS versions, then they basically can't buy new devices once the API is removed, because their app won't work. This is why Microsoft keeps APIs around forever, and why businesses keep running XP until ten years has gone by and they start getting hammered with 0-days.

keeperofdakeys3• 12 years ago

If taken too far, this can lead to two-tiers of applications, which can be incredibly bad for the eco-system. On early Windows Phone 7, Nokia used an entirely different api to other apps, that gave much more freedom. So Nokia apps both allowed custom styles, and were much faster. This meant no apps on the store could really compete with the system apps. I'm unsure if this changed with Windows Phone 8, though I'm sure it would have.

ctdonath6• 12 years ago

There's a difference between private APIs which are convenient for Apple to use and inconvenient for Apple to let others use but developers can create alternatives without much difficulty, vs private APIs which give Apple an outright unfair advantage over others.

Are there any private APIs which really do amount to "unfair advantage for Apple"? or does the whole issue amount to sniveling about not being able to play with all their toys and having to bring your own?

mikeash4• 12 years ago

It would be one thing if this was just built-in apps that need special capabilities. It's reasonable for, say, Settings to use private APIs, because it's special. (I don't agree with that, and would like third-party apps to be allowed to change that stuff too, but I don't think it's an unreasonable stance.)

However, this is iBooks, which you get from the App Store just like all third-party apps. It's explicitly competing with products from third-party developers. In this area, there should be a level playing field.

When us third-party developers distribute on the App Store, we have to agree to a contract that, among other things, states that our apps will not use private APIs. Why do Apple's apps, when distributed through the App Store, not follow the same rules? Why should they get special treatment for apps that aren't built in to the OS and which are distributed using the same channels the rest of us use?

This popover example is fairly trivial, since nothing stops you from building your own version of it and shipping it in your app, but it illustrates the point. A more significant example is the screen brightness control. iBooks has a slider that you can use to adjust the brightness of the screen. This brightness adjustment uses private API, and because of that, other eBook readers cannot replicate that feature. There is no technical reason third-party apps couldn't do this (they have the same access to the device that iBooks does) but Apple doesn't allow it.

The Kindle app, for example, has a brightness slider too. Except it doesn't adjust the screen brightness. It just adjusts the gray level of the white background, while leaving the backlight at original strength. This means that you lose contrast and use more battery power, meaning that the Kindle app is inherently worse because Apple isn't playing fair.

This is less important these days, now that Control Center lets you easily access the device brightness from anywhere. It was a big hit against Kindle's usability for years, though.

rjknight• 12 years ago

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.

isawczuk• 12 years ago

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.

cookiecaper• 12 years ago

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?

dtech• 12 years ago

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?

coldtea9• 12 years ago

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.

chrisdevereux2• 12 years ago

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.

DanBC• 12 years ago

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?

DougBTX• 12 years ago

The practical difference is that if you write an application which gets wide scale adoption which uses Microsoft's undocumented APIs, then Microsoft might choose to support those as-is in future versions of the OS, whereas with Apple you'll just not be able to release your application.

Ensorceled• 12 years ago

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.

whyleym• 12 years ago

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.

ant_sz• 12 years ago

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.

DanielBMarkham• 12 years ago

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.

poolpool3• 12 years ago

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

ctdonath6• 12 years ago

The fact that Apple, with a half-dozen products, is holding some 50% of the smartphone market against thousands of spec-equal competing products from hundreds of manufacturers shows there is something important lacking in your argument.

lepunk• 12 years ago

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"

0x0• 12 years ago

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.

bluesign• 12 years ago

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.

tempodox• 12 years ago

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

xuesj• 12 years ago

Good job!

poolpool3• 12 years ago

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.

jrochkind1• 12 years ago

you still own your phone. Don't be silly. Jailbreak and builds apps to your hearts content.

In the U.S., only as long as the Librarian of Congress keeps granting temporary exemptions to the DMCA, that otherwise probably makes jailbreaking your phone illegal. (And they have not exempted jailbreaking on tablets).

http://arstechnica.com/tech-policy/2012/10/jailbreaking-now-...

danford5• 12 years ago

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• 12 years ago

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

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

gioele• 12 years ago

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://www.tbray.org/ongoing/When/201x/2010/05/06/Private-AP...

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.

mirsadm• 12 years ago

Not only that I believe Google contacted most of the popular SMS devs when they made huge changes to the SMS content providers in Kit Kat (which are private). They didn't really need to but did to let them know of the changes.

loumf3• 12 years ago

Yes they did. If they deliver an OS upgrade and a bunch of apps stop working, the user will blame the OS upgrade regardless of the real reason. Raymond Chen (from MS) covered this well on his blog

http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...

keeperofdakeys3• 12 years ago

However they acted differently for the wakelock api. In Android, there is a private api that allowed access to a list of wakelocks, which was used by many apps to provide the user with more information about what is keeping the system awake. However, their was a security implication (this was a real concern), so 4.4 made the api both private and inaccessible. (Private apis by default you can't use, but you can get around it by getting a reference using language-features). Unlike the sms situation though, they didn't provide a replacement api without the security issue. So now you need to root the phone in order to access the list of wakelocks.

While this may not affect most of the users of these apps, this is quite unfortunate, because these applications were especially handy on non-stock phones, which usually aren't easily rootable.

adamlett• 12 years ago

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.

Which is swell if you're an application developer. But for the end users it means that apps may suddenly stop working if they upgrade the OS.

Anderkent• 12 years ago

OTOH, you get apps that can actually do things, rather than only whatever google produces.

danford5• 12 years ago

I've had apps stop working after upgrades on every device I have ever used.

It's important that the developer keep up with an evolving API and if they plan to use experimental features that aren't locked in yet, they should make note and be prepared for if/when it's taken out or changed.

Unfortunately, no matter what device you use, there will be developers who fail to maintain their apps.

300bps• 12 years ago

Having an unsupported API method is one level of "cheating". Hardcoding bundle names and only allowing certain applications to call your unsupported API method takes it to a new level.

loumf3• 12 years ago

What if the code was just in an unreleased static lib that was linked to each app.

Isn't Apple allowed to make shared code for just its apps? Putting it in the supported frameworks is just an easier way to make sure that it eventually gets released for everyone -- otherwise lots of useful code might just languish inside apps and private libs.

collyw• 12 years ago

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.

abhigupta2• 12 years ago

I find that such relative comparison put things in perspective.

adamors• 12 years ago

Having private APIs is now behaving like a twat? This whole issue is ridiculous, it concerns a user interface element!

martinnormark2• 12 years ago

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

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• 12 years ago

My understanding is that Raymond Chen ( 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...

martinnormark2• 12 years ago

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

achivetta• 12 years ago

Amazingly, this sort of use-after-free causes compatibility problems for allocator writers even today. Imagine if you change the implementation of malloc() such that smaller allocations get their own mmap() region rather than being stuffed in with other allocations. Now any use-after-free bugs to allocations affected by the change will segfault instead of reading garbage, since the allocator would munmap the region upon free().

keeperofdakeys3• 12 years ago

That's why programs like valgrind are great, they check all your memory allocations, and ensure these kinds of bugs don't occur (though it can only test codepaths that run, and has an overhead for all the checks).

This is also why I'm so excited about Rust. Suddenly your compiler and language definition ensure these kinds of bugs can't occur.

Touche• 12 years ago

While a fascinating story, this is nothing like that.

ninininini• 12 years ago

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.

eli3• 12 years ago

What are you implying?

eli3• 12 years ago

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.

mitosis• 12 years ago

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.

fpgeek• 12 years ago

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

zackboe• 12 years ago

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

[1] http://www.chromium.org/developers/design-documents/extensio...

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

[3] https://code.google.com/p/chromium/codesearch#chromium/src/c...

S_A_P• 12 years ago

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.

jasallen• 12 years ago

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.

ctdonath6• 12 years ago

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.

interpol_p• 12 years ago

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.

taumhn2• 12 years ago

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 :)

chj• 12 years ago

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

nateabele• 12 years ago

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.

tlrobinson• 12 years ago

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

ctdonath6• 12 years ago

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

goblin89• 12 years ago

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.

ksec• 12 years ago

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.

How Apple Cheats

Related Stories