ios - apple - Cuándo usar Storyboard y cuándo usar XIBs

main storyboard xcode (9)

¿Existen pautas sobre cuándo usar guiones gráficos en un proyecto de iOS y cuándo usar XIB? ¿Cuáles son los pros y los contras de cada uno y qué situaciones se adaptan a cada uno?

Por lo que puedo decir, no es tan sencillo utilizar los guiones del guión gráfico cuando tienes controles de vista impulsados por elementos dinámicos de la IU (como los pines del mapa).

He estado trabajando en un proyecto de tamaño razonable (> 20 escenas en el lenguaje del guión gráfico), me he topado con muchas limitaciones y tengo que recurrir repetidamente a la documentación y las búsquedas de Google para hacer cosas.

La interfaz de usuario está todo en un archivo. Incluso si crea múltiples guiones gráficos, todavía tiene muchas escenas / pantallas en cada guión gráfico. Este es un problema en equipos medianos y grandes.
En segundo lugar, no juegan bien con los controladores de contenedores personalizados que incorporan otros controladores de contenedores, etc. Estamos usando MFSlideMenu en una aplicación de fichas y la escena tiene una tabla. Esto es casi imposible de hacer con un guión gráfico. Habiendo pasado días, he recurrido a hacer la forma XIB donde hay un control completo.
El IDE no permite seleccionar controles en el estado de alejamiento. Por lo tanto, en un proyecto grande, el zoom-out es principalmente para obtener una vista de alto nivel y nada más.

Usaría guiones gráficos para aplicaciones más pequeñas con equipos de tamaño pequeño y utilizaría el enfoque XIB para equipos / proyectos medianos y grandes.

He usado XIB extensivamente y he completado dos proyectos usando Storyboards. Mis aprendizajes son:

Los guiones gráficos son agradables para aplicaciones con un número pequeño a medio de pantallas y una navegación relativamente sencilla entre las vistas.
Si tienes muchas vistas y mucha navegación cruzada entre ellas, la vista del Guión gráfico se vuelve confusa y mucho trabajo para mantenerte limpio.
Para un proyecto grande con múltiples desarrolladores, no usaría Storyboards porque tiene un solo archivo para su UI y no puede trabajar en paralelo fácilmente.
Podría valer la pena que las aplicaciones grandes se dividan en varios archivos de guión gráfico, pero no lo he intentado. Esta respuesta muestra cómo hacer segues entre storyboards.
Aún necesita XIB: en mis dos proyectos de Storyboard tuve que usar XIB para celdas de tabla personalizadas.

Creo que los Storyboards son un paso en la dirección correcta para la implementación de la interfaz de usuario y espero que Apple los amplíe en futuras versiones de iOS. Sin embargo, deben resolver el problema del "archivo único", de lo contrario no serán atractivos para proyectos más grandes.

Si comienzo una aplicación de tamaño pequeño y puedo permitirme la compatibilidad solo con iOS5, usaría Storyboards. Para todos los demás casos me quedo con XIBs.

Los storyboards se crearon para ayudar a los desarrolladores a visualizar su aplicación y el flujo de la aplicación. Es muy parecido a tener un montón de xib pero en un solo archivo.

Hay una pregunta similar a esta ubicada ¿Cuál es la diferencia entre un archivo .xib y un .storyboard? .

También puede crear transiciones personalizadas a través de un código que cambiará dinámicamente si es necesario, como lo hace con .xibs.

PROS:

Puedes simular el flujo de una aplicación sin escribir mucho, si es que hay algún código.
Mucho más fácil ver sus transiciones entre pantallas y el flujo de su aplicación.
También puede usar .xibs si es necesario con guiones gráficos.

CONTRAS:

Solo funciona con iOS 5+. No funciona con iOS4.
Se puede saturar fácilmente si tiene una aplicación muy intensiva de visualización.

Realmente no hay un correcto / incorrecto cuando usar uno u otro, es solo una cuestión de preferencia y qué versiones de iOS desea utilizar.

