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.)
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.
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.
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.
> [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.
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.
> 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.
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.
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…
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.
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().
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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?
There is definitely a need for private APIs that normal apps cannot use - they might have security implications, for instance. The App Store or Settings apps clearly need to be able to do things that other apps cannot do - for instance, any app that had the same privileges as the App Store would be able to install/uninstall other apps.
Further, Apple's position is that the App Store, Settings etc. are akin to natural monopolies - it only ever makes sense to have one of each. The fact that it's not possible to implement a third-party Settings app isn't a problem because nobody should ever need to do this. This is arguable, but it's an easily defensible position for Apple and most iOS users would be happy with this (and those who aren't can jailbreak).
Having private APIs that are available to apps like iBooks, when competitors to iBooks exist, seems a bit shadier and much closer to the example of Microsoft Office using hidden/unpublished Windows APIs in the 90s. iBooks isn't some essential system service, and should be replaceable by a third-party app according to user preference. If Apple are making it even slightly more difficult for a third-party app to replace iBooks then this would appear to be anti-competitive.
IANAL, but I doubt that there is a legal case to answer. However, there does seem to be a moral case to answer. Sure, it's Apple's product and they can do what they like, but we have seen what happens when essential software vendors do what they like, and it's generally not pretty.
There would be a moral case to answer if this class exposed OS functionality that is otherwise unavailable. This is a convenience class that could easily have been copy-pasted between apps. I don't think that there is a moral case to answer.
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
Open-source operating systems seem to have pretty secure applications without depending on secret or undocumented API calls. aptitude and pacman are just normal Linux programs. How come App Store can't be a normal OS X program?
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.
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]
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.
> 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).
>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.
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.
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.
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.
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).
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.
>> "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.
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.
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.
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.
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.
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.
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?
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.
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.
[+] [-] dilap|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] danford|11 years ago|reply
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.
[+] [-] jamra|11 years ago|reply
Nothing here is private.
[+] [-] fab13n|11 years ago|reply
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.
[+] [-] keeperofdakeys|11 years ago|reply
[+] [-] danudey|11 years ago|reply
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.
[+] [-] mikeash|11 years ago|reply
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.
[+] [-] matthewmacleod|11 years ago|reply
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…
[+] [-] martinnormark|11 years ago|reply
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|11 years ago|reply
[+] [-] Touche|11 years ago|reply
[+] [-] achivetta|11 years ago|reply
[+] [-] gioele|11 years ago|reply
> 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.
[+] [-] collyw|11 years ago|reply
[+] [-] mirsadm|11 years ago|reply
[+] [-] adamlett|11 years ago|reply
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.
[+] [-] 300bps|11 years ago|reply
[+] [-] chrisdevereux|11 years ago|reply
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
[+] [-] craigching|11 years ago|reply
Yes, that hits the nail on the head. Great point.
[+] [-] callumjones|11 years ago|reply
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.
[+] [-] antimagic|11 years ago|reply
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.
[+] [-] andyjohnson0|11 years ago|reply
[+] [-] rjknight|11 years ago|reply
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.
[+] [-] chrisdevereux|11 years ago|reply
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
[+] [-] cookiecaper|11 years ago|reply
[+] [-] isawczuk|11 years ago|reply
[+] [-] zackboe|11 years ago|reply
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...
[+] [-] poolpool|11 years ago|reply
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|11 years ago|reply
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-...
[+] [-] danford|11 years ago|reply
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.
[+] [-] nateabele|11 years ago|reply
When you put yourself in the shoes of the people on the product teams building the apps and maintaining the APIs, it's easy to see this for what it's much more likely to be: a hack that was implemented so that someone could leave the office at a reasonable hour.
[+] [-] mitosis|11 years ago|reply
Apple also did this in the Apple II days, calling undocumented ROM monitor routines from their own programs and operating systems. In fact, several companies made a list of those entry points and considered them "semi-official", the reasoning being that Apple wouldn't change entry points used by their own programs.
[+] [-] yalogin|11 years ago|reply
[+] [-] praptak|11 years ago|reply
[+] [-] DCKing|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
Private API's shouldn't be used in production. When Apple changes them they can update their apps to support the changes. They won't document these changes, you won't know about them, and your app is now broken for your users. You have to work out how to fix it, then submit it for review, and if they catch your private API use this time around you've screwed your users.
[+] [-] ehurrell|11 years ago|reply
[0]: http://blog.codinghorror.com/serving-at-the-pleasure-of-the-...
[+] [-] DanielBMarkham|11 years ago|reply
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|11 years ago|reply
[+] [-] ctdonath|11 years ago|reply
[+] [-] S_A_P|11 years ago|reply
[+] [-] nemasu|11 years ago|reply
[+] [-] libovness|11 years ago|reply
[+] [-] ant_sz|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] DanBC|11 years ago|reply
[+] [-] Ensorceled|11 years ago|reply
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.
[+] [-] DougBTX|11 years ago|reply