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 UITableViewController
a 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 init
métodos personalizados , por ejemplo initWithCustomer:
. De esa manera, puede hacer que el customer
interior de su controlador de vista sea inmutable y asegurarse de que este controlador de vista no se pueda crear sin un customer
objeto. 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 customer
propiedad 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 customer
objeto . 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