12 ms·

How Apple Cheats

348 points by libovness 12y ago

nemasu 12y ago
Interesting, couldn't we document the private APIs and use them ourselves? Or would Apple just reject the app then?
- libovness 12y ago
  Apple systematically rejects apps that use private API's
  - xuki 12y ago
    Only if you let them find out ;).
    - andyjohnson0 12y ago
      How would you prevent them from finding out?
      - xuki 12y ago
        https://speakerdeck.com/steipete/taking-advantage-of-the-runtime?slide=12 https://speakerdeck.com/steipete/taking-advantage-of-the-run... - 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 12y ago
        Here is the full video of that presentation: http://www.youtube.com/watch?v=frgnVhBcIFA http://www.youtube.com/watch?v=frgnVhBcIFA
    - logicallee 12y ago
      You're going to have to elaborate if you know any more, it seems incredibly easy to check programmatically.
    - nemasu 12y ago
      Hmmmmmm...downloadable 'modules'?
      - mantrax5 12y ago
        You can't download executable code to an iPhone app outside the App Store, only data.
        nemasu 12y ago
        Curious, how do they know it's executable?
    - userbinator 12y ago
      Apps are Turing-complete, right? In theory, that means it's possible to make an arbitarily complex and obfuscated route to a private API, making it impossible to detect via simple static analysis.
siphr 12y 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.
- username42 12y 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.
  - mantrax5 12y 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"?
    - username42 12y ago
      Please, do not joke about my english. This article is about the iphone that has features that are blocked by Apple. If you own the phone, you remove the block and use the feature. Take the example of a car where there would be a huge stone on the middle back sit. You can not use the middle back sit without removing the stone, but the seller of the car prohibits to remove the stone.
      - Geee 12y ago
        No, there is a stone in every the car but Apple hides it and you can't unhide it.
ehurrell 12y 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-king/ http://blog.codinghorror.com/serving-at-the-pleasure-of-the-...
chrisdevereux 12y 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 https://www.cocoacontrols.com/search?utf8=✓&q=popover
- craigching 12y 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 12y 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.
callumjones 12y 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.
- andyjohnson0 12y 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?
  - callumjones 12y 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.
  - matthewmacleod 12y 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 12y 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 12y 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.
- praptak 12y ago
  Funny how Microsoft got pitchforks & torches for using this argument for bundling IE with Windows.
  - poolpool 12y 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 12y 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 12y 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 12y 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).
xuki 12y ago
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 12y 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.
matthewmacleod 12y 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…
- craigching 12y 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 12y 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 12y ago
dilap 12y 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.)
- jacquesm 12y 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-undocumented-windows-apis-iowa-testimony 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 12y ago
    Microsoft had a monopoly position at that time, and Apple does not.
    - jacquesm 12y ago
      Is it possible to run Windows Phone or Android on iPhones now? They may not have a monopoly on smartphones (they wished they did, and maybe they even think they deserve one), but that's not for lack of trying and as far as systems software on hardware supplied by Apple goes they do. You can't buy an iPhone without iOs and nobody makes an alternative. Anti-trust law does not require a monopoly per-se, 'market power' is a well established concept and within the iPhone hardware segment Apple has 100% market power when it comes to systems software, on top of that they control (through their app store) 100% of all software that gets installed on those devices. So if an apple supplied app out-competes a 3rd party supplied app by using api's only known to apple then that might lead to trouble. I have no illusion that that would be an extremely hard case to fight/win, especially given the fact that Apple is the largest company and has a nearly unlimited budget when it comes to hiring lawyers.
rjknight 12y 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 12y 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 12y 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 12y 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?
DanBC 12y 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 12y 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 12y 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 12y 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.
HannibalLecter 12y ago
The poor ethical state of affairs in the technology field is precisely what is slowing down humanity. Let's just run out of time and do the universe a favor, and rid it of our stupidity.
ant_sz 12y 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 12y 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.
- poolpool 12y ago
  Maybe nerds, sorry, educated tech users, will eventually accept that Jobs vision of computers as appliances is what many (most?) people want.