No creo que haya una respuesta correcta para tu pregunta, es solo una cuestión de experiencia personal y con la que te sientas más cómodo.

En mi opinión, los guiones gráficos son una gran cosa. Es cierto, es muy difícil descubrir por qué su aplicación se bloquea misteriosamente en el tiempo de ejecución, pero después de un tiempo y experiencia, se dará cuenta de que siempre está relacionado con la falta de algún IBOutlet en algún lugar y podrá corregirlo fácilmente.

El único problema real es trabajar en equipo bajo el control de versiones con guiones gráficos, en las primeras etapas de desarrollo podría ser un verdadero desastre. Pero después de esa primera etapa, las actualizaciones de la interfaz de usuario que cambian por completo el guión gráfico son muy raras, y en la mayoría de los casos terminas con conflictos en las últimas partes del xml, que son referencias seguras que generalmente se reparan automáticamente cuando vuelves a abrir el guión gráfico . En nuestro trabajo de equipo, preferimos tratar esto con los controladores de vista pesados con toneladas de código de vista.

He leído muchos comentarios contra el diseño automático. Con XCode5 se mejoró realmente, es realmente bueno incluso para diseños automáticos. En algún caso, tendrá que hacer algo en el código, pero puede simplemente eliminar la restricción que necesita editar y, en ese momento, hacer lo que necesite en su código. Incluso animarlos.

También creo que la mayoría de las personas a quienes no les gustan los guiones gráficos no intentaron comprender completamente el poder de un segmento manual personalizado, donde puede personalizar totalmente (en un solo archivo) la forma en que realiza la transición de un camino a otro y también (con algunos trucos) incluso reutilizar un controlador de vista previamente cargado simplemente actualizando el contenido de su vista en lugar de volver a cargarlo por completo. Al final, realmente puedes hacer las mismas cosas que en el código, pero creo que tienes una mejor separación de inquietudes con los guiones gráficos, pero estoy de acuerdo en que en muchas cosas carecen de características (fuentes, imagen como fondo de color, ecc ... ).

No estoy usando StoryBoard o XIBs en ninguna de las aplicaciones ... sino que estoy creando todo programáticamente.

∆ Beneficios:

√ Puedes crear cualquier tipo complejo de interfaz de usuario o animaciones de transición para UIView .

√ Soporta todas las versiones de iOS. No hay que preocuparse por <iOS 5.

√ * Su aplicación admitiría todos los dispositivos iPhone / iPod / iPad dentro de su código.

√ Siempre estás actualizado, ya que sabes el código que siempre funcionará.

√ * Funcionará en cualquier (nuevo) dispositivo lanzado - No es necesario cambiar el código.

√ Todo depende de ti. En cierto lugar, desea cambiar algo: no es necesario mirar el guión gráfico o xib. Solo búscalo en clase particular.

√ Por último, pero no en la lista: nunca olvidará eso, cómo gestionar todo mediante programación. Esto es lo mejor, ya que conoces un control muy profundo que nadie.

_{Nunca he encontrado un problema al no usar SB o XIB ya que estoy bien con esto.}

_{* Si has establecido los marcos de objetos de UIKit de acuerdo con el tamaño de la pantalla.}

_{PD: Si aún no has hecho esto, es posible que tengas dificultades (o que te sientas aburrido), pero una vez que te hayas familiarizado con esto, es realmente un caramelo para ti.}

Si desea reutilizar alguna interfaz de usuario en varios controladores de vista, debería utilizar XIB

Si está a punto de preocuparse por el rendimiento del guión gráfico, vea la Sesión 407 de la WWDC 2015

Tiempo de construcción

