12 ms·

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

by 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.
    - celticninja 12y ago
      You are fundamentally misunderstanding a monopoly position.
      - jacquesm 12y ago
        And you are fundamentally misunderstanding that anti-trust law is about more than just monopolies.
        cynicalkane 12y ago
        Except you're not an antitrust law expert, you're a Random Guy On The Internet making up handwavey arguments that would never fly in court. Under this principle, you could say Nintendo has a monopoly on Nintendos and must therefore open secret APIs to developers, or that whatever cable box company has a monopoly on their particular brand of cable boxes, &c. Courts reject principles that lead to absurdity under simple substitutions. I don't know what your comment about "anti-trust law being about more than monopolies" is supposed to mean. It says nothing, and furthermore says nothing with an authority to which you are not entitled, being not an antitrust law expert. So your unsupported and unreasonable claims should be discounted accordingly.
        jacquesm 12y ago
        If the only people allowed to talk about anything are experts then we might as well shut down every forum on the internet including this one. But have a read on the various pages written by experts and come up with arguments against what I said instead of just trying to attack my credibility.
        cynicalkane 12y ago
        No, the point is you have no argument in addition to no authority. It's normal to require one or the other.
        12y ago
  - room271 12y ago
    In the vast chasm between pure monopoly (one supplier) and the perfectly competitive market (which is imaginary), is large room for firms which have competition but are still big enough to abuse their market position. It's not useful to focus only on pure monopoly. From an economics perspective, there are plenty of other market structures which can be damaging for consumers.
    - endersshadow 12y ago
      It's not just the person you're responding to--the FTC looks only at relatively pure monopolies for anti-trust violations. There are lots of things that are legal as a player in a competitive market versus illegal as a monopoly. The US has a long history with pure monopolies, which are why the laws are the way they are. You can argue until you're blue in the face that the FTC should look at other things, as well, but I'm not sure you'll get very far.
      - scott00 12y ago
        The SEC has nothing to do with enforcement of antitrust law. The Federal Trade Commission and the Department of Justice share that responsibility.
        endersshadow 12y ago
        You're right, I'm sorry--it was early and I got my initialisms wrong. Thank you for the correction--I'll correct my post.
    - GrinningFool 12y ago
      But from a legal perspective [IANAL, but I'm pretty confident on this one], they can engineer the system to give them an advantage as long as they don't have an monopoly. When a company is a monopoly, new rules do apply.
      - gnopgnip 12y ago
        Anti competitive practices are illegal, not monopolies.
- dilap 12y ago
  Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.
  - reidrac 12y ago
    If Apple is a abusing his position as OS provider by using in their apps APIs that are not available to other app developers, I'm not sure if the right answer is "go and develop for Android instead". What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did.
    - seszett 12y ago
      > What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did. They sometimes do, though, with Maps for example. ... and Maps is precisely one of the apps that use private APIs.
    - Consultant32452 12y ago
      I haven't checked into it lately but Apple certainly used to ban any competing apps from its app store. So if you had an iTunes competitor, you weren't going to get it released for iOS. http://www.cnet.com/news/apple-blocks-competitive-products-from-iphone-app-store-surprised/ http://www.cnet.com/news/apple-blocks-competitive-products-f...
  - loup-vaillant 12y ago
    It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.
    - al2o3cr 12y ago
      "local monopoly": meaningless. That's like saying that Gmail has a "local monopoly" on web-based email because switching would be a hassle.
- greedy_buffer 12y ago
  Does this apply to the same extent to phones as it does to an operating system? Apple has made devices that don't even have an app store - nobody cries foul that the Nokia 1100 only runs Nokia software.
- icantthinkofone 12y ago
  The difference may be that Microsoft used the private APIs to give itself (and select partners) advantages over competitors while being a monopoly. I don't know if Apple is using those APIs to give themselves an advantage over competitors but they certainly are not a monopoly as Microsoft is.
  - jacquesm 12y ago
    As microsoft was. At this point in time I don't think that anybody would be able to present an argument to the effect that Microsoft is the dominant player in consumer or business computing. The number of devices not running a Microsoft OS is significant.
    - icantthinkofone 12y ago
      At the time, there was only the desktop market and no mobile to speak of. Microsoft still dominates the desktop but how that figures into a monopoly calculation, I'm not sure.
    - dTal 12y ago
      Devices, sure. But computing? Some perspective: You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only). Businesses universally use PowerPoint, Excel, and Word. If you work in industry or manufacturing, you may have noticed that the drivers for specialist equipment are always for Windows. "Industry Standard" software like 3ds Max only runs on Windows. Government still overwhelmingly uses Windows, which is why it's still "news" when somewhere switches to Linux (usually Berlin again). Healthcare uses Windows. In the consumer OS space, nobody is even trying to compete with them commercially. The worst they have to worry about there is poor publicity from a lemon version of Windows, because no matter how crap it is all new computers will still ship with it. Seems to me Microsoft is still dominant.
      - dragonwriter 12y ago
        > You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only). Or ChromeOS. Or more traditional Linux (a number of vendors sell them). Last I checked (though I haven't for a while) you could even get OS-free laptops on NewEgg.
- coldtea 12y ago
  Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party. Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here. But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.
  - logfromblammo 12y ago
    It could be replicated by a third party, but thanks to Apple policy, using such a third-party component could be grounds for removal from the Apple App Store. What Apple can do and what it should do are not necessarily the same things. While it can establish privileged APIs, it should not. While it can attempt to support outside developers as a hardware company while also competing with them as a software company, it should not. If it is easily demonstrated for this particular API, it may be present and less obvious elsewhere, including a serious API. The only way to know for sure is to inspect the code.
    - Moto7451 12y ago
      Nonsense. I'm using WYPopoverController[1] in some of my apps and they're a-ok. On the component's page they even have links to apps in the App Store that use it[2]. [1] https://www.cocoacontrols.com/controls/wypopovercontroller https://www.cocoacontrols.com/controls/wypopovercontroller [2] https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=4 https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=...
      - kbenson 12y ago
        Whether they have removed apps that use is irrelevant. That they can at any point remove them because of their policies but don't should not be lauded, it just creates an air of confusion that they can use to their benefit as they see fit.
        logfromblammo 12y ago
- GrinningFool 12y ago
  Those rules apply in a monopoly - when a business is not a monopoly it has considerably more freedom.
  - rando289 12y ago
    Apple has a monopoly on operating systems which work on apple hardware.
    - andor436 12y ago
      Hello from Windows on a MacBook!
    - valarauca1 12y ago
      I don't think your understanding how a Monopoly applied in the situation with Microsoft. Microsoft's Anti-trust suite was because of its web browser's dominance, IE was during the anti-trust suite upwards of 95% of all browsers on the Internet, this was because of bundling and defaults. While other OS's may not execute on Apple's own hardware, other hardware exists (other smart phones) that directly compete with Apple. And by compete I mean neither Apple nor Andriod nor WindowsPhone 'owns' >90% of the mobile market. This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware, because its hardware was work station hardware. Which had to compete with Silicon Graphics, IBM, Apple, Next, etc.
      - AnthonyMouse 12y ago
        > This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware There is also the fact that Sun didn't prohibit other operating system or application vendors from making operating systems or applications for its hardware by locking the boot loader.
        coldtea 12y ago
        No, that didn't come into play at all. Sun could have locked it whichever way they wanted, and still they wouldn't get involved in such litigation.
- frik 12y ago
  The Windows system control, Explorer UI, Internet Explorer UI, Office UI all use undocumented APIs since Win98/2k and Office 95. It's called Windows "DirectUser" UI and it's in violation of the antitrust settlement. sources: * http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/529525.aspx#531565 http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/52952... * http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/6b801577-1699-4093-8a58-198c64b120e0/directuser-api-documentation?forum=windowsuidevelopment http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US... Internet Explorer's use of DUSER.DLL is only temporary. The final version of Internet Explorer will not use it. -- Raymond Chen [author of "The Old New Thing"] * yet, IE 7+ uses DirectUser UI: http://blogs.msdn.com/b/ie/archive/2006/02/01/a-new-look-for-ie.aspx#522924 http://blogs.msdn.com/b/ie/archive/2006/02/01/a-new-look-for...
fab13n 12y ago
> [it's reasonable not to commit to long-term API support lightly] Another dimension, which I think primes here, is potential for abuse: things either likely to be used for scammy features, or leading to 99% of results in very poor tastes (think of those as the descendants of the <blink> tag from the 90's). It's simpler and creates less outrage to block those APIs than to reject most of the applications misusing them. I think that's one of the reasons why they disallowed compatibility layers: it would have encouraged poor UX as, by definition, they only offer the common denominator of all the targeted platforms (I'm not naive about other motives, but they're off-topic). What Apple sales is great user experience. App developers are only welcome as long as they're improving that experience. They're currently useful to Apple as a whole, but they aren't Apple's customers. And of course Apple trusts itself to respect its own sense of taste, so doesn't need any self-limitation. They're your host in their personal walled garden, they can't even imagine that you'd ask to "compete with them on equal grounds". As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. They're intended for serious alerts requiring immediate action from the user, and they're often used as a substitute for a usable notification UI.
- madeofpalk 12y ago
  > As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. This is for a popover like this http://i.imgur.com/ItDZQRL.png http://i.imgur.com/ItDZQRL.png Not a popup like this (known as an alert in iOS) http://i.imgur.com/3U2Tq2e.png http://i.imgur.com/3U2Tq2e.png
jamra 12y ago
The situation you're describing is not the same situation as described in the article. This API is not private. It's a public API for the iPad. There is a check that detects if you are running an iPad or iPhone. If you are running an iPhone, your program will crash.... unless it is one of the internal apple apps. Nothing here is private.
- matthewmacleod 12y ago
  I think you've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.
  - jamra 12y ago
    The API is available. It compiles just fine. It just throws an exception when you try to initialize. There is no reason for this other than UI opinions. It clearly runs fine since Apple is using it. Since this is a simple control, there are no use cases that Apple is somehow snuffing through their use. It is not difficult at all in iOS 7 to create a modal popup on an iPhone. I don't think it would be too difficult to create a UIPopoverController clone either. I'm pretty sure it's just a case of getting the sender's frame relative to its parent's view for the arrow part of it (although I agree with Apple's UI opinion here). Circumventing the restriction has nothing to do with private APIs. Apple added a hard-coded check on the bundle identifier. That is not a private API. As a matter of fact, nothing here is private. I don't believe you can circumvent this restriction either because there is a private variable that is a part of the UIPopoverController class. Note that the private variable is not a private API.
    - overgryphon 12y ago
      "It clearly runs fine since Apple is using it." This doesn't mean it runs fine, it means that in the particular cases that Apple uses the API for it runs fine. Apple may not have tested the API sufficiently for broader usage, or made special cases in the API to support their specific internal usage. Public usage of the API on iPhones may result in concerns about security, stability, or it may simply not behave on iPhones the way most developers would expect it to, and Apple doesn't want to create an API that will result in a lot of application bugs they can't fix themselves. No one outside of Apple knows exactly why this API is only supported publicly on iPads and not iPhones. Concluding the reason isn't valid is premature.
