41–50 of 235 posts
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?
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 A…
When Microsoft did the same thing in Windows it was grounds for anti-trust lawsuits to be brought against them: http://www.pcpro.co.uk/news/101947/microsoft-used-undocument... The idea here is that if you are supplying both the operating system and the applications that your applications should not benefit from being made by the same company as the OS, in other words, that it should be a level playing ground without…
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.
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 A…
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 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.
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…
Earlier quoted context omitted.
When Microsoft did the same thing in Windows it was grounds for anti-trust lawsuits to be brought against them: http://www.pcpro.co.uk/news/101947/microsoft-used-undocument... The idea here is that if you are supplying both the operating system and the applications that your applications should not benefit from being made by the same company as the OS, in other words, that it should be a level playing ground without…
Microsoft had a monopoly position at that time, and Apple does not.
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.
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…
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
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 A…
> [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 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 thin…
This is for a popover like this http://i.imgur.com/ItDZQRL.png
Not a popup like this (known as an alert in iOS) http://i.imgur.com/3U2Tq2e.png
