Le développeur iOS UIKit arrive presque toujours sur une app existante. Il reprend des contrôleurs de vue, des contraintes Auto Layout posées dans des storyboards ou en code, des listes en UICollectionView et souvent un socle Objective-C relié à Swift par un bridging header. Le travail mêle corrections, nouvelles fonctions et modernisation : cycle de vie par scènes, data sources diffables, puis SwiftUI par UIHostingController.
Le risque vient des profils arrivés sur iOS ces dernières années. Beaucoup n'ont écrit que du SwiftUI et découvrent sur le poste le cycle de vie d'un UIViewController, les cycles de références dans les closures ou la lecture d'un header Objective-C. À l'inverse, un développeur Objective-C de longue date peut ignorer la concurrence Swift et le mode Swift 6. Faites préciser la part de chaque langage et le nombre d'écrans de la dernière app.
Apple pousse aussi à moderniser. Depuis le 28 avril 2026, l'App Store exige des builds faits avec Xcode 26 et le SDK iOS 26, et le cycle de vie UIScene devient obligatoire pour les apps compilées avec le SDK suivant. Un candidat qui a déjà migré un AppDelegate vers un SceneDelegate a touché aux parties sensibles d'une app. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
UIKit, Objective-C et les outils d'une app iOS établie
UIKit et UIViewController
Le framework d'interface historique d'iOS. Chaque écran est un contrôleur de vue avec un cycle de vie précis : viewDidLoad, viewWillAppear, viewIsAppearing, viewDidAppear. Une bonne partie des bugs d'une app UIKit vient d'un code placé au mauvais moment de ce cycle.
Auto Layout, storyboards et XIB
Le système de contraintes qui place les vues selon la taille de l'écran, posé dans Interface Builder ou en code avec les anchors. Un conflit de contraintes s'affiche dans la console et donne des écrans faux sur certains appareils. Les grandes équipes évitent souvent les storyboards géants, qui créent des conflits Git.
UICollectionView, compositional layout et diffable data source
La liste et la grille d'UIKit. Le compositional layout décrit la mise en page par sections, la diffable data source applique les changements par snapshot au lieu d'appels manuels à reloadData. Beaucoup d'apps gardent aussi des UITableView, qui acceptent les mêmes snapshots.
Objective-C et bridging avec Swift
Le langage d'origine des apps iOS. Le bridging header expose l'Objective-C à Swift, le header généré fait l'inverse pour les classes marquées @objc. Sans annotations de nullabilité dans les headers, Swift reçoit des optionnels implicites, source fréquente de crashs à la frontière.
ARC, Instruments et Memory Graph
ARC compte les références et libère les objets, en Swift comme en Objective-C, mais ne casse pas les cycles. Un délégué déclaré strong ou une closure qui capture self suffit à créer une fuite. Instruments et le Memory Graph Debugger de Xcode servent à les trouver.
GCD et concurrence Swift
Le code ancien utilise Grand Central Dispatch et OperationQueue, le code récent async/await et les actors. UIKit est annoté @MainActor, et le mode Swift 6 transforme en erreurs de compilation les accès concurrents mal protégés. Mélanger les deux modèles sans règle d'équipe pose souvent problème.
UIHostingController et UIHostingConfiguration
Les ponts vers SwiftUI. UIHostingController insère un écran SwiftUI dans une navigation UIKit, UIViewRepresentable fait l'inverse, UIHostingConfiguration permet d'écrire le contenu d'une cellule en SwiftUI. La migration se fait en général écran par écran, en commençant par les nouveaux.
Xcode, signature, SPM et TestFlight
Xcode pour le build, Swift Package Manager ou CocoaPods pour les dépendances, certificats et profils de provisionnement pour la signature, TestFlight puis App Store Connect pour la publication. Le dépôt central de CocoaPods passe en lecture seule en décembre 2026, ce qui pousse les équipes vers SPM.
Le poste change avec l'âge du code. Sur une app de plusieurs centaines d'écrans, le développeur passe plus de temps à lire qu'à écrire, et une régression sur un écran ancien se paie en avis négatifs sur l'App Store. Sur une base plus récente, UIKit sert surtout de structure de navigation autour d'écrans SwiftUI. Certaines équipes figent l'Objective-C et n'y touchent que pour corriger, d'autres le réécrivent module par module. Indiquez dans l'offre la part d'Objective-C, la version minimale d'iOS supportée et l'état de la migration, car un candidat à l'aise en Swift peut ne jamais avoir maintenu de code sans ARC ni de storyboard partagé.
Six compétences à vérifier chez un développeur UIKit
- Cycle de vie UIKit et scènes
- Auto Layout et listes UICollectionView
- Objective-C et interopérabilité Swift
- Mémoire ARC et performances
- Concurrence GCD et Swift 6
- Migration progressive vers SwiftUI
Ce qu'on demande à un développeur UIKit / Objective-C en entretien
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 · confirmé
Dans un UIViewController, où placez-vous le code qui dépend de la taille de la vue ou des traits d'affichage, et pourquoi pas dans viewDidLoad ?
Une bonne réponseviewDidLoad sert à la configuration faite une seule fois par instance : sous-vues, contraintes, abonnements. La géométrie n'y est pas encore définitive. Ce qui dépend de la taille ou des traits va dans viewIsAppearing, ajouté avec le SDK iOS 17 et disponible jusqu'à iOS 13, ou dans viewWillLayoutSubviews en sachant qu'elle est appelée souvent. Un profil à jour sait que traitCollectionDidChange est déprécié au profit de registerForTraitChanges.
Signal d'alerteTout dans viewDidLoad, calculs de frames compris. Ou du code de chargement dans viewWillAppear sans savoir qu'il s'exécute à chaque retour sur l'écran.
Question 2 · junior à confirmé
La console affiche « Unable to simultaneously satisfy constraints » sur un écran qui semble correct. Comment trouvez-vous la contrainte en cause, et que corrigez-vous ?
Une bonne réponseLa lecture du journal d'abord : la liste des contraintes en conflit et celle qu'Auto Layout a cassée. Puis le View Debugger de Xcode, des identifiants posés sur les contraintes pour les reconnaître et le point d'arrêt symbolique UIViewAlertForUnsatisfiableConstraints. Les causes fréquentes sont une hauteur fixe face à un contenu dynamique, translatesAutoresizingMaskIntoConstraints resté à true sur une vue créée en code, ou des priorités toutes à 1000. La correction passe par une priorité abaissée ou une contrainte retirée.
Signal d'alerte« Ça s'affiche bien, on laisse. » Ou des contraintes supprimées au hasard jusqu'à ce que le message disparaisse.
Question 3 · confirmé
Une méthode Objective-C renvoie parfois nil, et l'app plante côté Swift avec « unexpectedly found nil ». Que s'est-il passé, et comment corrigez-vous la frontière entre les deux langages ?
Une bonne réponseSans annotation de nullabilité, Swift importe le retour en optionnel implicitement déballé (String!) et plante au premier accès si la valeur vaut nil. La correction se fait dans le header : nullable ou nonnull sur chaque déclaration, ou un bloc NS_ASSUME_NONNULL_BEGIN/END avec les exceptions marquées. Côté Swift, le cas nil est traité explicitement. Un bon profil cite aussi NS_SWIFT_NAME pour donner un nom propre à une API et les génériques légers (NSArray<NSString *> *) pour éviter des [Any].
Signal d'alerteDes ! ajoutés côté Swift pour faire taire le compilateur, ou aucun header Objective-C ouvert dans les dernières années.
Question 4 · confirmé
La mémoire monte à chaque ouverture et fermeture d'un écran de détail. Comment trouvez-vous la fuite, et quelles causes cherchez-vous en premier ?
Une bonne réponseIl reproduit le parcours plusieurs fois, ouvre le Memory Graph Debugger de Xcode ou Instruments (Leaks, Allocations avec marquage des générations) et vérifie que le deinit du contrôleur est appelé. Les causes classiques : une closure stockée qui capture self sans [weak self], un délégué déclaré strong, un Timer ou un CADisplayLink qui retient sa cible, un observateur NotificationCenter à base de bloc jamais retiré.
Signal d'alerte« ARC gère tout. » Ou [weak self] posé partout par réflexe, sans savoir quel cycle il casse.
Question 5 · confirmé
Le nouvel écran de profil doit être écrit en SwiftUI, dans une app entièrement UIKit qui navigue avec un UINavigationController. Comment l'intégrez-vous ?
Une bonne réponseUn UIHostingController poussé dans la navigation existante, avec un modèle observable partagé avec le code UIKit (@Observable, ou ObservableObject si la version minimale d'iOS est plus ancienne que 17). La navigation reste côté UIKit, par un coordinator ou une closure passée à la vue, pour ne pas gérer deux piles. Quand la vue SwiftUI est intégrée comme enfant d'un écran UIKit, il vérifie le dimensionnement du contrôleur hébergé (sizingOptions) et le comportement de la barre de navigation.
Signal d'alerteToute la navigation réécrite en SwiftUI pour un seul écran, ou aucune idée de la façon dont l'écran SwiftUI renverra une action au code UIKit.
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
Recruter sur une base UIKit, les points qui reviennent
Objective-C est-il encore un critère de recrutement ?
Tout dépend de votre code. Si l'app contient des modules Objective-C encore modifiés, la lecture du langage est indispensable, et l'écriture utile pour les corrections. Si l'Objective-C est figé derrière des interfaces stables, savoir le lire et comprendre la frontière avec Swift suffit en général. Regardez la part réelle dans votre dépôt avant de rédiger l'offre, car l'exigence écarte une partie des profils formés récemment.
Que perd-on en recrutant un profil 100 % SwiftUI sur une base UIKit ?
Le temps d'apprentissage du cycle de vie des contrôleurs, d'Auto Layout et des listes UIKit, d'autant plus long que l'app est grosse. Le risque est plus grand sur la mémoire : les cycles de références d'UIKit, avec délégués et closures, ne se présentent pas de la même façon en SwiftUI. Un profil SwiftUI solide reste un bon choix si un développeur UIKit de l'équipe relit son code au début et si la migration fait partie de la feuille de route.
Comment construire un exercice à partir de votre propre code UIKit ?
Prenez un écran réel, simplifié et sans données sensibles, avec un défaut connu : une fuite de mémoire, un conflit de contraintes, une liste qui saccade. Demandez au candidat de trouver la cause en direct, Xcode ouvert, en commentant ce qu'il fait. Ce test technique d'une heure dit plus qu'un projet à rendre en une semaine, et il montre comment la personne lit un code qu'elle n'a pas écrit.
Apple impose-t-il de quitter UIKit ?
Non. UIKit reste maintenu et reçoit de nouvelles API à chaque version d'iOS, et SwiftUI s'appuie encore sur lui dans beaucoup d'apps. Apple impose en revanche des changements à l'intérieur d'UIKit : le cycle de vie par scènes pour les apps compilées avec le SDK qui suit iOS 26, les nouvelles versions de Xcode pour publier, et le nouveau design des composants. Un développeur UIKit doit suivre ces évolutions, pas forcément tout réécrire.
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.