Cuando Interface Builder está compilando un guión gráfico, primero hace dos cosas, intenta maximizar el rendimiento de su aplicación y, en segundo lugar, también minimiza la cantidad de archivos de plumilla creados.
Si tengo un controlador de vista con una vista y un grupo de subvistas, creador de interfaces, el tiempo de compilación creará un archivo de punta para el controlador de vista y creará un archivo de punta para la vista.
Al tener archivos nib separados para el controlador de vista y la vista, esto significa que la jerarquía de vista se puede cargar a pedido.

Tiempo de ejecución

Cuando asigna una instancia del guión gráfico utilizando el guión gráfico de la interfaz de usuario, API, inicialmente todo lo que está asignando memoria es la instancia del guión gráfico de la interfaz de usuario.
No hay controladores de vista no hay vistas todavía.
Al crear una instancia de su controlador de vista inicial, se cargará la punta de ese controlador de vista inicial, pero, nuevamente, no se ha cargado ninguna jerarquía de vistas hasta que alguien realmente lo solicite.

Solo expondré 4 razones simples por las que debería usar guiones gráficos, especialmente en un entorno productivo en el que tiene que trabajar en un equipo de propietarios de productos, gerentes de productos, diseñadores de UX, etc.

Apple ha mejorado mucho trabajando con Storyboards. Y te animan a trabajar con ellos. Lo que significa que no romperán sus proyectos existentes con actualizaciones, se asegurarán de que los guiones gráficos estén a prueba de futuro para las nuevas versiones de XCode / iOS.
Resultados más visibles en menos tiempo para los propietarios y administradores del producto, incluso durante la fase de creación. Incluso puede utilizar el guión gráfico como un diagrama de flujo de pantalla y discutirlo en reuniones.
Incluso después de que se realiza una aplicación (y ahí es donde generalmente comienza su ciclo de vida), en el futuro será más rápido y más fácil aplicar pequeños ajustes . Y estos podrían muy bien cambiar múltiples aspectos de su diseño al mismo tiempo, lo que probablemente desee ver de forma WYSIWYG. La alternativa sería escribir manualmente los cambios de la interfaz de usuario en el código y alternar entre el IDE y el simulador para probarlo, cada vez esperando la compilación y compilación.
A los no desarrolladores se les puede enseñar a configurar diseños en guiones gráficos y crear los ganchos necesarios para los desarrolladores (IBOutlets e IBActions). Esa es una ventaja muy grande porque permite a los desarrolladores concentrarse en la lógica y los diseñadores de UX aplican sus cambios de manera visual, sin tener que escribir ningún código.

No escribiré ningún CONS, ya que Johannes ya ha enumerado probablemente todos los viables en su respuesta. Y la mayoría de ellos definitivamente no son viables, especialmente no con las mejoras principales de XCode6.

Actualización 12/01/2016 : es 2016 y todavía prefiero colocar mis interfaces de usuario en código y no en Storyboards. Dicho esto, los storyboards han recorrido un largo camino. He eliminado todos los puntos de esta publicación que simplemente no aplican más en 2016.

Actualización 24/04/2015 : Es interesante que Apple ni siquiera use Storyboards en su reciente ResearchKit de fuente abierta como Peter Steinberger ha notado (bajo el subtítulo "Interface Builder").

Actualización 6/10/2014 : Como se esperaba, Apple sigue mejorando Storyboards y Xcode. Algunos de los puntos que se aplicaron a iOS 7 y anteriores ya no se aplican a iOS 8 (y ahora están marcados como tales). Por lo tanto, aunque los guiones gráficos todavía tienen defectos, reviso mis consejos para no usarlos de manera selectiva donde tenga sentido .

Incluso ahora que iOS 9 está fuera, aconsejaría ~~en contra~~ tener cuidado al decidir si usar Storyboards. Aquí están mis razones:

