Cuándo usar Storyboard y cuándo usar XIB

¿Hay alguna guía 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 limpio usar segues del guión gráfico cuando tienes controladores de vista empujados por elementos dinámicos de la interfaz de usuario (como pines de mapa).

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

• Los guiones gráficos son buenos para aplicaciones con un número pequeño o mediano de pantallas y una navegación relativamente sencilla entre las vistas.
• Si tiene muchas vistas y mucha navegación cruzada entre ellas, la vista de Storyboard se vuelve confusa y demasiado trabajo para mantenerse limpio.
• Para un proyecto grande con múltiples desarrolladores, no usaría Storyboards porque tiene un solo archivo para su IU y no puede trabajar fácilmente en paralelo.
• Puede 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 guiones gráficos.
• Todavía 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 extienda 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 inicio 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 los XIB.

Actualización 1/12/2016 : es 2016 y todavía prefiero diseñar 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 ya no se aplican en 2016.

Actualización 24/04/2015 : Curiosamente, Apple ni siquiera usa Storyboards en su ResearchKit de código abierto recientemente como Peter Steinberger ha notado (bajo el subtítulo "Interface Builder").

Actualización 10/06/2014 : Como se esperaba, Apple sigue mejorando Storyboards y Xcode. Algunos de los puntos que se aplicaron a iOS 7 y versiones posteriores ya no se aplican a iOS 8 (y ahora están marcados como tales). Entonces, aunque Storyboards inherentemente todavía tiene fallas, reviso mi consejo de no usar para usar selectivamente donde tiene sentido .

Incluso ahora que iOS 9 está fuera, recomendaría en contratener precaución al decidir si usar Storyboards. Aquí están mis razones:

• Los guiones gráficos fallan en el tiempo de ejecución, no en el momento de la compilación : ¿tiene un error tipográfico en un nombre segue o lo conectó incorrectamente en su guión gráfico? Estallará en tiempo de ejecución. ¿Utiliza una subclase personalizada de UIViewController que ya no existe en su guión gráfico? Estallará en tiempo de ejecución. Si hace tales cosas en código, las detectará desde el principio, durante el tiempo de compilación. Actualización : Mi nueva herramienta StoryboardLint resuelve principalmente este problema.

• Los guiones gráficos se vuelven confusos rápidamente : a medida que su proyecto crece, su guión gráfico se vuelve cada vez más difícil de navegar. Además, si varios controladores de vista tienen múltiples segmentos a varios otros controladores de vista, su guión gráfico rápidamente comenzará a verse como un tazón de espagueti 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 averiguar qué puntos de segue dónde. Actualización : este problema se puede resolver principalmente dividiendo su Storyboard en múltiples Storyboards, como se describe en este artículo de Pilky y este artículo de Robert Brown .

• Los guiones gráficos hacen que trabajar en un equipo sea más difícil : debido a que generalmente solo tiene un gran archivo de guión gráfico para su proyecto, tener múltiples desarrolladores que realizan cambios regularmente en ese archivo puede ser un dolor de cabeza: los cambios deben fusionarse y los conflictos deben resolverse. Cuando se produce un conflicto, es difícil saber cómo resolverlo: Xcode genera el archivo XML del guión gráfico y no se diseñó realmente 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ódigo sean difíciles o casi imposibles : las revisiones de código de pares son una gran cosa para 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 extraer es una diferencia de un gran archivo XML. Descifrar lo que realmente cambió y si esos cambios son correctos o si se 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 utilizo en toda la aplicación para darle una apariencia consistente: es un cambio de una línea si tengo que ajustar cualquiera de esos valores para toda la aplicación. Si establece dichos valores en el guión gráfico, los duplica y necesitará encontrar cada aparición cuando desee cambiarlos. Hay muchas posibilidades de que te pierdas uno, porque no hay búsqueda y 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 el código que en los guiones gráficos. Cuando su aplicación usa guiones gráficos, cambia constantemente su contexto: "Oh, quiero tocar 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 escribir mal el nombre de eso sigue para mi método prepareForSegue. ¡Cómo desearía poder escribir esas 3 líneas de código aquí donde estoy! " No, no es divertido Cambiar 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 lo descubrirás en tiempo de ejecución si aún funciona con tu código. Me parece que tengo 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 quieras hacer algunas cosas avanzadas con animaciones y transiciones, te encontrarás "luchando contra el guión gráfico" para que funcione.

• Los guiones gráficos no le permiten cambiar el tipo de controladores de vista especiales : ¿Desea cambiar un UITableViewControllera UICollectionViewController? O en una llanura UIViewController? No es posible en un Storyboard. Debe 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 del Editor de guiones gráficos 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 interfaz de usuario y controlador a partir de él. Ambas partes pueden tener errores que no puede solucionar.

• Los guiones gráficos no le permiten agregar una subvista aUIImageView : Quién sabe por qué.

• Los guiones gráficos no le permiten habilitar el Diseño automático para las Vistas individuales (-Controlador) : 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 de archivo del guión gráfico y no garantiza de ninguna manera que podrá abrir los archivos del guión gráfico que cree hoy dentro de unos años o incluso meses. (Gracias a Thoughtadvances por este punto. Ver el comentario original )