- ctdonath 12y 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 12y 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 12y 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 12y 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 12y 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 12y ago
Good job!
poolpool 12y 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 12y 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-legal-under-dmca-for-smartphones-but-not-tablets/ http://arstechnica.com/tech-policy/2012/10/jailbreaking-now-...
- danford 12y 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.
gioele 12y 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-with-content-providers.html http://android-developers.blogspot.de/2010/05/be-careful-wit... http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-APIs 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 12y 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.
  - loumf 12y 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.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
    - pdpi 12y ago
martinnormark 12y 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 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 12y ago
  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/0321440307 http://www.amazon.com/The-Old-New-Thing-Development/dp/03214...
  - martinnormark 12y ago
    Amazing. Thanks, I didn't know of him specifically but I do remember seeing his book somewhere.
- achivetta 12y 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().
jasallen 12y 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.
- ctdonath 12y 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.
deleted 12y ago
[deleted]
ninininini 12y 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.
- deleted 12y ago
  [deleted]
- eli 12y ago
  What are you implying?
eli 12y 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 12y 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 12y ago
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
zackboe 12y 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/nckgahadagoaajjgafhacjanaoiihapd?hl=en https://chrome.google.com/webstore/detail/hangouts/nckgahada... [1] http://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development/panels http://www.chromium.org/developers/design-documents/extensio... [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/chrome/browser/ui/panels/panel_manager.cc&q=file:panel_manager.cc%20nckgahadagoaajjgafhacjanaoiihapd&sq=package:chromium&type=cs&l=128 https://code.google.com/p/chromium/codesearch#chromium/src/c...
S_A_P 12y 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.
interpol_p 12y 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.
taumhn 12y 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 12y ago
Mozilla can't port their browser to iOS, isn't that a bigger issue than this?
nateabele 12y 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 12y ago
So who will be the first to override "bundleIdentifier" to inspect the stack and return @"com.apple.iBooks" if UIPopoverController is calling it?
- ctdonath 12y ago
  None, because developers have learned that lying to the OS is a fast track to App Store rejection.
goblin89 12y 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.
deleted 12y ago
[deleted]
ksec 12y 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

348 points by libovness 12y ago

nemasu 12y ago

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

libovness 12y ago
Apple systematically rejects apps that use private API's
- xuki 12y ago
  Only if you let them find out ;).
  - andyjohnson0 12y ago
    How would you prevent them from finding out?
    - xuki 12y ago
      https://speakerdeck.com/steipete/taking-advantage-of-the-runtime?slide=12 https://speakerdeck.com/steipete/taking-advantage-of-the-run... - 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 12y ago
        Here is the full video of that presentation: http://www.youtube.com/watch?v=frgnVhBcIFA http://www.youtube.com/watch?v=frgnVhBcIFA
  - logicallee 12y ago
    You're going to have to elaborate if you know any more, it seems incredibly easy to check programmatically.
  - nemasu 12y ago
    Hmmmmmm...downloadable 'modules'?
    - mantrax5 12y ago
      You can't download executable code to an iPhone app outside the App Store, only data.
      - nemasu 12y ago
        Curious, how do they know it's executable?
  - userbinator 12y ago
    Apps are Turing-complete, right? In theory, that means it's possible to make an arbitarily complex and obfuscated route to a private API, making it impossible to detect via simple static analysis.

siphr 12y 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.

username42 12y 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.
- mantrax5 12y 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"?
  - username42 12y ago
    Please, do not joke about my english. This article is about the iphone that has features that are blocked by Apple. If you own the phone, you remove the block and use the feature. Take the example of a car where there would be a huge stone on the middle back sit. You can not use the middle back sit without removing the stone, but the seller of the car prohibits to remove the stone.
    - Geee 12y ago
      No, there is a stone in every the car but Apple hides it and you can't unhide it.

