Pourquoi Swift existe : comment il a succédé à Objective‑C sur iOS

Ce que couvre cet article (et à qui il s'adresse)

Swift n'est pas apparu simplement parce qu'Apple voulait un nouveau langage « pour le plaisir ». Il a été conçu en réponse à des points de douleur réels dans le développement iOS : itérations lentes, patterns dangereux faciles à écrire par erreur, et un décalage croissant entre la complexité des apps modernes et la conception plus ancienne d'Objective‑C.

Cet article répond à une question pratique : pourquoi Swift existe, comment il est devenu le langage par défaut, et pourquoi cette histoire influence encore aujourd'hui vos décisions de codebase et d'équipe.

Ce que vous retirerez de cet article

Vous aurez une chronologie claire et légère — des premières versions de Swift à une chaîne d'outils stable et largement adoptée — sans vous perdre dans des détails triviaux. En chemin, nous relierons l'histoire aux conséquences quotidiennes : comment les développeurs écrivent du code plus sûr, comment les API ont évolué, ce qui a changé dans les workflows Xcode, et ce que signifie le « Swift moderne » avec des fonctionnalités comme la concurrence et SwiftUI.

À qui c'est destiné

• Développeurs iOS qui veulent comprendre pourquoi Swift donne une impression différente (et où les angles vifs existaient auparavant).
• Tech leads et managers qui évaluent la modernisation : coût de migration, maintenabilité et recrutement.
• Équipes produit et livraison qui doivent comprendre pourquoi « réécrire vs migration incrémentale » n'est pas une réponse binaire.
• Apprenants qui entendent « Objective‑C est mort » et veulent un modèle mental plus précis.

Une note rapide sur Objective‑C

Objective‑C est encore présent dans de nombreuses apps réussies, surtout dans les bases de code plus anciennes et certaines bibliothèques. L'objectif n'est pas d'alarmer mais d'éclairer : Swift n'a pas effacé Objective‑C du jour au lendemain ; il l'a supplanté progressivement via l'interopérabilité et des changements d'écosystème.

Objective‑C avant Swift : ce qui fonctionnait et ce qui coinçait

Objective‑C a été la fondation du développement Apple pendant des décennies. Quand le premier SDK iPhone est arrivé en 2008, Objective‑C (et les frameworks Cocoa Touch) était le moyen principal de construire des apps, tout comme il l'avait été pour Mac OS X avec Cocoa. Si vous développiez des apps iOS à l'époque, vous appreniez les conventions de la plateforme Apple via Objective‑C.

Ce qui marchait bien

Objective‑C avait beaucoup d'atouts — surtout si l'on adhérait à la « façon Cocoa » de construire le logiciel.

Il reposait sur un runtime dynamique puissant : messaging, introspection, catégories et method swizzling permettaient des patterns flexibles et « plug‑in ». Les conventions Cocoa comme delegation, target–action, notifications et KVC/KVO (key‑value coding/observing) étaient profondément intégrées et bien documentées.

Autre point important : un écosystème mature. Les frameworks Apple, les bibliothèques tierces et des années de réponses sur Stack Overflow supposaient Objective‑C. Les outils et API étaient conçus autour de ce langage, et les équipes pouvaient recruter des développeurs avec des compétences prévisibles.

Ce qui coinçait

Les problèmes n'étaient pas philosophiques — ils étaient pratiques et quotidiens.

Objective‑C pouvait être verbeux, surtout pour des tâches « simples ». Les signatures de méthodes, les crochets et le boilerplate rendaient le code plus long et plus difficile à parcourir. Beaucoup d'API exposaient des concepts lourds en pointeurs, augmentant le risque d'erreurs, en particulier avant la généralisation de l'ARC (Automatic Reference Counting).

La mémoire et la sécurité restaient des sujets : même avec ARC, il fallait comprendre la propriété, les cycles de références et comment la nullabilité pouvait vous surprendre à l'exécution.

L'interfaçage avec les APIs C était courant — et pas toujours agréable. Faire le bridge des types C, gérer Core Foundation et le « toll‑free bridging » ajoutait une charge mentale qui ne ressemblait pas à l'écriture de code applicatif moderne.

Pourquoi c'est encore important

Les bases de code iOS héritées s'appuient souvent sur Objective‑C parce qu'elles sont stables, éprouvées et coûteuses à réécrire. Beaucoup d'apps de longue durée incluent des couches Objective‑C (ou des dépendances anciennes) qui font encore un vrai travail — et le font de manière fiable.

Pourquoi Apple a créé Swift à l'origine

Apple n'a pas créé Swift parce qu'Objective‑C était « cassé ». Objective‑C avait permis des années d'apps iPhone et Mac réussies. Mais à mesure que les apps grandissaient, les équipes s'élargissaient et les API se multipliaient, le coût de certains défauts par défaut d'Objective‑C est devenu plus visible — surtout quand on multiplie de petits risques sur des millions de lignes de code.

Des comportements par défaut plus sûrs (moins d'angles vifs)

Un objectif majeur était de rendre les erreurs courantes plus difficiles à écrire. La flexibilité d'Objective‑C est puissante, mais elle peut masquer des problèmes jusqu'à l'exécution : envoyer des messages à nil, confondre des types id, ou mal gérer la nullabilité des API. Beaucoup de ces problèmes étaient gérables avec de la discipline, des conventions et de bonnes revues, mais restaient coûteux à grande échelle.

Swift intègre des garde‑fous : les optionnels vous obligent à penser « est‑ce que ça peut manquer ? », le typage fort réduit les usages accidentels, et des fonctionnalités comme guard, l'exhaustivité des switch et une manipulation plus sûre des collections déplacent davantage de bugs vers le temps de compilation plutôt que la production.

Syntaxe moderne et potentiel de meilleures performances

Swift a aussi modernisé l'expérience quotidienne d'écriture de code. Une syntaxe concise, l'inférence de type et une bibliothèque standard plus riche rendent beaucoup de tâches plus claires avec moins de boilerplate que les patterns header/implementation, les bricolages de generics ou l'utilisation intensive de macros.

Sur les performances, Swift a été conçu pour permettre des optimisations agressives du compilateur (notamment avec les types valeur et les generics). Cela ne garantit pas qu'une app Swift soit automatiquement plus rapide qu'une app Objective‑C, mais cela fournit à Apple un modèle de langage qui peut évoluer vers la vitesse sans dépendre autant du runtime dynamique.

Apprentissage, lisibilité et maintenabilité à long terme

Apple avait besoin que le développement iOS soit abordable pour les nouveaux développeurs et durable pour les produits de longue durée. Les conventions de nommage des API Swift, l'intention plus claire sur les sites d'appel et l'accent sur des types expressifs visent à réduire le « savoir tribal » et à rendre les bases de code plus faciles à relire plusieurs mois plus tard.

Le résultat : moins de pièges, des API plus propres, et un langage qui aide mieux les grandes équipes à maintenir des apps pendant des années — sans prétendre qu'Objective‑C ne pouvait pas faire le travail.

Une courte chronologie : de Swift 1.0 à un langage mature

Swift n'a pas « gagné » du jour au lendemain. Apple l'a présenté comme une meilleure option pour le code neuf, puis a passé des années à le rendre stable, plus rapide et plus simple à adopter aux côtés des apps Objective‑C existantes.

Jalons clés (Swift 1 → 5)

• 2014 : Swift 1.0 annoncé à la WWDC. L'excitation était là, mais les premières versions ont beaucoup changé — les équipes qui ont adopté très tôt ont dû mettre à jour le code fréquemment.
• 2015 : Swift 2 a mis l'accent sur la productivité (meilleure gestion des erreurs) et, surtout, Swift a été open‑sourcé. Cela a ouvert la porte à plus d'implication communautaire, d'outils tiers et d'expérimentation hors de l'écosystème Apple.
• 2016 : Swift 3 a été la grosse release de « nettoyage ». Elle a introduit des changements majeurs de nommage et de style rendant Swift plus cohérent, mais cela a aussi signifié de larges migrations.
• 2017–2018 : Swift 4 / 4.2 ont amélioré les performances et stabilisé la direction du langage, rendant les montées de version moins disruptives.
• 2019 : Swift 5 a été un tournant grâce à la stabilité ABI.

Pourquoi la stabilité ABI de Swift 5 était importante

La stabilité ABI signifie que le runtime Swift et les bibliothèques standard sont compatibles au niveau binaire entre les versions Swift 5 sur les plateformes Apple. Avant Swift 5, beaucoup d'apps devaient embarquer les bibliothèques Swift dans l'app, augmentant la taille et compliquant la distribution. Avec la stabilité ABI, Swift est devenu plus similaire à Objective‑C en fiabilité d'exécution entre mises à jour d'OS, aidant Swift à paraître « sûr » pour les bases de code de production de longue durée.

Adoption graduelle, par conception

Pendant des années, beaucoup d'équipes ont utilisé Swift pour les nouvelles fonctionnalités tout en laissant des modules cœur en Objective‑C. Ce chemin par étapes — plutôt que la réécriture totale — a rendu l'ascension de Swift pratique pour des apps réelles et des deadlines réelles.

Comment Swift a « remplacé » Objective‑C : interopérabilité, pas réécriture

Swift n'a pas gagné en forçant chaque équipe à jeter du code Objective‑C fonctionnel. Apple a garanti que les deux langages puissent coexister dans la même cible d'app. Cette compatibilité est une grosse raison pour laquelle l'adoption de Swift n'a pas buté dès le premier jour.

Une app, deux langages

Une base de code mixte est normale sur iOS : vous pouvez garder des composants réseau, analytics ou UI en Objective‑C tout en écrivant de nouvelles fonctionnalités en Swift. Xcode supporte cela directement, donc « Swift a remplacé Objective‑C » signifie généralement un changement incrémental, pas une réécriture massive.

Bridging headers et interfaces générées (l'idée générale)

L'interopérabilité fonctionne via deux mécanismes complémentaires :

• Objective‑C → Swift : vous ajoutez un bridging header pour lister les en‑têtes Objective‑C que vous voulez rendre visibles à Swift. Une fois inclus, Swift peut importer ces types et les appeler comme des API normales (avec quelques ajustements de nommage).
• Swift → Objective‑C : Xcode génère un header (souvent nommé YourModuleName-Swift.h) qui expose les classes et méthodes Swift compatibles Objective‑C. On opte en général pour cela avec des attributs comme @objc (ou en héritant de NSObject).

Vous n'avez pas besoin de mémoriser toute la plomberie pour en tirer parti — mais comprendre qu'il y a une étape explicite « exposer ceci à l'autre langage » aide à expliquer pourquoi certains types apparaissent automatiquement et d'autres non.

Patterns d'intégration courants que vous verrez vraiment

La plupart des équipes rencontrent quelques points d'intégration récurrents :

• Appeler des frameworks Objective‑C existants (y compris des bibliothèques internes plus anciennes) depuis Swift.
• Utiliser Swift pour de nouveaux écrans pendant que des view controllers legacy restent en Objective‑C.
• Exposer un service ou une couche modèle Swift à Objective‑C quand une réécriture serait risquée.

Remarque pratique : la migration incrémentale est la norme

Les vraies apps vivent longtemps. L'interopérabilité vous permet de migrer fonctionnalité par fonctionnalité, continuer à livrer et réduire le risque — surtout quand des SDKs tiers, des composants anciens ou des contraintes de temps rendent irréaliste une conversion totale.

Différences de langage qui ont changé le développement iOS

Swift n'a pas seulement modernisé la syntaxe — il a changé l'apparence du code iOS « normal » au quotidien. Beaucoup de patterns qui reposaient auparavant sur des conventions (et des revues attentives) sont devenus des choses que le compilateur peut aider à faire respecter.

Optionnels : rendre le « nil » explicite

Les développeurs Objective‑C avaient l'habitude que l'envoi de messages à nil ne fasse rien silencieusement. Swift rend l'absence explicite avec les optionnels (String?), vous poussant à gérer les valeurs manquantes en amont avec if let, guard ou ??. Cela prévient toute une catégorie de crashs et de bugs liés à « pourquoi ceci est vide ? » — sans prétendre que les erreurs ne peuvent plus arriver.

Inférence de type et generics : moins de casts, plus d'intention

Swift peut inférer les types à de nombreux endroits, ce qui coupe le boilerplate tout en gardant le code lisible :

let title = "Settings" // inferred as String

Plus important, les generics permettent d'écrire du code réutilisable et typé sans s'appuyer sur id et des vérifications runtime. Comparer « tableau de n'importe quoi » versus « tableau de ce que j'attends exactement » réduit les objets inattendus qui se glissent et les casts forcés.

Erreurs, chaînes et collections : des comportements par défaut plus sûrs

Le throw/try/catch de Swift encourage des chemins d'erreur explicites au lieu d'ignorer les échecs ou de propager des NSError **. Les collections sont fortement typées ([User], [String: Int]), et les chaînes sont des String Unicode correctes plutôt qu'un mélange de C strings, NSString et décisions d'encodage manuelles. L'effet net est moins d'erreurs off‑by‑one, moins d'hypothèses invalides et moins de « ça compile mais casse à l'exécution ».

Là où le dynamisme d'Objective‑C reste utile

Le runtime d'Objective‑C reste précieux pour des patterns fortement orientés runtime : method swizzling, forward de messages dynamiques, certaines approches d'injection de dépendances, et du code piloté par KVC/KVO. Swift peut interopérer avec ces mécanismes, mais quand vous avez vraiment besoin de dynamisme à l'exécution, Objective‑C reste un outil pratique.

Outillage et changements d'écosystème : Xcode, Packages et API

Swift n'a pas seulement changé la syntaxe — il a poussé l'écosystème iOS à moderniser ses outils et conventions. Cette transition n'a pas toujours été fluide : les premières versions de Swift pouvaient signifier des builds plus lents, une autocomplétion moins fiable et des refactors plus risqués qu'ils ne devraient l'être. Avec le temps, l'expérience développeur est devenue un des plus grands avantages de Swift.

Xcode a mûri avec Swift

Le support Swift dans Xcode s'est amélioré de façon concrète :

• Fix‑its et diagnostics sont devenus plus utiles. Le typage strict de Swift permet à Xcode de proposer des corrections précises (et pas seulement signaler des erreurs).
• Outils de refactor (rename, extract, mise à jour des sites d'appel) sont plus fiables parce que le compilateur comprend davantage la structure du code.
• Les temps de build sont devenus une considération réelle. Les vérifications à la compilation et les generics Swift peuvent ajouter du coût, surtout dans de grands projets. Les équipes ont appris à surveiller les performances des builds incrémentaux, découper les modules et maîtriser les dépendances.

Si vous avez utilisé Swift aux versions 1.x/2.x, vous vous souvenez peut‑être des aspérités. Depuis, la tendance est constante : meilleur indexage, meilleure stabilité des sources et bien moins de moments « Xcode est perdu ».

Swift Package Manager a simplifié les dépendances

Swift Package Manager (SPM) a réduit le besoin de systèmes de dépendances externes pour beaucoup d'équipes. Au niveau basique, vous déclarez des packages et des versions, Xcode les résout, et la construction s'intègre sans gymnastique de fichiers de projet. Ce n'est pas parfait pour tous les setups, mais pour de nombreuses apps cela a simplifié l'onboarding et rendu les mises à jour de dépendances plus prévisibles.

Les API ont commencé à « sentir » Swift

Les Apple API Design Guidelines ont poussé les frameworks vers un nommage plus clair, de meilleurs comportements par défaut et des types qui communiquent l'intention. Cette influence s'est diffusée : les bibliothèques tierces ont de plus en plus adopté des API Swift‑first, rendant les bases de code iOS modernes plus cohérentes — même quand il y a un bridge Objective‑C en-dessous.

Frameworks aujourd'hui : UIKit en Swift et l'essor de SwiftUI

UIKit n'a pas disparu. La majorité des apps iOS en production s'en appuient encore fortement, surtout pour la navigation complexe, les gestes fins, le traitement avancé du texte et la longue traîne de composants UI éprouvés. Ce qui a changé, c'est que Swift est désormais le moyen par défaut d'écrire du code UIKit — même si le framework sous‑jacent est le même.

UIKit reste l'outil de travail — mais écrit en Swift

Pour beaucoup d'équipes, « app UIKit » n'implique plus Objective‑C. Storyboards, nibs et vues programmatiques sont couramment pilotés par des view controllers et des modèles Swift.

Ce changement compte parce qu'Apple conçoit de plus en plus de nouvelles API en pensant l'ergonomie Swift (nommage plus clair, optionnels, generics, types résultat). Même quand une API existe pour Objective‑C, la surcouche Swift donne souvent l'impression d'être la surface « prévue », ce qui accélère la montée en compétence des nouveaux développeurs dans une base UIKit.

SwiftUI : un framework UI pensé pour Swift qui a influencé l'architecture

SwiftUI n'a pas été qu'une nouvelle façon d'afficher des boutons. Il a poussé un modèle mental différent :

• L'UI est une fonction de l'état, pas une séquence impérative de mises à jour.
• Le flux de données (bindings, observed objects) devient une préoccupation de conception de première importance.

Concrètement, cela a changé les discussions d'architecture. Les équipes qui adoptent SwiftUI mettent souvent l'accent sur le flux de données unidirectionnel, des composants de vue plus petits et l'isolation des effets de bord (réseau, persistance) hors du code de vue. Même si vous n'allez pas « tout faire » en SwiftUI, il simplifie les écrans principalement composés de formulaires, listes et mises en page pilotées par l'état.

Les vraies apps mélangent SwiftUI et UIKit — et c'est normal

Les apps en production combinent fréquemment les deux frameworks :

• Intégrer SwiftUI dans UIKit via UIHostingController pour de nouveaux écrans.
• Envelopper des composants UIKit existants (contrôles personnalisés, vues de carte, caméra, web views) pour les utiliser dans SwiftUI.

Cette approche hybride permet de garder l'infrastructure UIKit mature — piles de navigation, coordinators, design systems existants — tout en adoptant SwiftUI de façon incrémentale là où il apporte un bénéfice clair. Elle maintient aussi le risque à un niveau gérable : vous pouvez piloter SwiftUI sur des zones limitées sans réécrire toute la couche UI.

Les frameworks « Swift‑first » influencent les nouveaux projets

Si vous démarrez aujourd'hui, la nouvelle histoire UI d'Apple est SwiftUI, et beaucoup de technologies adjacentes (widgets, Live Activities, certaines extensions) sont fortement orientées Swift. Même hors UI, les API favorables à Swift sur les plateformes Apple tendent à orienter les choix par défaut : les nouveaux projets sont généralement prévus avec Swift, et la question devient « combien de UIKit avons‑nous besoin ? » plutôt que « devons‑nous utiliser Objective‑C ? »

Le résultat n'est pas tant la disparition d'un framework au profit d'un autre que le fait que Swift devient la langue commune, à la fois pour la voie legacy‑friendly (UIKit) et la voie plus récente, native Swift (SwiftUI).

Swift moderne : concurrence et multithreading plus sûr

La concurrence, c'est la façon dont une app fait plusieurs choses « en même temps » — charger des données, décoder du JSON et mettre à jour l'écran — sans figer l'interface. L'approche moderne de Swift vise à rendre ce travail plus lisible, comme du code normal, et moins comme de la jonglerie de threads.

async/await en langage courant

Avec async/await, vous pouvez écrire du travail asynchrone (comme une requête réseau) dans un style linéaire :

• async marque une fonction qui peut se mettre en pause en attendant quelque chose.
• await est le point « pause ici jusqu'à ce que le résultat soit prêt ».

Au lieu d'imbriquer des handlers de completion, vous le lisez comme une recette : fetch, parse, update.

Concurrence structurée : des tâches avec des règles

Swift associe async/await à la concurrence structurée, ce qui signifie essentiellement : « le travail en arrière‑plan doit avoir un propriétaire et une durée de vie clairs. » Les tâches sont créées dans un scope et les tâches enfants sont liées à leur parent.

Cela améliore :

• Le réseau : les requêtes peuvent être lancées, attendues et relancées de façon prévisible.
• La réactivité UI : le travail lourd reste hors du main thread, tandis que les mises à jour UI restent fluides.
• L'annulation : annuler une tâche parente peut annuler ses enfants, évitant des téléchargements inutiles.

Actors et Sendable : outils de sécurité (haut niveau)

Deux concepts aident à réduire les crashs liés aux accès simultanés :

• Actors protègent l'état mutable de sorte qu'une seule entité l'accède à la fois.
• Sendable est une vérification pour les valeurs sûres à transmettre entre tâches concurrentes.

Réalités d'adoption dans les bases de code réelles

La plupart des équipes n'activent pas tout d'un coup. Il est courant de mélanger la concurrence moderne Swift avec d'anciens patterns — OperationQueue, GCD, callbacks et completion handlers — surtout quand on intègre des bibliothèques legacy ou des flows UIKit plus anciens.

Migrer des apps existantes : stratégies pratiques et pièges

Migrer une vraie app iOS n'est pas un projet « tout convertir » — c'est un projet de gestion des risques. L'objectif est de continuer à livrer tout en réduisant progressivement la part d'Objective‑C à maintenir.

Stratégies qui fonctionnent en production

Une approche courante est la migration incrémentale :

• Commencez par les nouvelles fonctionnalités en Swift. Gardez l'Objective‑C stable et ajoutez des écrans, services ou view models Swift derrière des interfaces bien définies.
• Refactorez ensuite les hotspots. Identifiez les modules crashés, les goulets de performance ou les zones fréquemment modifiées, puis réécrivez ou enveloppez en Swift une fois les tests en place.

Cela vous permet de construire de la confiance tout en contenant le rayon d'impact — particulièrement utile quand les deadlines ne permettent pas de bloquer pour une transition linguistique.

Où les migrations deviennent compliquées

Plusieurs patterns Objective‑C ne se traduisent pas proprement :

• Dépendances tierces Objective‑C. Certaines bibliothèques plus anciennes reposent sur le comportement du runtime et ne sont pas adaptées aux API modernes Swift.
• Réflexion runtime et dispatch dynamique. Le code qui utilise selectors, swizzling ou objc_runtime intensif peut nécessiter une refonte plutôt qu'une traduction.
• Macros et logique du préprocesseur. Swift propose d'autres outils (generics, protocols, build settings), donc le code macro‑heavy devient souvent un petit projet de refactorisation.

Tester pour préserver le comportement

Considérez la migration comme un échange d'implémentation, pas un changement de fonctionnalité. Ajoutez d'abord des tests de caractérisation autour des flux critiques (réseau, cache, paiements, auth), puis portez. Les tests de snapshot aident à détecter les régressions UI quand du code UIKit bouge vers Swift.

Construire une checklist de migration interne

Créez une norme légère pour les équipes : conventions de code, linting (SwiftLint ou équivalent), frontières de module, règles de bridging header et « pas de nouvel Objective‑C sauf justification ». L'écrire empêche la base de code de devenir bilingue de manière incohérente.

Ce que ce changement implique pour les équipes, le recrutement et la maintenance

Swift n'a pas seulement changé la syntaxe — il a changé ce qui est « normal » dans une équipe iOS. Même si votre produit contient encore de l'Objective‑C, les décisions quotidiennes sur les personnes, les processus et la maintenance long terme sont maintenant influencées par des attentes orientées Swift.

Recrutement et onboarding

La plupart des offres iOS supposent Swift par défaut. Les candidats peuvent n'avoir jamais livré en Objective‑C professionnellement, ce qui rallonge le temps d'adaptation si la base est mixte.

Pratique à retenir : considérez la connaissance d'Objective‑C comme un « plus », pas comme un prérequis, et fournissez des docs d'onboarding claires indiquant où l'Objective‑C existe et pourquoi. Un guide interne court sur les bridging headers, la propriété des fichiers et les zones « ne pas toucher sans contexte » évite des erreurs précoces.

Revue de code et architecture

Le typage fort de Swift et les optionnels clairs peuvent rendre les revues plus rapides : les relecteurs passent moins de temps à deviner ce qu'une valeur peut être et plus de temps à valider l'intention. Des patterns comme les protocols, les generics et les types valeur encouragent aussi une architecture plus consistante — lorsqu'ils sont utilisés avec retenue.

Le revers de la médaille est la dérive de style. Les équipes gagnent à avoir un guide de style Swift partagé et du formatage/linting automatisé pour que les revues portent sur le comportement, pas sur l'indentation. (Si vous avez déjà des règles, liez‑les depuis votre hub de docs interne.)

Maintenance long terme et budgétisation

La maintenance devient plus simple quand vous pouvez utiliser directement des API modernes au lieu de porter des wrappers personnalisés construits autour d'anciens patterns. Mais Objective‑C ne disparaîtra pas du jour au lendemain — surtout dans les apps matures avec des modules éprouvés.

Budgetez de façon réaliste pour des bases mixtes : planifiez la migration autour de jalons métier, pas comme un nettoyage sans fin. Définissez ce que signifie « fini » (par ex. tout nouveau code en Swift, modules legacy touchés seulement de façon opportuniste) et revisitez cette règle lors de refactors majeurs.

Pour un cadre de décision, voyez /blog/migrating-objective-c-to-swift.

Comment décider de la suite (nouvelles apps et apps legacy)

Choisir entre Swift et Objective‑C n'est généralement pas un débat philosophique — c'est une décision de coût, de risque et de planning. La bonne nouvelle : vous avez rarement à choisir « tout ou rien ». La plupart des équipes obtiennent le meilleur résultat en faisant évoluer la base de code sur place.

Nouvelles apps : par défaut Swift (avec une stratégie UI claire)

Si vous démarrez un projet, Swift devrait être la valeur par défaut. Il s'aligne sur les API les plus récentes d'Apple, offre de meilleures garanties de sécurité et donne un accès direct aux patterns modernes comme async/await.

Votre première décision porte sur la stratégie UI : UIKit en Swift, SwiftUI ou un mix. Si vous hésitez, comparez les compromis dans /blog/swiftui-vs-uikit.

Apps legacy : introduire Swift là où ça réduit le risque

Pour une app Objective‑C existante, conservez les modules stables et testés en Objective‑C et introduisez Swift là où vous en tirerez un bénéfice rapide :

• nouvelles fonctionnalités/écrans qui auraient complexifié l'ancienne architecture ;
• zones sujettes à plantages ou problèmes de threading ;
• réseau, parsing et logique métier pouvant être isolés derrière des interfaces propres.

Règle pratique : créez un nouveau module Swift quand vous pouvez définir des frontières claires (surface API, propriété, tests). Gardez Objective‑C stable quand le code est mature, fortement imbriqué ou risqué à toucher sans refactor global.

Pour la planification, consultez /blog/ios-migration-checklist.

Un parcours d'apprentissage aligné avec le travail réel

Pour les individus et les équipes, cette séquence correspond bien au développement iOS quotidien :

1. Fondamentaux Swift (types, optionnels, gestion d'erreurs)
2. Bases UIKit et/ou SwiftUI
3. Concurrence (async/await, actors, annulation de tâches)
4. Packaging et réutilisation (Swift Package Manager)

Une façon pragmatique d'accélérer (sans tout réécrire)

La modernisation iOS met souvent en lumière du travail « adjacent » qui concurrence le même temps ingénierie : dashboards admin, outils internes, services backend et APIs dont l'app dépend. Si vous voulez garder votre équipe iOS concentrée sur la migration vers Swift tout en continuant à livrer le logiciel de support, Koder.ai peut vous aider à lancer des web apps, backends Go (avec PostgreSQL) ou apps compagnon Flutter via un workflow piloté par chat — puis exporter le code source, déployer et gérer les itérations avec snapshots/rollback.

Si vous voulez de l'aide externe pour cadrer la prochaine étape la plus sûre — nouveau module, migration partielle ou « ne rien toucher » — voyez /pricing.