danford 12y ago
>You've got to support the API forever Not really. Many APIs have features that are put in and removed all the time. The key to managing this is having a good API that tags features as things like 'experimental', 'deprecated', 'locked', etc to indicate if features are permanent or could be changing. Stability: 0 - Deprecated This feature is known to be problematic, and changes are planned. Do not rely on it. Use of the feature may cause warnings. Backwards compatibility should not be expected. Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team. Stability: 2 - Unstable The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable. Backwards-compatibility will be maintained if reasonable. Stability: 3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes. Backwards-compatibility is guaranteed. Stability: 4 - API Frozen This API has been tested extensively in production and is unlikely to ever have to change. Stability: 5 - Locked Unless serious bugs are found, this code will not ever change. Please do not suggest changes in this area; they will be refused.
- taumhn 12y ago
  I'm actually rather happy with the Apple philosophy of not opening APIs early and supporting them as long as possible when they've been made public, rather than having to check my app against 6 levels of API stability... thank you very much.
  - danford 12y ago
    But you don't have to check your app against 6 levels, just use features in level 5. It's like apples API, but with benefits.
danudey 12y ago
> You've got to support the API forever, and future design directions are constrained. Actually, I think part of the reason for Apple's reluctance is that they don't do this; they'll gladly deprecate APIs and remove them in future versions, but that's about as bad because now you're breaking apps (which admittedly are unable or unwilling to update). This is especially a problem in corporate environments with custom iPad apps; if the customer doesn't want to pay the developer to update for newer iOS versions, then they basically can't buy new devices once the API is removed, because their app won't work. This is why Microsoft keeps APIs around forever, and why businesses keep running XP until ten years has gone by and they start getting hammered with 0-days.
keeperofdakeys 12y ago
If taken too far, this can lead to two-tiers of applications, which can be incredibly bad for the eco-system. On early Windows Phone 7, Nokia used an entirely different api to other apps, that gave much more freedom. So Nokia apps both allowed custom styles, and were much faster. This meant no apps on the store could really compete with the system apps. I'm unsure if this changed with Windows Phone 8, though I'm sure it would have.
- ctdonath 12y ago
  There's a difference between private APIs which are convenient for Apple to use and inconvenient for Apple to let others use but developers can create alternatives without much difficulty, vs private APIs which give Apple an outright unfair advantage over others. Are there any private APIs which really do amount to "unfair advantage for Apple"? or does the whole issue amount to sniveling about not being able to play with all their toys and having to bring your own?
