Um dia na vida de um desenvolvedor Swift: de uma xícara de café ao deploy na App Store

Como é um dia de trabalho típico de um desenvolvedor Swift em 2025

Quando comecei a estudar Swift, achava que os desenvolvedores iOS eram uns magos que passavam o dia escrevendo código perfeito enquanto tomavam um latte num coworking estiloso. A realidade, como você pode imaginar, acabou sendo mais prosaica, mas não menos interessante.

Neste artigo, vou te guiar pelo dia de trabalho típico de um desenvolvedor Swift — desde o café da manhã até o push noturno na App Store. Você verá não apenas a agenda, mas também trechos reais de código que enfrentamos todos os dias. Vamos lá!

09:00 — Manhã: Daily Stand-up e planejamento

O dia começa com uma rápida stand-up no Zoom ou Slack. Somos uma equipe de 5 desenvolvedores iOS, dois backend e um product manager. Cada um fala por 1-2 minutos: o que foi feito ontem, o que está planejado para hoje, se há bloqueios.

Minha resposta típica soa assim:

\n
• Ontem: Terminei a refatoração do módulo de autenticação com Combine.
\n
• Hoje: Vou integrar a nova tela de perfil com SwiftUI, preciso fazer a animação de transição.
\n
• Bloqueio: Aguardando os mockups finais do designer para o tema escuro.
\n

Após a stand-up — 15 minutos para revisar mensagens no Jira e GitHub. Vejo quais PRs precisam da minha revisão e leio os comentários nos meus pull requests.

09:45 — Primeiro trabalho profundo: Nova funcionalidade

A manhã é a melhor hora para tarefas complexas. Hoje estou escrevendo o módulo de notificações push com deep linking. Aqui está como é a estrutura típica da classe handler:

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}

Observe o Task { @MainActor in } — esta é a forma moderna de forçar a execução na thread principal sem o antigo DispatchQueue.main.async. O desenvolvedor iOS atualmente usa bastante a Concurrency do Swift 5.5+.

11:00 — Code Review: Um olhar de fora

Chega uma notificação de um colega: "Dá uma olhada no PR, por favor". Abro o GitHub, vejo alterações no modelo de dados. Aqui está um exemplo do que costumo comentar:

// ❌ Ruim: force unwrap\nlet user = users.first!\n\n// ✅ Bom: extração segura\nguard let user = users.first else {\n    assertionFailure("A lista de users não deve estar vazia nesta etapa")\n    return\n}

No code review, discutimos não apenas a correção, mas também a arquitetura. Hoje, um colega usou SwiftUI com @ObservableObject, mas, de acordo com nosso padrão de código, estamos migrando para @Observable (iOS 17+). Faço uma observação sutil:

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

12:30 — Almoço e mudança de contexto

O almoço é sagrado. Saio para a rua ou cozinho em casa. Tento não olhar para a tela — meus olhos descansam. Durante o almoço, costumo ler o Telegram