Adentrarse en el mundo del desarrollo de aplicaciones móviles puede resultar un camino lleno de desafíos, especialmente cuando se intenta dominar nuevas tecnologías y herramientas. En 2023, decidí emprender mi primer proyecto serio con Swift, SwiftUI y Xcode para crear una aplicación nativa en iOS, y la experiencia fue tanto reveladora como educativa. A lo largo de este recorrido, comprendí las ventajas de optar por un desarrollo nativo frente a alternativas multiplataforma, las curiosidades del lenguaje Swift y la interacción con SwiftUI, así como las sorpresas y dificultades propias de Xcode como entorno de trabajo. Durante años, intenté aprender React Native en varias ocasiones. La instalación, las actualizaciones constantes y los numerosos errores me hicieron sentir frustrado.
Las interminables horas dedicadas a simplemente hacer funcionar un "Hello World" parecían un obstáculo demasiado grande. Esta vivencia contrastó enormemente con los tiempos en que usaba Visual Basic 6, donde bastaba abrir el entorno y el código funcionaba de manera sencilla. Por ello, decidí cambiar de rumbo y darle una oportunidad al desarrollo nativo, con la esperanza de una experiencia más fluida y menos frustrante. El primer paso fue descargar Xcode desde la Mac App Store. Sin embargo, me encontré con el primer inconveniente: la tienda me ofrecía versiones antiguas sin la opción clara de obtener la última.
Al investigar, descubrí que Apple exige actualizar el sistema operativo, por lo que tuve que actualizar a macOS Ventura. Esta tarea llevó su tiempo e incluso me recibió un nuevo fondo de escritorio, un recordatorio visual del cambio que estaba realizando. Una vez actualizado el sistema, continué con la instalación de Xcode, que también presentó momentos de incertidumbre, como una rueda giratoria cuando debería aparecer el botón para abrir la aplicación. Esta espera me permitió tomar un descanso y reflexionar. Abrir Xcode por primera vez fue una mezcla de emoción y confusión.
Al crear un nuevo proyecto, observé que los nombres de las plantillas no eran especialmente claros, con opciones como "App" y "Document App" que no ofrecían mucha información GUIADA. También existían versiones "Multiplatform" o específicas para "iOS", generando dudas sobre cuál elegir. La mejor estrategia fue seleccionar una, explorar y en caso necesario borrar para intentar otra opción. Al avanzar, descubrí que el proyecto base sólo contenía dos archivos de código, lo que me agradó porque implicaba una mínima cantidad de plantilla y evitando el ruido habitual de otros entornos. El archivo principal actuaba como punto de entrada, creando la vista principal, mientras que el segundo definía esa vista.
Noté desde el inicio algunas curiosidades en la sintaxis de Swift y SwiftUI. Por ejemplo, la posibilidad de encadenar métodos como .imageScale() y .foregroundColor(), algo que me recordó a LINQ por su fluidez, me hizo preguntarme si cada método devuelve un objeto que permite continuar la cadena. Otra característica llamativa fue el uso del operador punto sin un objeto explícito a la izquierda, como en .
large. Esto me hizo cuestionar si Swift permite puntos en nombres o si hay un implícito this que se comunica detrás del código. Asimismo, la aparición de bloques rodeados por llaves directamente tras una llamada a tipo o función —como VStack { ...
}— generó curiosidad, pues no parecía una simple declaración sino un mecanismo para definir la interfaz. Buscando referencias, entendí que podría ser un uso de closures o propiedades computadas que definen jerarquías visuales declarativas. El uso de la palabra reservada some también llamó mi atención. En SwiftUI, verla en una declaración como var body: some View parecía indicar un tipo opaco o un nivel de abstracción para lograr polimorfismo, lo que invitaba a investigar más sobre los conceptos de tipos genéricos y composición de vistas en Swift. Con estas primeras impresiones, decidí crear una aplicación básica de lista de tareas, un proyecto clásico para empezar a entender controles, gestión de eventos y estado.
Empecé con algo simple: un botón que, al presionarse, imprimiera un mensaje en la consola y navegar al siguiente pantalla. El código para el botón fue sencillo y funcional, y me sorprendí gratamente de la facilidad para definir su apariencia mediante modificadores encadenados. Sin embargo, cuando intenté que una variable booleana controlara automáticamente la aparición de un texto en la interfaz tras pulsar dicho botón, me topé con un obstáculo: el texto no aparecía pese a que el mensaje de clic sí se imprimía. Tras horas de investigación, descubrí que SwiftUI requiere usar la anotación @State para variables que cambian en tiempo de ejecución y que deben disparar una actualización de la vista. Este detalle no es trivial y evidencia la diferencia con paradigmas imperativos tradicionales, destacando la naturaleza declarativa y reactiva de SwiftUI.
Adicionalmente, aprendí que en SwiftUI las "vistas" no representan necesariamente pantallas o páginas completas como en otras plataformas, sino que pueden estar compuestas por múltiples vistas anidadas que forman la interfaz. Esto generó cierta confusión en cuanto a cómo gestionar la navegación entre diferentes contenidos y cambiar la vista global mostrada. Buscando la forma correcta de manejar la navegación, leído documentación y tutoriales resultó en más confusión. SwiftUI ofrece tipos especializados para navegación, como NavigationStack o NavigationView, que funcionan como contenedores con comportamientos predeterminados y animaciones integradas. No obstante, también es posible gestionar la presentación de vistas manualmente modificando el estado, aunque esto sacrifica ciertas ventajas estéticas.
Intentar un control de pantallas mediante un enum y un switch dentro de la vista principal fue la solución más clara para mí, aunque al principio la sintaxis me provocó errores crípticos como "Expected declaration" o problemas con los tipos de retorno opacos. Esto reforzó la idea de que el entorno tiene una curva de aprendizaje pronunciada y requiere comprensión profunda de conceptos declarativos y manejo del estado. Finalmente, logré implementar navegación básica cambiando la variable de estado que indicaba la página actual y condicionando la vista mostrada según su valor. Esta experiencia me liberó de la confusión e hizo evidente que la clave está en aprender a pensar en términos de estado y vistas descriptivas. A partir de ahí, el desarrollo fue más fluido.
Agregué estructuras de datos para representar tareas, diseñé layouts más elaborados y planifiqué funcionalidades pendientes, tales como agregar controles flotantes, separar cada pantalla en vistas estructuradas, transmitir datos entre componentes, implementar animaciones de transición y persistir la información entre sesiones. Sobre Swift como lenguaje, encontré múltiples características interesantes, desde inferencia de tipos, manejo de opciones, protocolos, hasta su sintaxis limpia pero diferente a lenguajes tradicionales. Requiere tiempo para acostumbrarse, pero promete un desarrollo seguro y moderno. En cuanto a Xcode, valoro que sea un entorno minimalista que prioriza la simplicidad, aunque la autocompletación suele interrumpir más de la cuenta, y los mensajes de error muchas veces parecen obsoletos, poco claros y sin orientaciones precisas para solucionar fallos comunes. A pesar de estas dificultades, avanzar en el proyecto fue gratificante y me brindó una experiencia apreciablemente más agradable que la de anteriores herramientas multiplataforma.
En suma, dar mis primeros pasos en Swift, SwiftUI y Xcode fue un reto, pero la experiencia fue positiva y aprendí con rapidez los fundamentos clave para seguir avanzando. La transición de frameworks con capas intermedias a desarrollo nativo me ha permitido tener mayor control y entender mejor cómo funcionan las aplicaciones iOS bajo el capó. Mi objetivo ahora es continuar perfeccionando mis habilidades, avanzar en la aplicación que comencé y, eventualmente, lanzar un producto funcional en la App Store. Compartiré futuras experiencias y aprendizajes en este camino, con la esperanza de que sirvan a otros desarrolladores que también buscan dominar este ecosistema Apple tan apasionante como complejo.
