iOS Developer Jr route: learn for free from scratch in 6 weeks

Esta semana aprendes Swift, el idioma en el que se escriben las apps de iPhone, y Git, una herramienta que guarda cada versión de tu trabajo. Piensa en Swift como las reglas de una receta: ingredientes (datos) y pasos (instrucciones) que el teléfono sigue al pie de la letra. Swift es estricto pero amable: si algo puede fallar, te avisa antes de correr el programa. Git es como las partidas guardadas de un videojuego: si algo sale mal, vuelves a un punto anterior sin perder nada. Empieza con pasos pequeños: cada programa que corre es un logro.

Mini ejemplo: let saldo = 100 no se puede cambiar; var intentos = 0 sí. Y let nombre: String? = nil te obliga a decidir qué hacer si no hay nombre.

Error típico de principiante: usar ! para forzar un opcional. Si es nil, la app se cierra; mejor if let, guard let o ??.

Esta semana vas a dibujar tus primeras pantallas de iPhone con SwiftUI, la herramienta de Apple para armar lo que la persona ve y toca. Es como armar con bloques de LEGO: una pila vertical aquí (VStack), una fila allá (HStack), un botón encima, y juntas piezas simples hasta tener una pantalla completa. Lo mejor: el canvas de Xcode te muestra el resultado mientras escribes, sin correr la app. Ver tu propia pantalla funcionando en el simulador es de lo más motivador: disfrútalo.

Mini ejemplo: VStack { Text("Hola"); Button("Entrar") { } } ya es una pantalla: un texto con un botón debajo.

Error típico de principiante: cambiar el orden de los modificadores sin mirar. .padding().background(.yellow) y .background(.yellow).padding() se ven distintos.

Esta semana aprendes a que tu app "recuerde" cosas y a pasarlas de una pantalla a otra. @State es la memoria de una vista, @Binding es un control remoto que le prestas a otra vista para que cambie ese dato, y un ViewModel con @Observable es como el mesero de un restaurante: toma los pedidos, aplica las reglas y le avisa a la pantalla cuando algo cambió. La navegación funciona como los pasillos de un centro comercial: entras a una tienda y puedes volver atrás. Si al principio se siente raro, es normal; con la práctica encaja solo.

Mini ejemplo: en un contador, @State var cuenta = 0 es el dato y el botón hace cuenta += 1; si una vista hija necesita cambiarlo, recibe $cuenta como @Binding.

Error típico de principiante: tener un @State separado para el mismo dato en dos vistas. Se desincronizan; un solo dueño y los demás lo piden prestado.

Esta semana tu app deja de usar datos inventados y empieza a pedirlos a internet, como hace cualquier app real. Una API es una ventanilla: tu app hace un pedido y recibe una respuesta en JSON, que es como una ficha de datos. Codable traduce ese JSON a tus struct automáticamente, y async/await permite esperar la respuesta sin congelar la pantalla, como cuando pides delivery y sigues con tus cosas hasta que suena el timbre. También aprendes a mostrar "cargando" y "algo salió mal", que es lo que separa una app de juguete de una app de verdad.

Mini ejemplo: let (data, _) = try await URLSession.shared.data(from: url) espera sin congelar la pantalla; luego JSONDecoder().decode(Pokemon.self, from: data) lo convierte en un struct.

Error típico de principiante: olvidar el estado de error. Sin internet la pantalla queda en blanco; piensa siempre en cargando, éxito y error.

Esta semana ordenas tu código como lo hace un equipo profesional y haces que la app recuerde cosas aunque la cierres. MVVM es como un restaurante bien organizado: el salón (la vista) solo atiende, el mesero (el ViewModel) toma pedidos y la cocina (el repositorio) prepara lo que se pide, sin que nadie se meta en el trabajo del otro. Con @AppStorage guardas preferencias chiquitas, como "ocultar saldo", y con SwiftData guardas listas completas, como tus Pokémon favoritos. Así tu app funciona incluso sin internet.

Mini ejemplo: @AppStorage("ocultarSaldo") var ocultar = false recuerda tu preferencia; los 500 movimientos van en SwiftData con @Model.

Error típico de principiante: guardar el token o la contraseña en UserDefaults. No está cifrado; para secretos usa el Keychain.

Esta semana practicas cómo se trabaja en un equipo real: escribir pruebas (tests), encontrar errores (bugs) con el debugger y pedir revisión de tu código. Un test es como revisar la mochila antes de salir de casa: una lista que confirma que todo está donde debe. El debugger es como pausar una película para mirar cada detalle de la escena. Un Pull Request es como entregar una tarea para que alguien la revise antes de publicarla, y los comentarios que recibas son para mejorar, no para juzgarte. Llegaste hasta aquí: ya piensas como alguien que programa de verdad.

Mini ejemplo: @Test func sumaGastos() { #expect(total([10, 20]) == 30) }; si alguien rompe total, el test se pone en rojo antes de publicar.

Error típico de principiante: leer un crash de abajo hacia arriba o mandar un PR gigante. Busca la primera línea de tu código y manda cambios pequeños.