¿Para qué se utiliza el programa Interface Builder en iOS? Desarrollador de registros, desarrollo de aplicaciones

Creo que Emil David tiene una gran respuesta a continuación, pero solo quería comentar * por qué * usarías Interface Builder, en lugar de hacer cosas programáticamente. Ambos métodos dan como resultado el mismo binario compilado cuando todo está dicho y hecho, entonces, ¿por qué elegiría usar Interface Builder sobre la creación de instancias de vistas en su código? En realidad, hay ventajas de hacerlo en ambos sentidos.

¿Por qué usar IB?

Porque puedes escribir menos código: esto debería ser bastante obvio. El principal atractivo de Interface Builder, especialmente para aquellos nuevos en el desarrollo de iOS es que puede arrastrar y soltar visualmente y conectar cosas sin tener que saber cómo hacerlo en código. Podrías escribir una aplicación completa usando solo Interface Builder. Menos código escrito significa menos que puede salir mal, menos errores, más fácil de mantener, más fácil de cambiar, etc. Es algo bueno.
Debido a que puede comprender más fácilmente cómo funciona su programa, las aplicaciones de iOS son cosas innegablemente visuales, en lugar de decir que un programa se ejecuta en un servidor, o tal vez incluso en un servidor. Interface Builder funciona de manera natural al hacer que la visualización sea obvia. ¿Quieres saber qué sucede cuando tocas ese botón? Todo lo que tienes que hacer es mirar hacia dónde va la línea Segue y eso te dice el 90% de lo que necesitas saber. Más importante aún, si * alguien más * necesita entender cómo funciona su programa, probablemente también será más fácil para ellos.
Múltiples diseños, misma aplicación: con el creador de interfaces puede crear múltiples guiones gráficos. Entonces, por ejemplo, puede tener uno para iPad y uno para iPhones con pantallas más grandes (6, 6+) y uno para iPhones con pantallas más pequeñas. Puede intercambiarlos indistintamente mientras usa la misma lógica de cómo funciona su aplicación. Entonces, por ejemplo, supongamos que tiene una funcionalidad en su aplicación que solo tiene sentido en la pantalla más grande del iPad. Simplemente verifique qué dispositivo está utilizando el usuario antes de que se cargue esa vista y solo cárguelo si está en un iPad. Esto hace que su aplicación sea mucho más fácil de mantener.
Sin reinventar la rueda: todo lo que haces en Interface Builder es realmente solo un código que Apple escribió previamente. Eso significa que es un código que no tiene que escribir, pero lo más importante, es un código que no tiene que * probar *. A menos que haya un error o estés haciendo algo mal, solo sabes que va a funcionar. Por lo tanto, puede dedicar su tiempo a perfeccionar la funcionalidad de su aplicación en lugar de hacer manualmente cosas que esencialmente se han automatizado.

Bien, entonces ¿por qué hacer las cosas mediante programación?

Porque puedes escribir más código: sé que el primer punto que escribí dice que IB es bueno porque puedes escribir menos código, y aquí estoy diciendo lo contrario. Bueno, la cuestión es que Interface Builder es una especie de forma manual de programar. Dado que todo el código está preescrito, en realidad nunca obtienes una idea de cómo funciona iOS. En mi opinión, solo puede obtener eso escribiendo el código y usando Interface Builder. Una vez que pude conectar en mi mente cómo hacer algo en ambos sentidos, fue como si se hubiera apagado una luz, y de repente entendí mucho más sobre cómo funciona iOS. Un ejemplo de esto para mí fue en UIButtons. En IB, simplemente dibuje el botón en la pantalla, arrastre una conexión desde su IBAction y listo. No hay un concepto del objetivo del botón, o su selector. Hay un pequeño concepto de su estado (es decir, Seleccionado, Destacado, etc.). Después de configurar algunos botones mediante programación, tuve una mejor idea de esas cosas. Aunque podría ser yo.
Porque obtienes más control: a veces necesitas más control sobre los elementos de tu programa del que te proporciona Interface Builder. Por ejemplo, es posible que desee crear una subclase de un elemento visual que haga algo que el preexistente no hace. Esto es muy común con UITableViewCells y UICollectionViewCells. También es muy común crear UISegues personalizados.
Debido a que podría ser más eficiente: por ejemplo, usando solo Interface Builder, es posible que deba configurar una vista para cada función de su aplicación, pero si crea esas vistas mediante programación, o incluso solo las instancia en su código, puede simplemente cambiar la funcionalidad a medida que el usuario toca los botones. Ahora puede usar una sola vista para hacer muchas cosas. Esto puede o no hacer que su programa sea más fácil de entender. Si su funcionalidad es lo suficientemente compleja, es posible que desee utilizar varias vistas …
Porque es más fácil de depurar: las cosas salen mal cuando estás programando. A veces obtiene resultados inesperados y no sabe por qué, por lo que establece puntos de interrupción en el código y lo recorre para inspeccionar el contenido de las variables. Por ejemplo, al hacer esto, es posible que vea que una matriz que espera que contenga algo nunca se inicializó y, por lo tanto, es nula. Realmente no es posible en Interface Builder.
Debido a que hay algunas cosas que Interface Builder simplemente no puede hacer: un ejemplo que me viene a la mente es trabajar con CALayer de la vista. Esto es algo que haría, por ejemplo, para que una vista tenga esquinas redondeadas y un borde negro. Resulta que hay un concepto llamado Variables de tiempo de ejecución definidas por el usuario en Interface Builder, y puede usarlos para establecer el CornerRadius de la capa y el ancho del borde, pero por alguna razón no puede establecer el color en negro . Este es solo un ejemplo de algo que no puedes hacer, estoy seguro de que hay muchos más.

Espero que esto ayude.