ehurrell 12y 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-king/ http://blog.codinghorror.com/serving-at-the-pleasure-of-the-...

chrisdevereux 12y 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 https://www.cocoacontrols.com/search?utf8=✓&q=popover

craigching 12y 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 12y 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.

callumjones 12y 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.

andyjohnson0 12y 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?
- callumjones 12y 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.
- matthewmacleod 12y 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 12y 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 12y 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.

praptak 12y ago
Funny how Microsoft got pitchforks & torches for using this argument for bundling IE with Windows.
- poolpool 12y 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 12y 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 12y 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 12y 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).

xuki 12y ago

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

matthewmacleod 12y 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…

craigching 12y 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 12y 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 12y ago

dilap 12y 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.)

jacquesm 12y 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-undocumented-windows-apis-iowa-testimony 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 12y ago
  Microsoft had a monopoly position at that time, and Apple does not.
  - jacquesm 12y ago
    Is it possible to run Windows Phone or Android on iPhones now? They may not have a monopoly on smartphones (they wished they did, and maybe they even think they deserve one), but that's not for lack of trying and as far as systems software on hardware supplied by Apple goes they do. You can't buy an iPhone without iOs and nobody makes an alternative. Anti-trust law does not require a monopoly per-se, 'market power' is a well established concept and within the iPhone hardware segment Apple has 100% market power when it comes to systems software, on top of that they control (through their app store) 100% of all software that gets installed on those devices. So if an apple supplied app out-competes a 3rd party supplied app by using api's only known to apple then that might lead to trouble. I have no illusion that that would be an extremely hard case to fight/win, especially given the fact that Apple is the largest company and has a nearly unlimited budget when it comes to hiring lawyers.

rjknight 12y 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 12y 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 12y 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 12y 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?

DanBC 12y 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 12y 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 12y 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 12y 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.

HannibalLecter 12y ago

The poor ethical state of affairs in the technology field is precisely what is slowing down humanity. Let's just run out of time and do the universe a favor, and rid it of our stupidity.

ant_sz 12y 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 12y 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.

poolpool 12y ago
Maybe nerds, sorry, educated tech users, will eventually accept that Jobs vision of computers as appliances is what many (most?) people want.
ctdonath 12y 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 12y 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 12y 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 12y 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 12y 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 12y ago

Good job!

poolpool 12y 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 12y 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-legal-under-dmca-for-smartphones-but-not-tablets/ http://arstechnica.com/tech-policy/2012/10/jailbreaking-now-...
danford 12y 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.

gioele 12y 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-with-content-providers.html http://android-developers.blogspot.de/2010/05/be-careful-wit... http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-APIs 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 12y 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.
- loumf 12y 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.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
  - pdpi 12y ago

martinnormark 12y 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 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 12y ago
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/0321440307 http://www.amazon.com/The-Old-New-Thing-Development/dp/03214...
- martinnormark 12y ago
  Amazing. Thanks, I didn't know of him specifically but I do remember seeing his book somewhere.
achivetta 12y 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().

jasallen 12y 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.

ctdonath 12y 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.

deleted 12y ago

[deleted]

ninininini 12y 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.

deleted 12y ago
[deleted]
eli 12y ago
What are you implying?

eli 12y 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 12y 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 12y ago

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

zackboe 12y 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/nckgahadagoaajjgafhacjanaoiihapd?hl=en https://chrome.google.com/webstore/detail/hangouts/nckgahada... [1] http://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development/panels http://www.chromium.org/developers/design-documents/extensio... [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/chrome/browser/ui/panels/panel_manager.cc&q=file:panel_manager.cc%20nckgahadagoaajjgafhacjanaoiihapd&sq=package:chromium&type=cs&l=128 https://code.google.com/p/chromium/codesearch#chromium/src/c...

S_A_P 12y 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.

interpol_p 12y 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.

taumhn 12y 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 12y ago

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

nateabele 12y 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 12y ago

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

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

goblin89 12y 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.

deleted 12y ago

[deleted]

ksec 12y 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.