mikeash 12y ago
It would be one thing if this was just built-in apps that need special capabilities. It's reasonable for, say, Settings to use private APIs, because it's special. (I don't agree with that, and would like third-party apps to be allowed to change that stuff too, but I don't think it's an unreasonable stance.) However, this is iBooks, which you get from the App Store just like all third-party apps. It's explicitly competing with products from third-party developers. In this area, there should be a level playing field. When us third-party developers distribute on the App Store, we have to agree to a contract that, among other things, states that our apps will not use private APIs. Why do Apple's apps, when distributed through the App Store, not follow the same rules? Why should they get special treatment for apps that aren't built in to the OS and which are distributed using the same channels the rest of us use? This popover example is fairly trivial, since nothing stops you from building your own version of it and shipping it in your app, but it illustrates the point. A more significant example is the screen brightness control. iBooks has a slider that you can use to adjust the brightness of the screen. This brightness adjustment uses private API, and because of that, other eBook readers cannot replicate that feature. There is no technical reason third-party apps couldn't do this (they have the same access to the device that iBooks does) but Apple doesn't allow it. The Kindle app, for example, has a brightness slider too. Except it doesn't adjust the screen brightness. It just adjusts the gray level of the white background, while leaving the backlight at original strength. This means that you lose contrast and use more battery power, meaning that the Kindle app is inherently worse because Apple isn't playing fair. This is less important these days, now that Control Center lets you easily access the device brightness from anywhere. It was a big hit against Kindle's usability for years, though.

by dilap 12y ago

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.
  - celticninja 12y ago
    You are fundamentally misunderstanding a monopoly position.
    - jacquesm 12y ago
      And you are fundamentally misunderstanding that anti-trust law is about more than just monopolies.
      - cynicalkane 12y ago
        Except you're not an antitrust law expert, you're a Random Guy On The Internet making up handwavey arguments that would never fly in court. Under this principle, you could say Nintendo has a monopoly on Nintendos and must therefore open secret APIs to developers, or that whatever cable box company has a monopoly on their particular brand of cable boxes, &c. Courts reject principles that lead to absurdity under simple substitutions. I don't know what your comment about "anti-trust law being about more than monopolies" is supposed to mean. It says nothing, and furthermore says nothing with an authority to which you are not entitled, being not an antitrust law expert. So your unsupported and unreasonable claims should be discounted accordingly.
        jacquesm 12y ago
        If the only people allowed to talk about anything are experts then we might as well shut down every forum on the internet including this one. But have a read on the various pages written by experts and come up with arguments against what I said instead of just trying to attack my credibility.
        cynicalkane 12y ago
        No, the point is you have no argument in addition to no authority. It's normal to require one or the other.
        12y ago
- room271 12y ago
  In the vast chasm between pure monopoly (one supplier) and the perfectly competitive market (which is imaginary), is large room for firms which have competition but are still big enough to abuse their market position. It's not useful to focus only on pure monopoly. From an economics perspective, there are plenty of other market structures which can be damaging for consumers.
  - endersshadow 12y ago
    It's not just the person you're responding to--the FTC looks only at relatively pure monopolies for anti-trust violations. There are lots of things that are legal as a player in a competitive market versus illegal as a monopoly. The US has a long history with pure monopolies, which are why the laws are the way they are. You can argue until you're blue in the face that the FTC should look at other things, as well, but I'm not sure you'll get very far.
    - scott00 12y ago
      The SEC has nothing to do with enforcement of antitrust law. The Federal Trade Commission and the Department of Justice share that responsibility.
      - endersshadow 12y ago
        You're right, I'm sorry--it was early and I got my initialisms wrong. Thank you for the correction--I'll correct my post.
  - GrinningFool 12y ago
    But from a legal perspective [IANAL, but I'm pretty confident on this one], they can engineer the system to give them an advantage as long as they don't have an monopoly. When a company is a monopoly, new rules do apply.
    - gnopgnip 12y ago
      Anti competitive practices are illegal, not monopolies.
dilap 12y ago
Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.
- reidrac 12y ago
  If Apple is a abusing his position as OS provider by using in their apps APIs that are not available to other app developers, I'm not sure if the right answer is "go and develop for Android instead". What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did.
  - seszett 12y ago
    > What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did. They sometimes do, though, with Maps for example. ... and Maps is precisely one of the apps that use private APIs.
  - Consultant32452 12y ago
    I haven't checked into it lately but Apple certainly used to ban any competing apps from its app store. So if you had an iTunes competitor, you weren't going to get it released for iOS. http://www.cnet.com/news/apple-blocks-competitive-products-from-iphone-app-store-surprised/ http://www.cnet.com/news/apple-blocks-competitive-products-f...
- loup-vaillant 12y ago
  It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.
  - al2o3cr 12y ago
    "local monopoly": meaningless. That's like saying that Gmail has a "local monopoly" on web-based email because switching would be a hassle.
greedy_buffer 12y ago
Does this apply to the same extent to phones as it does to an operating system? Apple has made devices that don't even have an app store - nobody cries foul that the Nokia 1100 only runs Nokia software.
icantthinkofone 12y ago
The difference may be that Microsoft used the private APIs to give itself (and select partners) advantages over competitors while being a monopoly. I don't know if Apple is using those APIs to give themselves an advantage over competitors but they certainly are not a monopoly as Microsoft is.
- jacquesm 12y ago
  As microsoft was. At this point in time I don't think that anybody would be able to present an argument to the effect that Microsoft is the dominant player in consumer or business computing. The number of devices not running a Microsoft OS is significant.
  - icantthinkofone 12y ago
    At the time, there was only the desktop market and no mobile to speak of. Microsoft still dominates the desktop but how that figures into a monopoly calculation, I'm not sure.
  - dTal 12y ago
    Devices, sure. But computing? Some perspective: You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only). Businesses universally use PowerPoint, Excel, and Word. If you work in industry or manufacturing, you may have noticed that the drivers for specialist equipment are always for Windows. "Industry Standard" software like 3ds Max only runs on Windows. Government still overwhelmingly uses Windows, which is why it's still "news" when somewhere switches to Linux (usually Berlin again). Healthcare uses Windows. In the consumer OS space, nobody is even trying to compete with them commercially. The worst they have to worry about there is poor publicity from a lemon version of Windows, because no matter how crap it is all new computers will still ship with it. Seems to me Microsoft is still dominant.
    - dragonwriter 12y ago
      > You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only). Or ChromeOS. Or more traditional Linux (a number of vendors sell them). Last I checked (though I haven't for a while) you could even get OS-free laptops on NewEgg.
coldtea 12y ago
Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party. Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here. But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.
- logfromblammo 12y ago
  It could be replicated by a third party, but thanks to Apple policy, using such a third-party component could be grounds for removal from the Apple App Store. What Apple can do and what it should do are not necessarily the same things. While it can establish privileged APIs, it should not. While it can attempt to support outside developers as a hardware company while also competing with them as a software company, it should not. If it is easily demonstrated for this particular API, it may be present and less obvious elsewhere, including a serious API. The only way to know for sure is to inspect the code.
  - Moto7451 12y ago
    Nonsense. I'm using WYPopoverController[1] in some of my apps and they're a-ok. On the component's page they even have links to apps in the App Store that use it[2]. [1] https://www.cocoacontrols.com/controls/wypopovercontroller https://www.cocoacontrols.com/controls/wypopovercontroller [2] https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=4 https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=...
    - kbenson 12y ago
      Whether they have removed apps that use is irrelevant. That they can at any point remove them because of their policies but don't should not be lauded, it just creates an air of confusion that they can use to their benefit as they see fit.
      - logfromblammo 12y ago
GrinningFool 12y ago
Those rules apply in a monopoly - when a business is not a monopoly it has considerably more freedom.
- rando289 12y ago
  Apple has a monopoly on operating systems which work on apple hardware.
  - andor436 12y ago
    Hello from Windows on a MacBook!
  - valarauca1 12y ago
    I don't think your understanding how a Monopoly applied in the situation with Microsoft. Microsoft's Anti-trust suite was because of its web browser's dominance, IE was during the anti-trust suite upwards of 95% of all browsers on the Internet, this was because of bundling and defaults. While other OS's may not execute on Apple's own hardware, other hardware exists (other smart phones) that directly compete with Apple. And by compete I mean neither Apple nor Andriod nor WindowsPhone 'owns' >90% of the mobile market. This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware, because its hardware was work station hardware. Which had to compete with Silicon Graphics, IBM, Apple, Next, etc.
    - AnthonyMouse 12y ago
      > This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware There is also the fact that Sun didn't prohibit other operating system or application vendors from making operating systems or applications for its hardware by locking the boot loader.
      - coldtea 12y ago
        No, that didn't come into play at all. Sun could have locked it whichever way they wanted, and still they wouldn't get involved in such litigation.
frik 12y ago
The Windows system control, Explorer UI, Internet Explorer UI, Office UI all use undocumented APIs since Win98/2k and Office 95. It's called Windows "DirectUser" UI and it's in violation of the antitrust settlement. sources: * http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/529525.aspx#531565 http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/52952... * http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/6b801577-1699-4093-8a58-198c64b120e0/directuser-api-documentation?forum=windowsuidevelopment http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US... Internet Explorer's use of DUSER.DLL is only temporary. The final version of Internet Explorer will not use it. -- Raymond Chen [author of "The Old New Thing"] * yet, IE 7+ uses DirectUser UI: http://blogs.msdn.com/b/ie/archive/2006/02/01/a-new-look-for-ie.aspx#522924 http://blogs.msdn.com/b/ie/archive/2006/02/01/a-new-look-for...

fab13n 12y ago

> [it's reasonable not to commit to long-term API support lightly] Another dimension, which I think primes here, is potential for abuse: things either likely to be used for scammy features, or leading to 99% of results in very poor tastes (think of those as the descendants of the <blink> tag from the 90's). It's simpler and creates less outrage to block those APIs than to reject most of the applications misusing them. I think that's one of the reasons why they disallowed compatibility layers: it would have encouraged poor UX as, by definition, they only offer the common denominator of all the targeted platforms (I'm not naive about other motives, but they're off-topic). What Apple sales is great user experience. App developers are only welcome as long as they're improving that experience. They're currently useful to Apple as a whole, but they aren't Apple's customers. And of course Apple trusts itself to respect its own sense of taste, so doesn't need any self-limitation. They're your host in their personal walled garden, they can't even imagine that you'd ask to "compete with them on equal grounds". As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. They're intended for serious alerts requiring immediate action from the user, and they're often used as a substitute for a usable notification UI.

madeofpalk 12y ago
> As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. This is for a popover like this http://i.imgur.com/ItDZQRL.png http://i.imgur.com/ItDZQRL.png Not a popup like this (known as an alert in iOS) http://i.imgur.com/3U2Tq2e.png http://i.imgur.com/3U2Tq2e.png

jamra 12y ago

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

matthewmacleod 12y ago
I think you've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.
- jamra 12y ago
  The API is available. It compiles just fine. It just throws an exception when you try to initialize. There is no reason for this other than UI opinions. It clearly runs fine since Apple is using it. Since this is a simple control, there are no use cases that Apple is somehow snuffing through their use. It is not difficult at all in iOS 7 to create a modal popup on an iPhone. I don't think it would be too difficult to create a UIPopoverController clone either. I'm pretty sure it's just a case of getting the sender's frame relative to its parent's view for the arrow part of it (although I agree with Apple's UI opinion here). Circumventing the restriction has nothing to do with private APIs. Apple added a hard-coded check on the bundle identifier. That is not a private API. As a matter of fact, nothing here is private. I don't believe you can circumvent this restriction either because there is a private variable that is a part of the UIPopoverController class. Note that the private variable is not a private API.
  - overgryphon 12y ago
    "It clearly runs fine since Apple is using it." This doesn't mean it runs fine, it means that in the particular cases that Apple uses the API for it runs fine. Apple may not have tested the API sufficiently for broader usage, or made special cases in the API to support their specific internal usage. Public usage of the API on iPhones may result in concerns about security, stability, or it may simply not behave on iPhones the way most developers would expect it to, and Apple doesn't want to create an API that will result in a lot of application bugs they can't fix themselves. No one outside of Apple knows exactly why this API is only supported publicly on iPads and not iPhones. Concluding the reason isn't valid is premature.

