Why is UIPopoverController not a UIViewController subclass?

Question

Can you think of particular reasons why Apple chose to implement UIPopoverController as a plain NSObject subclass? To me, a UIViewController subclass would make much more sense, to implement proper UIViewController containment.

But perhaps there are reasons I didn't think of, why Apple's bright engineers made their choice?

Answer 1

I assume it's because, like UIAlertView, it's presented in a new UIWindow so that's windowLevel property guarantees that it's presented over all content.

Whether or not it's in a new UIWindow, as far as view controller containment is concerned, you should have no problem using complex parent-child view controller container hierarchies in the view controllers you present in a UIPopoverController. I have view controllers with at least three levels of nesting in Pillboxie for some of the popovers, without any problems.

UPDATE: I've checked the hierarchy by logging the classes of the first three levels of the view hierarchy in a sample project, and it is as follows when a popover is visible (my root view controller had two UIButtons):

A WINDOW:

_SUBVIEW CLASS: UIView

___SUBSUBVIEW CLASS: UIRoundedRectButton

__SUBSUBSUBVIEW CLASS: UIButtonLabel

___SUBSUBVIEW CLASS: UIRoundedRectButton

__SUBSUBSUBVIEW CLASS: UIButtonLabel

_SUBVIEW CLASS: UIDimmingView

___SUBSUBVIEW CLASS: _UIPopoverView

__SUBSUBSUBVIEW CLASS: _UIPopoverStandardChromeView

__SUBSUBSUBVIEW CLASS: UIView

Apple's documentation states that the root view controller's view in a UIWindow should have no sibling views managed by other view controllers, because those sibling view controllers will not receive rotation events (see here, second bullet).

So, if Apple had made UIPopoverController a UIViewController subclass, it would have to add it as a child/subview of the rootViewController's hierarchy. But what if the root view controller (which is your code, anyway) decides to present a view that interferes with the hierarchy of the UIPopoverController's view? Rather than let us bungle it up, it seems that Apple decided to manage the presentation of the UIPopoverController completely, but in such a way that they did not have to grant themselves an exception to the no-sibling-view-controllers policy of UIWindow.