Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple Cheats

marksands.github.io

Post reply on HN
Print view View original

21–30 of 235 posts

Re: How Apple Cheats

#21

Post by callumjones »

andyjohnson0 wrote: post #20
callumjones wrote: post #15

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 doub…

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?

Yep I know, you could consider these production apps as beta tests of the API.

If they mess up the API calls, they can sidetrack the review process and deliver a swift update.

Re: How Apple Cheats

#22

Post by matthewmacleod »

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…

Re: How Apple Cheats

#23

Post by matthewmacleod »

andyjohnson0 wrote: post #20
callumjones wrote: post #15

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 doub…

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?

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

Re: How Apple Cheats

#24

Post by xuki »

andyjohnson0 wrote: post #7
xuki wrote: post #5

Earlier quoted context omitted.

Only if you let them find out ;).

How would you prevent them from finding out?

https://speakerdeck.com/steipete/taking-advantage-of-the-run... - see 2nd line

Peter Steinberger (https://twitter.com/steipete) shipped this in his PSPDFKit, which is used for Box/Dropbox/Evernote.

Re: How Apple Cheats

#26

Post by matthewmacleod »

probably_wrong wrote: post #8
siphr wrote: post #4

I am surprised that this is so shocking to the author. Stuff like this is expected and only logical, as wrong as it may be. Apple has been desperately trying to tie people into their eco-system and every move the company makes is a step in that direction whether it may be immediately obvious to other people or not. Also I should mention that I believe Apple is probably not the only company that promotes the use of it…

As someone who is not an iDeveloper and has no idea what the UIPopoverController does: couldn't you make a case that Apple is deliberately crippling the competition and, therefore, make a case for abuse of a dominant position? If it were so it then it wouldn't be about being shocking, expected or logical, but about being against the law.

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

Re: How Apple Cheats

#27

Post by dilap »

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

Re: How Apple Cheats

#28

Post by rjknight »

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.

Re: How Apple Cheats

#29

Post by DanBC »

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?

Re: How Apple Cheats

#30

Post by whyleym »

It's understandable that Apple locks down private API's, however given that developed these often they move from the private state (beta testing for their own apps?) to public and available for developers to develop against once they are happy with them.
Post reply on HN