danford 12y ago

>You've got to support the API forever Not really. Many APIs have features that are put in and removed all the time. The key to managing this is having a good API that tags features as things like 'experimental', 'deprecated', 'locked', etc to indicate if features are permanent or could be changing. Stability: 0 - Deprecated This feature is known to be problematic, and changes are planned. Do not rely on it. Use of the feature may cause warnings. Backwards compatibility should not be expected. Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team. Stability: 2 - Unstable The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable. Backwards-compatibility will be maintained if reasonable. Stability: 3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes. Backwards-compatibility is guaranteed. Stability: 4 - API Frozen This API has been tested extensively in production and is unlikely to ever have to change. Stability: 5 - Locked Unless serious bugs are found, this code will not ever change. Please do not suggest changes in this area; they will be refused.

taumhn 12y ago
I'm actually rather happy with the Apple philosophy of not opening APIs early and supporting them as long as possible when they've been made public, rather than having to check my app against 6 levels of API stability... thank you very much.
- danford 12y ago
  But you don't have to check your app against 6 levels, just use features in level 5. It's like apples API, but with benefits.

danudey 12y ago

> You've got to support the API forever, and future design directions are constrained. Actually, I think part of the reason for Apple's reluctance is that they don't do this; they'll gladly deprecate APIs and remove them in future versions, but that's about as bad because now you're breaking apps (which admittedly are unable or unwilling to update). This is especially a problem in corporate environments with custom iPad apps; if the customer doesn't want to pay the developer to update for newer iOS versions, then they basically can't buy new devices once the API is removed, because their app won't work. This is why Microsoft keeps APIs around forever, and why businesses keep running XP until ten years has gone by and they start getting hammered with 0-days.

