Un día en la vida de un desarrollador Swift: de la taza de café al despliegue en la App Store

Cómo es un día laboral típico de un desarrollador Swift en 2025

Cuando empecé a aprender Swift, pensaba que los desarrolladores iOS eran magos que escribían código perfecto desde la mañana hasta la noche mientras tomaban un latte en un coworking moderno. La realidad, como habrás adivinado, resultó más prosaica, pero no menos interesante.

En este artículo te guiaré a través de un día laboral típico de un desarrollador Swift, desde el café matutino hasta el push nocturno en la App Store. No solo verás el horario, sino también fragmentos de código reales con los que nos enfrentamos cada día. ¡Allá vamos!

09:00 — Mañana: Daily Stand-up y planificación

El día comienza con un breve standup en Zoom o Slack. Somos un equipo de 5 desarrolladores iOS, dos backend y un product manager. Cada uno habla durante 1-2 minutos: qué se hizo ayer, qué se planea hoy, si hay bloqueos.

Mi respuesta típica suena así:

\n
• Ayer: Terminé la refactorización del módulo de autorización con Combine.
\n
• Hoy: Integraré la nueva pantalla de perfil con SwiftUI, necesito hacer la animación de transición.
\n
• Bloqueo: Espero los mockups finales del diseñador para el modo oscuro.
\n

Después del standup, 15 minutos para revisar los mensajes en Jira y GitHub. Miro qué PR requieren mi revisión y leo los comentarios de mis pull requests.

09:45 — Primer trabajo profundo: Nueva funcionalidad

La mañana es el mejor momento para tareas complejas. Hoy estoy escribiendo el módulo de notificaciones push con deep linking. Así es como se ve la estructura típica de una clase manejadora:

import UIKit\nimport UserNotifications\n\nfinal class PushNotificationHandler: NSObject, UNUserNotificationCenterDelegate {\n    \n    func userNotificationCenter(\n        _ center: UNUserNotificationCenter,\n        didReceive response: UNNotificationResponse,\n        withCompletionHandler completionHandler: @escaping () -> Void\n    ) {\n        let userInfo = response.notification.request.content.userInfo\n        \n        guard let deepLink = DeepLinkParser.parse(userInfo) else {\n            completionHandler()\n            return\n        }\n        \n        Task { @MainActor in\n            Coordinator.shared.handle(deepLink)\n        }\n        \n        completionHandler()\n    }\n    \n    func userNotificationCenter(\n        _ center: UNUserNotificationCenter,\n        willPresent notification: UNNotification,\n        withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void\n    ) {\n        completionHandler([.banner, .sound, .badge])\n    }\n}

Observa Task { @MainActor in } — esta es la forma moderna de forzar la ejecución en el hilo principal sin el anticuado DispatchQueue.main.async. Un desarrollador iOS actualmente usa activamente Concurrency de Swift 5.5+.

11:00 — Code Review: Una mirada externa

Llega una notificación de un colega: "Revisa el PR, por favor". Abro GitHub, veo cambios en el modelo de datos. Aquí hay un ejemplo de lo que a menudo comento:

// ❌ Mal: force unwrap\nlet user = users.first!\n\n// ✅ Bien: extracción segura\nguard let user = users.first else {\n    assertionFailure("La lista de users no debería estar vacía en esta etapa")\n    return\n}

En el code review no solo discutimos la corrección, sino también la arquitectura. Hoy un colega usó SwiftUI con @ObservableObject, pero según nuestro estándar de código estamos migrando a @Observable (iOS 17+). Hago un comentario sutil:

// Recomendamos reescribir con @Observable\n@Observable\nfinal class ProfileViewModel {\n    var name: String = ""\n    var age: Int = 0\n}

12:30 — Almuerzo y cambio de contexto

El almuerzo es sagrado. Salgo a la calle o cocino yo mismo. Trato de no mirar la pantalla — los ojos descansan. Durante el almuerzo a menudo leo Telegram