No creo que iOS 6 corrige cualquiera de estas situaciones. Más al punto, xcode 4.5 no los arregla o incluso intenta hacerlo. Los problemas enumerados parecen reflejar opiniones o preferencias estilísticas, y quizás alguna información errónea. Estos no son el tipo de cosas que PODRÍAN corregirse en el código.
Estoy utilizando guiones gráficos para una aplicación sustancial y considero que son una gran ayuda para la productividad. Te animo a que intentes ver si no estás de acuerdo.
Un par de comentarios sobre la lista de temas:
- No estoy al tanto de cualquier problema con los equipos y SBS, pero si fuera cierto 2 (que no lo es) que explicarían esta preocupación . Creo que esto es un concepto erróneo basado en 2.
- No es cierto. Uso a Git religiosamente y me comprometo con frecuencia. No hay problema. Durante las confirmaciones, los SB se muestran en su forma de código fuente (XML). Los diffs funcionan perfectamente y proporcionan una idea de cómo se implementan los SB. Esto reduce la sensación de comportamientos misteriosos "encubiertos", que se convierte en un problema de familiaridad.
- No estoy de acuerdo. No interrumpen el flujo, ofrecen un flujo diferente, que es donde obtienen su poder. Muchos programadores encuentran valor en la separación impuesta por la disciplina MVC. Los SB introducen una separación entre la colocación del elemento de UI y el código de soporte. Es una división natural, y elimina una tonelada de código descerebrado (lo que elimina la posibilidad de errores tipográficos, y "despeja" el código REAL que queda).
- Parcialmente de acuerdo, definitivamente mejoran la facilidad de uso. Pero no encuentro ningún sacrificio en absoluto. Incluso cuando usa SB, siempre puede volver a codificar manualmente cualquier objeto si lo necesita. No hay sacrificio de flexibilidad o control.
- No estoy seguro de lo que esto significa, y por qué podría ser un problema. Por supuesto, creamos diferentes VCs para diferentes escenas, eso es natural. Pero ciertamente es posible reutilizar las clases de VC en SB. Este elemento podría ser una idea errónea sobre cómo configurar la clase para un objeto SB. Es fácil olvidarse de hacer este paso, y a veces desconcierta a los principiantes.Pero es trivial corregirlo, y establecer la clase rápidamente se convierte en un hábito.
Para mí las preocupaciones reales son:
- Usando SB exige una gran cantidad de espacio en pantalla para el desarrollo. Usar SB puede ser frustrante en una pantalla pequeña.
- Las IU altamente complejas con muchas escenas se deben dividir en varios SB. Múltiples SB son totalmente compatibles, pero es fácil dejar de hacerlo. (Es como refactorización un método que se hace demasiado grande. Por lo general, noto que tengo que refractor código después de algo que ya ha conseguido desordenado.)
La conveniencia de SB durante el diseño y la eliminación de gran parte del código repetitivo que satura objetos VC es un gran beneficio. (Cada línea de código que elimino es una línea que no puedo arruinar, y una línea que no puede oscurecer el código real que queda.)
En resumen, no puedo imaginar volver a la vida sin SBs. Sí, es un cambio. Pero no he encontrado ningún inconveniente serio. Es especialmente importante tener en cuenta que incluso cuando se utilizan SB, todas las técnicas de codificación que no son de SB aún funcionan. Prueba SB's e informa tu propia experiencia. ¡Buena suerte!
Un punto más, hay una charla muy útil en la biblioteca WWDC 2012 sobre cómo agregar objetos SB a proyectos existentes sin convertir todo a SB. Está aquí: https://developer.apple.com/videos/wwdc/2012/?id=407 – jbbenni