À quoi ressemble une journée de travail typique d'un développeur Swift en 2025
\n\nQuand j'ai commencé à apprendre Swift, je pensais que les développeurs iOS étaient des sortes de magiciens qui passaient leurs journées à écrire du code parfait devant un latte dans un espace de coworking stylé. La réalité, comme vous l'imaginez, s'est avérée plus prosaïque, mais tout aussi intéressante.
\n\nDans cet article, je vais vous guider à travers une journée de travail typique d'un développeur Swift — du café du matin au push du soir sur l'App Store. Vous verrez non seulement l'emploi du temps, mais aussi des extraits de code réels que nous rencontrons chaque jour. C'est parti !
\n\n09:00 — Matin : Daily Stand-up et planification
\n\nLa journée commence par un court stand-up sur Zoom ou Slack. Nous sommes une équipe de 5 développeurs iOS, deux développeurs backend et un product manager. Chacun parle pendant 1 à 2 minutes : ce qui a été fait hier, ce qui est prévu aujourd'hui, s'il y a des blocages.
\n\nMa réponse typique ressemble à ceci :
\n\n- \n
- Hier : J'ai terminé le refactoring du module d'authentification avec Combine. \n
- Aujourd'hui : J'intègre le nouvel écran de profil avec SwiftUI, je dois faire l'animation de transition. \n
- Blocage : J'attends les maquettes finales du designer pour le thème sombre. \n
Après le stand-up — 15 minutes pour parcourir les messages dans Jira et GitHub. Je regarde quelles PR nécessitent ma relecture et je lis les commentaires sur mes pull requests.
\n\n09:45 — Première session de travail approfondi : Nouvelle fonctionnalité
\n\nLe matin est le meilleur moment pour les tâches complexes. Aujourd'hui, j'écris le module de notifications Push avec deep linking. Voici à quoi ressemble la structure typique d'une classe de gestionnaire :
\n\nimport 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}\n\nRemarquez l'utilisation de Task { @MainActor in } — c'est une façon moderne de forcer l'exécution sur le thread principal sans utiliser l'ancien DispatchQueue.main.async. Un développeur iOS utilise activement la concurrence (Concurrency) de Swift 5.5+.
11:00 — Code Review : Un regard extérieur
\n\nUne notification arrive d'un collègue : « Regarde ma PR, s'il te plaît ». J'ouvre GitHub, je vois des modifications dans le modèle de données. Voici un exemple de ce que je commente souvent :
\n\n// ❌ Mauvais : force unwrap\nlet user = users.first!\n\n// ✅ Bon : extraction sécurisée\nguard let user = users.first else {\n assertionFailure("La liste users ne devrait pas être vide à ce stade")\n return\n}\n\nLors du code review, nous discutons non seulement de la correction, mais aussi de l'architecture. Aujourd'hui, un collègue a utilisé SwiftUI avec @ObservableObject, mais selon notre guide de style, nous passons à @Observable (iOS 17+). Je fais une remarque discrète :
// Nous recommandons de réécrire avec @Observable\n@Observable\nfinal class ProfileViewModel {\n var name: String = ""\n var age: Int = 0\n}\n\n12:30 — Déjeuner et changement de contexte
\n\nLe déjeuner est sacré. Je sors dehors ou je cuisine moi-même. J'essaie de ne pas regarder l'écran — mes yeux se reposent. Pendant le déjeuner, je lis souvent des messages Telegram