Swift, SwiftUI, une architecture MVVM ou TCA, des tests, la CI et la publication sur l'App Store : la liste revient dans les offres de développeur iOS SwiftUI. Beaucoup gardent une part d'UIKit : écrans anciens, SDK tiers, intégration progressive dans une application existante. Depuis le 28 avril 2026, les applications envoyées sur l'App Store doivent être construites avec Xcode 26 et le SDK iOS 26, et de nombreuses équipes passent leur code en mode Swift 6, avec sa vérification stricte de la concurrence.
SwiftUI s'apprend vite pour des écrans simples, et beaucoup de CV s'arrêtent là. La différence se voit sur la gestion d'état : @State, @Binding, @Observable et @Environment ont chacun leur rôle, et un mauvais choix donne des vues qui perdent leurs données ou se recalculent sans cesse. Elle se voit aussi sur la navigation, les longues listes et le passage par UIKit.
Demandez quelle version minimale d'iOS ciblait la dernière application, ce qui restait en UIKit et pourquoi, et comment l'équipe est passée d'ObservableObject à @Observable. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Swift, SwiftUI et les frameworks qui les entourent
Swift 6 et la concurrence
Le langage d'Apple, en version 6.4 depuis septembre 2026. Le mode Swift 6 vérifie à la compilation les accès concurrents aux données : async/await, acteurs, types Sendable, isolation sur le MainActor. Depuis Swift 6.2, un module peut isoler par défaut son code sur le MainActor, réglage recommandé pour les apps.
SwiftUI
Le framework d'interface déclaratif d'Apple, apparu en 2019. On décrit les vues en fonction de l'état, et SwiftUI recalcule ce qui a changé. Chaque version d'iOS ajoute des API, donc la version minimale ciblée par l'application fixe ce que le développeur peut utiliser.
Observation (@Observable)
Le framework Observation, disponible depuis iOS 17, remplace ObservableObject et @Published. Une vue n'est recalculée que si elle lit une propriété qui a changé. Avec Xcode 27, @State devient une macro et un objet stocké dans @State n'est créé qu'une fois par durée de vie de la vue.
Combine
Le framework réactif d'Apple, avec ses publishers et ses opérateurs. Il recule au profit d'async/await et d'Observation, mais reste présent dans beaucoup de bases de code et de view models écrits avant iOS 17.
Navigation SwiftUI
NavigationStack et NavigationSplitView, arrivés avec iOS 16, pilotent la navigation à partir d'un chemin de données et de navigationDestination. C'est ce qui rend possibles les liens profonds et la restauration de la navigation. L'ancien NavigationView est déprécié.
Interopérabilité UIKit
UIViewRepresentable et UIViewControllerRepresentable intègrent une vue UIKit dans SwiftUI, UIHostingController fait l'inverse. Indispensable pour un SDK tiers, une caméra, une carte personnalisée ou une migration écran par écran.
SwiftData et Core Data
Core Data est la persistance historique d'iOS. SwiftData, depuis iOS 17, la reprend avec des modèles déclarés en Swift (@Model) et des requêtes intégrées aux vues (@Query). Demandez ce que la personne a fait des migrations de schéma.
Tests, Instruments et publication
XCTest et Swift Testing pour les tests unitaires, XCUITest pour les parcours, #Preview pour les aperçus. Instruments propose un instrument SwiftUI qui montre les vues recalculées trop souvent. La signature, TestFlight et App Store Connect servent à livrer.
Sur une application récente qui cible iOS 17 ou plus, le développeur peut écrire presque tout en SwiftUI, avec Observation et SwiftData. Sur une application plus ancienne, SwiftUI arrive écran par écran dans une base UIKit, avec des view models en Combine et des coordinators pour la navigation. Les deux postes n'attendent pas le même profil : le premier demande une maîtrise fine des API récentes, le second une bonne connaissance d'UIKit et des ponts entre les deux. Indiquez dans l'offre la version minimale d'iOS et la part d'UIKit.
Les compétences SwiftUI à valider en entretien
- Gestion d'état SwiftUI
- Observation et flux de données
- Navigation SwiftUI
- Concurrence Swift 6
- Interopérabilité UIKit
- Performance, tests et publication
Ce que le candidat doit expliquer sur l'état et le rendu SwiftUI
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Une vue enfant doit modifier un compteur affiché par son parent. Comment le lui passez-vous ?
Une bonne réponseLe parent possède la valeur dans @State et la transmet à l'enfant par un @Binding ($compteur). L'enfant lit et modifie la valeur sans la posséder. Pour un objet @Observable partagé, l'enfant reçoit l'objet lui-même, et @Bindable sert quand il faut des bindings sur ses propriétés.
Signal d'alerteDéclarer dans l'enfant un second @State initialisé avec la valeur du parent, qui se désynchronise dès la première modification.
Question 2 · confirmé
Une liste de 5 000 éléments saccade au défilement. Que regardez-vous ?
Une bonne réponseUne List ou un LazyVStack qui ne construit que les lignes visibles, des identifiants stables (Identifiable, pas l'index du tableau), aucun calcul lourd ni formatage dans body, des images chargées et redimensionnées hors du thread principal. Elle mesure avec l'instrument SwiftUI d'Instruments pour voir quelles vues se recalculent et combien de temps prend leur body.
Signal d'alerteUn VStack dans un ScrollView qui construit les 5 000 lignes d'un coup, ou id: \.self sur des valeurs qui ne sont pas uniques.
Question 3 · confirmé
Une notification doit ouvrir directement le détail d'une commande, trois écrans plus loin. Comment le faites-vous avec NavigationStack ?
Une bonne réponseUn NavigationStack lié à un chemin (NavigationPath ou tableau de valeurs typées) détenu par un objet de navigation, des navigationDestination par type de valeur. À la réception de la notification, on remplit le chemin avec les étapes voulues. Le même mécanisme sert à restaurer la navigation et à revenir à la racine en vidant le chemin.
Signal d'alerteDes NavigationLink avec isActive, dépréciés, et un booléen par écran, ou encore NavigationView.
Question 4 · senior
En passant le projet en mode Swift 6, le compilateur signale des dizaines d'erreurs de concurrence. Comment les traitez-vous ?
Une bonne réponseElle active la vérification stricte module par module, marque @MainActor les modèles qui alimentent l'interface, rend Sendable les types partagés (structures immuables, acteurs pour l'état mutable partagé) et isole les accès aux API anciennes. Elle connaît l'isolation par défaut sur le MainActor proposée depuis Swift 6.2 et Xcode 26, et réserve @unchecked Sendable et nonisolated(unsafe) à des cas justifiés et commentés.
Signal d'alerteDes @unchecked Sendable partout pour faire taire le compilateur, ou rester en Swift 5 sans plan.
Question 5 · confirmé
Un SDK de paiement ne fournit qu'un UIViewController. Comment l'intégrez-vous dans un écran SwiftUI ?
Une bonne réponseUn UIViewControllerRepresentable qui crée le contrôleur dans makeUIViewController et le met à jour dans updateUIViewController, avec un Coordinator qui reçoit les callbacks du délégué et les transmet à SwiftUI par un binding ou une closure. Elle veille à ne pas recréer le contrôleur à chaque mise à jour et à éviter un cycle de références avec le délégué.
Signal d'alerteRécupérer le rootViewController de la fenêtre et présenter le SDK par-dessus SwiftUI.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
SwiftUI, UIKit, Swift 6 : vos questions de recruteur
Un développeur UIKit peut-il passer sur un poste SwiftUI ?
Oui, à condition d'accepter de changer de logique. Il connaît déjà Swift, le cycle de vie de l'application, la signature et la publication, ce qui fait gagner du temps. La difficulté est de cesser de piloter les vues pour décrire l'état, et de savoir quelle donnée appartient à quelle vue. Vérifiez en entretien le passage d'un compteur entre deux vues et une navigation par chemin de données.
Quel test technique pour un développeur iOS SwiftUI ?
Plutôt qu'un projet à rendre, préparez un petit projet Xcode avec deux ou trois défauts réels : un état dupliqué entre parent et enfant, une liste sans identifiants stables, un chargement lancé dans onAppear et jamais annulé. La personne les corrige en direct en commentant à voix haute, puis écrit un test unitaire sur le modèle. En une heure, vous voyez sa lecture de code, ses réflexes SwiftUI et sa façon de tester.
Faut-il exiger TCA ou une architecture précise ?
Seulement si votre code existant repose dessus et qu'il est volumineux. TCA a ses conventions et son outillage, qu'un développeur confirmé apprend en quelques semaines. Ce qui compte davantage, c'est la séparation entre état, logique et affichage, la testabilité et la capacité à justifier un choix. Un candidat qui défend une seule architecture sans en connaître les coûts mérite plus de vigilance qu'un candidat qui ne connaît pas TCA.
Peut-on recruter un développeur iOS qui ne connaît que SwiftUI ?
Pour une application récente sans UIKit, c'est possible. Dans la plupart des projets, il reste un SDK tiers, un écran ancien ou une API absente de SwiftUI qui oblige à passer par UIKit. Un profil purement SwiftUI doit au moins savoir écrire un UIViewRepresentable et lire un contrôleur UIKit. Posez la question de l'intégration d'un SDK fourni uniquement en UIKit pour mesurer ce point.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
