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

This class only has one function. It pops up. That's all. There is a UIView that shows content. It literally only has one job.

The environment that runs the iPad and the iPhone is the same. You can run the same exact code on either device. The UI code between devices are equivalent. They have the same class hierarchies. UIPopoverViewController is an NSObject. It has one function that the writer of this article proved can be run just fine on an iPhone by reversing the code.

It uses CGRects to lay itself out. This is prevalent in one of the delegate callbacks.

It uses the UIPopoverControllerDelegate in order to send the calling class callbacks relative to certain events. That is standard code on iOS both for iPads and iPhones. When creating a universal app, I have never had to change how I use delegates between the iPad and the iPhone.

This is because they both run objective C with the same SDK. When compiling the iPad version of your XCode project, you may have to change your build target, which is indicative of differences in the environment (perhaps only the CPU architecture). You do not, however, change an SDK. The classes you import are identical.

I believe Apple's reasoning is entirely valid. Popovers look terrible on small devices. That is what the Apple guidelines state. I like that they are very opinionated with their design guidelines. There are still a very many ways of doing things and staying inside those guidelines.

Edit: I believe that the presence of the UIPopoverController while building an iOS app is proof enough that the SDKs are identical.

And yet, there is something Apple knows about it, which you don't, that leads Apple to prevent general use thereof. They are in a position to abruptly change how it's used in their own software, but are not in a position to make you abruptly change how you use it; not letting you use it is fair in this situation.

Since there is one init function, any changes to the SDK will cascade outwards automatically.

I think that you are trying to make some sort of theoretical point about theoretical issues with the SDK. Do you program on iOS devices?

There is a reason why they do not want users to use this on an iPhone. It is the same reason why they do not want users to use a numeric-only keyboard on the iPad. It is because it does not look nice. Launching a popover from the bottom half of an iPhone doesn't look quite right. That is all. There are no API problems. A popover is just a view that appears in dynamic locations on the device. When programming something like that in objective-c, you use CGRect to provide an x, y, width, and height. I don't know why people keep trying to argue these theoretical points without understanding the simplicity of the control.