¿Por qué UIPopoverController no es una subclass UIViewController?

¿Puedes pensar en razones particulares por las que Apple decidió implementar UIPopoverController como una subclass simple de NSObject? Para mí, una subclass UIViewController tendría mucho más sentido, para implementar la contención adecuada de UIViewController.

Pero tal vez hay razones por las que no pensé, ¿por qué los shinys ingenieros de Apple tomaron su decisión?

Supongo que es porque, como UIAlertView, se presenta en una nueva UIWindow, por lo que la propiedad windowLevel garantiza que se presenta a través de todo el contenido.

Ya sea que esté o no en una nueva UIWindow, en lo que respecta a la contención del controller de vista, no debería tener problemas para usar jerarquías complejas de contenedor de controller primario-secundario en los controlleres de vista que presente en UIPopoverController. Tengo controlleres de vista con al less tres niveles de anidamiento en Pillboxie para algunos de los popovers, sin ningún problema.

ACTUALIZACIÓN: He verificado la jerarquía al registrar las classs de los tres primeros niveles de la jerarquía de vistas en un proyecto de ejemplo, y es como sigue cuando un popover está visible (mi controller de vista raíz tenía dos botones UIB):

UNA VENTANA:

_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

La documentation de Apple establece que la vista del controller de la vista raíz en una UIWindow no debe tener vistas hermanas administradas por otros controlleres de vista, ya que esos controles de la vista de hermanos no recibirán events de rotation (ver aquí , segunda viñeta).

Por lo tanto, si Apple hubiera convertido a UIPopoverController en una subclass UIViewController, tendría que agregarlo como un secundario / subview de la jerarquía de rootViewController. Pero, ¿qué pasa si el controller de vista raíz (que es su código, de todos modos) decide presentar una vista que interfiera con la jerarquía de la vista del UIPopoverController? En lugar de dejarnos desorientar, parece que Apple decidió gestionar la presentación del UIPopoverController por completo, pero de tal forma que no tuvieron que otorgarse una exception a la política de los controlleres de vista-sin-hermano-de-UIWindow.

debido a que los objects UIPopoverController no interactúan con el usuario, es por eso que no forma parte de la capa View , su UIViewController puede comunicarse con el usuario, UIPopoverController no realiza trabajos similares dentro de sí mismo.

Eche un vistazo rápido a la definición genérica del Controlador :

Un controller puede enviar commands a su vista asociada para cambiar la presentación de la vista del model (por ejemplo, desplazándose por un documento). Puede enviar commands al model para actualizar el estado del model (por ejemplo, editar un documento).

explica por qué no forma parte de la capa de vista , espero que sea de ayuda.