• Los guiones gráficos pueden hacer que su código sea más complejo : cuando crea sus controladores de vista en código, puede crear initmétodos personalizados , por ejemplo initWithCustomer:. De esa manera, puede hacer que el customerinterior de su controlador de vista sea inmutable y asegurarse de que este controlador de vista no se pueda crear sin un customerobjeto. Esto no es posible cuando se usan Storyboards. Tendrá que esperar a que se invoque el prepareForSegue:sender:método y luego deberá establecer la customerpropiedad en su controlador de vista, lo que significa que debe hacer que esta propiedad sea mutable y deberá permitir que el controlador de vista se cree sin un customerobjeto . En mi experiencia, esto puede complicar mucho 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 excelente 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 guiones gráficos 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 interfaz de usuario y el flujo de la aplicación en el código, tengo mucho más control de lo que está sucediendo, es más fácil de depurar, es más fácil detectar errores desde el principio, es más fácil explicar mis cambios a otros desarrolladores y Es más fácil admitir iPhone y iPad.

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

Apple podría solucionar muchos de los problemas descritos anteriormente y espero que eso sea lo que hagan.

Solo 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 porta las plantillas de Xcode 4 (con la opción de exclusión de Storyboard) a Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Los guiones gráficos se crearon para ayudar a los desarrolladores a visualizar su aplicación y el flujo de la aplicación. Es mucho como 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 del código que cambiará dinámicamente si es necesario, al igual que con .xibs.

PROS:

• Puede simular el flujo de una aplicación sin escribir mucho, si es que hay algún código.
• Es 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.
• Puede saturarse 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 quieres usar.

Solo expondré 4 razones simples por las que debe usar guiones gráficos, especialmente en un entorno productivo donde tiene que trabajar en un equipo de propietarios de productos, gerentes de productos, diseñadores de experiencia de usuario, etc.

1. Apple ha mejorado enormemente el trabajo 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 sean una prueba futura para las nuevas versiones de XCode / iOS.
2. Resultados más visibles en menos tiempo. para los propietarios y gerentes de productos, incluso durante la fase de creación. Incluso puede usar el guión gráfico como un diagrama de flujo de pantalla y discutirlo en las reuniones.
3. Incluso después de que se realiza una aplicación (y generalmente es donde 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 cambiar múltiples aspectos de su diseño al mismo tiempo, lo que probablemente quiera ver de manera WYSIWYG. La alternativa sería escribir a mano los cambios de UI en el código y alternar entre el IDE y el simulador para probarlo, cada vez que se espera la compilación y la compilación.
4. 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 gran ventaja porque permite a los desarrolladores centrarse 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 principales mejoras de XCode6.

No creo que haya una respuesta correcta para su pregunta, es solo una cuestión de experiencia personal y con lo que se siente más cómodo.

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

El único problema real es trabajar en equipo bajo 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 auto-arreglan cuando vuelves a abrir el guión gráfico. . En nuestro trabajo en equipo preferimos lidiar con esto en lugar de pesados ​​controladores de vista con toneladas de código de vista.

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

También creo que la mayoría de las personas a las que no les gustan los guiones gráficos no intentaron comprender por completo el poder de una segue manual personalizada, donde puede personalizar totalmente (en un solo archivo) la forma en que pasa de una manera a otra y también (con algunos trucos) incluso reutilizan un controlador de vista previamente cargado simplemente actualizando su contenido de vista en lugar de volver a cargarlo completamente. Al final, realmente puede hacer las mismas cosas que en el código, pero creo que tiene una mejor separación de las preocupaciones con los guiones gráficos, pero estoy de acuerdo en que en muchas cosas carecen de características (fuentes, imagen como fondo de color, etc.) )

No estoy usando StoryBoard o XIB en ninguna de las aplicaciones ... sino creando todo mediante programación.

∆ Beneficios:

√ Puede crear cualquier tipo complejo de UI o animaciones de transición para UIView 's.

√ Admite 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 dispositivo (nuevo) lanzado: no es necesario cambiar el código.

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

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

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

_{* si ha configurado los marcos de objetos de UIKit de acuerdo con el tamaño de la pantalla.}

_{PD: Si aún no ha hecho esto, puede enfrentar dificultades (o puede sentirse aburrido) pero una vez que se familiarice con esto, es realmente un caramelo para usted.}

Si está a punto de preocuparse por el rendimiento de Storyboard, vea la Sesión 407 de WWDC 2015

Tiempo de construcción

Cuando el creador de interfaces está compilando un guión gráfico, primero está haciendo dos cosas, está tratando de maximizar el rendimiento de su aplicación y, en segundo lugar, también está minimizando la cantidad de archivos plumín creados.

Si tengo un controlador de vista con una vista y un montón de vistas secundarias, generador de interfaz, el tiempo de compilación creará un archivo plumín para el controlador de vista y creará un archivo plumín para la vista.

Al tener archivos plum separados tanto para el controlador de vista como para 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 con 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 propia interfaz de usuario.

No hay controladores de vista aún no hay vistas.

Cuando crea una instancia de su controlador de vista inicial, cargará la punta para ese controlador de vista inicial pero, nuevamente, no se ha cargado ninguna jerarquía de vista hasta que alguien realmente lo solicite.

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

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

2. En segundo lugar, no funcionan bien con los Controladores de contenedores personalizados que incorporan otros controladores de contenedores, etc. Estamos utilizando MFSlideMenu en una aplicación con pestañas y la escena tiene una tabla. Esto es casi imposible de hacer con un guión gráfico. Después de pasar días, he recurrido a hacer la forma XIB donde hay un control completo.

3. El IDE no permite seleccionar controles en estado reducido. Entonces, en un proyecto grande, el alejamiento 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 tamaños de equipo pequeños y usaría el enfoque XIB para equipos / proyectos medianos y grandes.

Si desea reutilizar alguna IU en múltiples controladores de vista, entonces debe usar XIB