keeperofdakeys 12y ago

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

ctdonath 12y ago
There's a difference between private APIs which are convenient for Apple to use and inconvenient for Apple to let others use but developers can create alternatives without much difficulty, vs private APIs which give Apple an outright unfair advantage over others. Are there any private APIs which really do amount to "unfair advantage for Apple"? or does the whole issue amount to sniveling about not being able to play with all their toys and having to bring your own?

mikeash 12y ago

It would be one thing if this was just built-in apps that need special capabilities. It's reasonable for, say, Settings to use private APIs, because it's special. (I don't agree with that, and would like third-party apps to be allowed to change that stuff too, but I don't think it's an unreasonable stance.) However, this is iBooks, which you get from the App Store just like all third-party apps. It's explicitly competing with products from third-party developers. In this area, there should be a level playing field. When us third-party developers distribute on the App Store, we have to agree to a contract that, among other things, states that our apps will not use private APIs. Why do Apple's apps, when distributed through the App Store, not follow the same rules? Why should they get special treatment for apps that aren't built in to the OS and which are distributed using the same channels the rest of us use? This popover example is fairly trivial, since nothing stops you from building your own version of it and shipping it in your app, but it illustrates the point. A more significant example is the screen brightness control. iBooks has a slider that you can use to adjust the brightness of the screen. This brightness adjustment uses private API, and because of that, other eBook readers cannot replicate that feature. There is no technical reason third-party apps couldn't do this (they have the same access to the device that iBooks does) but Apple doesn't allow it. The Kindle app, for example, has a brightness slider too. Except it doesn't adjust the screen brightness. It just adjusts the gray level of the white background, while leaving the backlight at original strength. This means that you lose contrast and use more battery power, meaning that the Kindle app is inherently worse because Apple isn't playing fair. This is less important these days, now that Control Center lets you easily access the device brightness from anywhere. It was a big hit against Kindle's usability for years, though.