Los guiones gráficos fallan en tiempo de ejecución, no en tiempo de compilación : ¿Tiene un error tipográfico en un nombre segue o está mal conectado en su guión gráfico? Se explotará en el tiempo de ejecución. ¿Utiliza una subclase UIViewController personalizada que ya no existe en su guión gráfico? Se explotará en el tiempo de ejecución. Si hace esas cosas en código, las capturará temprano, durante el tiempo de compilación. Actualización : mi nueva herramienta StoryboardLint soluciona principalmente este problema.
Los guiones gráficos se confunden rápidamente : a medida que su proyecto crece, su guión se vuelve cada vez más difícil de navegar. Además, si varios controladores de vista tienen varios segmentos respecto a otros controladores de vista, su guión gráfico rápidamente se verá como un plato de espaguetis y se encontrará acercándose y alejándose y desplazándose por todo el lugar para encontrar el controlador de vista que está buscando. Para y para saber qué puntos seguimos dónde. Actualización : este problema se puede resolver principalmente dividiendo su Guión gráfico en múltiples Guiones gráficos , como lo describe Pilky y este artículo de Robert Brown .
Los guiones gráficos dificultan el trabajo en equipo : como, por lo general, solo tiene un gran archivo de guión gráfico para su proyecto, tener múltiples desarrolladores que realicen cambios regularmente en ese archivo puede ser un dolor de cabeza: los cambios deben combinarse y resolverse los conflictos. Cuando ocurre un conflicto, es difícil saber cómo resolverlo: Xcode genera el archivo XML del guión gráfico y no fue realmente diseñado con el objetivo en mente de que un humano tendría que leer, y mucho menos editarlo.
Los guiones gráficos hacen que las revisiones de códigos sean difíciles o casi imposibles : las revisiones de códigos entre pares son una gran cosa para hacer en su equipo. Sin embargo, cuando realiza cambios en un guión gráfico, es casi imposible revisar estos cambios con un desarrollador diferente. Todo lo que puede sacar es una diferencia de un enorme archivo XML. Descifrar lo que realmente cambió y si esos cambios son correctos o si rompieron algo es realmente difícil.
Los guiones gráficos dificultan la reutilización del código : en mis proyectos de iOS, generalmente creo una clase que contiene todos los colores, fuentes, márgenes e inserciones que uso en toda la aplicación para darle un aspecto coherente: es un cambio de una línea si tengo que Ajusta cualquiera de esos valores para toda la aplicación. Si establece tales valores en el guión gráfico, los duplica y tendrá que encontrar cada aparición cuando desee cambiarlos. Hay muchas posibilidades de que se pierda uno, porque no hay búsqueda ni reemplazo en los guiones gráficos.
Los guiones gráficos requieren cambios de contexto constantes : me encuentro trabajando y navegando mucho más rápido en código que en guiones gráficos. Cuando su aplicación usa guiones gráficos, cambia constantemente su contexto: "Oh, quiero que un toque en esta celda de vista de tabla para cargar un controlador de vista diferente. Ahora tengo que abrir el guión gráfico, encontrar el controlador de vista correcto, crear un nuevo segmento al otro controlador de vista (que también tengo que encontrar), asigne un nombre al segmento, recuerde ese nombre (no puedo usar constantes o variables en los guiones gráficos), cambie de nuevo al código y espero no confundir el nombre de eso depende de mi método prepareForSegue. ¡Cómo me gustaría poder escribir esas 3 líneas de código aquí donde estoy! " No, no es divertido. El cambio entre el código y el guión gráfico (y entre el teclado y el mouse) envejece rápidamente y te ralentiza.
Los guiones gráficos son difíciles de refactorizar : cuando refactoriza su código, debe asegurarse de que aún coincida con lo que su guión gráfico espera. Cuando mueves cosas en tu guión gráfico, solo descubrirás en tiempo de ejecución si aún funciona con tu código. Me siento como si tuviera que mantener dos mundos sincronizados. Se siente frágil y desalienta el cambio en mi humilde opinión.
Los guiones gráficos son menos flexibles : ¡En el código, básicamente puedes hacer lo que quieras! Con los guiones gráficos está limitado a un subconjunto de lo que puede hacer en el código. Especialmente cuando quieres hacer algunas cosas avanzadas con animaciones y transiciones, te encontrarás "luchando contra el guión gráfico" para que funcione.
Los UITableViewController UICollectionViewController no le permiten cambiar el tipo de controladores de vista especiales : ¿Desea cambiar un UITableViewController en un UICollectionViewController ? ¿O en un UIViewController plano? No es posible en un Storyboard. Tienes que eliminar el controlador de vista anterior y crear uno nuevo y volver a conectar todos los segmentos. Es mucho más fácil hacer tal cambio en el código.
Los guiones gráficos agregan dos responsabilidades adicionales a su proyecto : (1) la herramienta Editor del guión gráfico que genera el XML del guión gráfico y (2) el componente de tiempo de ejecución que analiza el XML y crea objetos de UI y controladores a partir de él. Ambas partes pueden tener errores que no se pueden solucionar.
Los UIImageView no le permiten agregar una subvista a un UIImageView : quién sabe por qué.
Los guiones gráficos no le permiten habilitar el diseño automático para vistas individuales (-Controller) s : Al marcar / desmarcar la opción Diseño automático en un guión gráfico, el cambio se aplica a TODOS los controladores en el guión gráfico. (Gracias a Sava Mazăre por este punto!)
Los guiones gráficos tienen un mayor riesgo de romper la compatibilidad con versiones anteriores : Xcode a veces cambia el formato del archivo del guión gráfico y no garantiza de ninguna manera que pueda abrir los archivos del guión gráfico que cree hoy en algunos años o incluso meses. (Gracias a pensamiento avanzado por este punto. Ver el comentario original )
Los initWithCustomer: pueden hacer que su código sea más complejo : cuando crea sus controladores de vista en código, puede crear métodos de init personalizados, por ejemplo initWithCustomer: De esa manera, puede hacer que el customer dentro de su controlador de vista sea inmutable y asegurarse de que este controlador de vista no se pueda crear sin un objeto de customer . Esto no es posible cuando se utilizan guiones gráficos. Deberá esperar a que se prepareForSegue:sender: al método prepareForSegue:sender: y luego tendrá que configurar la propiedad del customer en su controlador de vista, lo que significa que debe hacer que esta propiedad sea mutable y debe permitir que el controlador de vista Ser creado sin un objeto de customer . En mi experiencia, esto puede complicar enormemente su código y hace que sea más difícil razonar sobre el flujo de su aplicación. Actualización 9/9/16 : Chris Dzombak escribió un gran artículo sobre este problema .
Es McDonald''s : Para decirlo en palabras de Steve Jobs sobre Microsoft: ¡ Es McDonald''s (video) !

Estas son mis razones por las que realmente no me gusta trabajar con guiones gráficos. Algunas de estas razones también se aplican a los XIB. En los proyectos basados en el guión gráfico en los que he trabajado, me han costado mucho más tiempo del que han ahorrado e hicieron las cosas más complicadas en lugar de más fáciles.

Cuando creo mi UI y el flujo de aplicaciones en el código, tengo mucho más control sobre lo que está sucediendo, es más fácil de depurar, es más fácil detectar errores al principio, es más fácil explicar mis cambios a otros desarrolladores y Es más fácil soportar iPhone y iPad.

Sin embargo, estoy de acuerdo en que la distribución de toda su IU en el código podría no ser una solución única para todos los proyectos. Si la IU de su iPad difiere mucho de la IU de su iPhone en ciertos lugares, podría tener sentido crear un XIB solo para esas áreas.

Apple puede solucionar muchos de los problemas descritos anteriormente y espero que eso sea lo que harán.

Sólo mis dos centavos.

Actualización : En Xcode 5, Apple eliminó la opción de crear un proyecto sin un Storyboard. He escrito un pequeño script que conecta las plantillas de Xcode 4 (con opción de exclusión del guión gráfico) a Xcode 5: https://github.com/jfahrenkrug/Xcode4templates