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β¦
> Apple haven't done the necessary amount of work to ensure that the UIPopoverController on an iPhone is stable, API-compliant, and well-tested.
And, to add to what you're saying, maybe this is how they're testing it, by using it in their own widely used apps.
I agree with the "nothing to see here" crowd, if I wanted the feature I'd develop it myself in this case. Doesn't seem like it would be that bad. Microsoft has always had their own controls too that they never exposed to the world leaving it up to applications developers to replicate if they wanted the functionality.
What I find confusing is why the API would be acceptable on an iPad and not on an iPhone. It seems unlikely that Apple would be willing to devote the resources to testing the element on one and not the other, or that the software behind the two implementations is different enough that testing would not carry between the two. And, if that were the case, surely it would have been easier to just not release the API at all?
Rather, it sounds like someone at Apple decided that popover widgets provide a poor user experience in small form factors unless they are carefully designed, so they disabled the API on the iPhone to discourage careless use. Obviously, the same restriction would not apply to Apple... which is unfair but understandable, given that "We know design better than you" is basically Apple's value proposition.
"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."
I was with you until here. I'd much rather just use the same 1st party component on a universal app, rather than a 2nd or 3rd party approximation.
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β¦