Entretien blanc iOS Developer — pratique avec l'IA

Les entretiens iOS vivent dans un entre-deux étrange — la moitié des questions supposent que vous avez grandi avec UIKit, l'autre moitié suppose que vous livrez en SwiftUI dès demain, et presque toutes les équipes ont une base de code qui mélange les deux. Les candidats qui décrochent des offres sont ceux qui savent parler de Swift, du lifecycle et de la concurrence avec la précision de la documentation d'Apple. Ce guide explique comment utiliser les entretiens blancs IA pour répéter le loop spécifique iOS sans perdre de temps sur des questions mobiles génériques.

Les tours d'entretien typiques pour les iOS developers

Le loop iOS compte 4 à 5 tours. Screening recruteur, un screening technique téléphonique sur les fondamentaux Swift (types valeur vs référence, optionals, generics, protocols, gestion d'erreur), un tour de coding SwiftUI ou UIKit (construire une petite fonctionnalité en direct ou en takehome), un tour d'architecture et de system design (« comment structureriez-vous cette fonctionnalité offline-first »), et un tour behavioral. Les loops senior ajoutent une revue d'architecture de projets passés et un deep dive spécifique à Apple (soumission App Store, code signing, privacy manifests).

Le tour d'architecture est celui où les entretiens blancs IA rapportent le plus. Il colle précisément au format : énoncé ouvert, relances sur le threading, le state et les frontières de dépendances. Le tour de fondamentaux Swift convient aussi à l'entretien blanc — c'est une conversation, pas un test de coding. Le live-coding SwiftUI pur est plus difficile à simuler ; associez la session IA à Xcode dans une fenêtre à côté.

Les principaux sujets techniques

Le langage Swift en profondeur

Le recruteur suppose une aisance Swift. Soyez prêt : types valeur vs référence et les implications pour la thread safety, copy-on-write (Array, Dictionary, String), protocols avec associated types et comment ils contraignent les generics, la différence entre some View et any View, la gestion d'erreur avec Result et les throwing functions, property wrappers (et pourquoi @State, @StateObject, @Binding, @ObservedObject se comportent différemment), strong vs weak vs unowned. Un piège courant : les closures et les capture lists — savoir expliquer pourquoi [weak self] importe et quand utiliser [unowned self].

SwiftUI

Les questions SwiftUI se concentrent sur le state et l'identité des vues. Soyez prêt : le protocol View et la magie du type de retour du body, quand SwiftUI redessine (mutation de state, changement d'environnement, re-render du parent), comment l'identité pilote le diffing (.id(), ForEach avec des identifiants stables), le piège du @State dans un parent vs @Binding vers un enfant, les différences de lifecycle entre @StateObject et @ObservedObject, les Environment values et l'injection de dépendances, les primitives d'animation et matchedGeometryEffect. Un énoncé favori : « la liste scintille quand je mets à jour un seul élément — diagnostiquez. »

Interop UIKit et legacy

Même les projets greenfield gardent UIKit pour les ViewControllers, les layouts de collection complexes et le travail AVPlayer/AVKit. Soyez prêt : le lifecycle des ViewControllers (viewDidLoad vs viewWillAppear vs viewDidAppear), UICollectionView avec compositional layout et diffable data sources, la responder chain, les gestures et le hit testing, UIRepresentable et UIViewControllerRepresentable pour héberger UIKit dans SwiftUI (et l'inverse avec UIHostingController). Le recruteur sondera si vous savez débugger une base de code mixte sans en réécrire la moitié.

Concurrence

Swift Concurrency est désormais incontournable. Soyez prêt : la sémantique async/await, la concurrence structurée avec TaskGroup, Sendable et le modèle d'acteurs, MainActor et le global executor, le piège de capturer self à l'intérieur d'une Task, AsyncSequence et AsyncStream. Soyez prêt à comparer à GCD et Combine — la plupart des fiches mentionnent les trois. Une question favorite : « vous avez 100 téléchargements d'images, vous voulez limiter la concurrence à 5 — écrivez la version en concurrence structurée. »

Architecture

MVVM domine mais les recruteurs attendent que vous connaissiez les alternatives : MVC (toujours l'architecture par défaut des exemples de code d'Apple), MVP, MVI, TCA (The Composable Architecture de Point-Free), VIPER (plus ancien mais vivant dans les bases de code d'entreprise), Clean Architecture. Soyez prêt à plaider pour l'une dans un contexte donné et à refactorer un fouillis MVC sans réécriture big-bang. Le recruteur esquisse souvent une fonctionnalité pendant l'appel et vous demande de parler structure de fichiers, direction des dépendances et testabilité.

La livraison spécifique à Apple

Les loops senior creusent : App Store Connect, TestFlight, code signing, provisioning profiles, App Transport Security, le privacy manifest (Required Reason APIs), background modes, push notifications et APNs, deep links et universal links, App Intents et Shortcuts. Les loops junior sautent l'essentiel de cela. Si le poste est senior ou staff, travaillez-le ; s'il est mid ou junior, tenez une vue d'ensemble fonctionnelle.

Questions de scénario courantes

• « Concevez une fonctionnalité de notes offline-first avec synchronisation. CoreData vs SQLite, résolution de conflits, états d'UI. »
• « Votre liste SwiftUI scintille quand une ligne se met à jour. Déroulez-moi le diagnostic. » (Identité, ownership du state, recréation de vue.)
• « Implémentez un téléchargeur d'images à 5 tâches concurrentes avec la concurrence structurée. »
• « L'app crashe sur iOS 17 mais pas sur 18. Comment commencez-vous le débogage ? » (Crash log symbolisé, sysdiagnose, revue des deprecations.)
• « Vous héritez d'une base de code UIKit. L'équipe veut migrer vers SwiftUI. Feuille de route ? » (Par écran, hosting, modèles partagés, risque et rollback.)

Axes behavioral — ce que les recruteurs recherchent

Les recruteurs iOS recherchent trois traits. D'abord, le respect du langage de design d'Apple et du système — les candidats qui combattent systématiquement les conventions UIKit/SwiftUI sont filtrés. Ensuite, la discipline App Store — vous avez livré à travers la review, vous savez ce qui déclenche un refus, vous avez géré une review expédiée en urgence. Enfin, l'attention à la mémoire et à l'énergie — les utilisateurs iOS remarquent quand une app vide la batterie ; les recruteurs iOS remarquent quand un candidat ne s'en soucie pas. Attendez-vous à au moins un énoncé qui touche l'un de ces points (un refus d'App Review mémorable, une fuite mémoire que vous avez traquée, un choix de design fait pour respecter le système).

Comment utiliser l'entraînement IA pour ce poste

Réglez le type d'entretien sur « Tech Screening » et choisissez iOS comme plateforme. L'IA pondère les questions vers Swift, l'interop SwiftUI/UIKit et la concurrence. Collez la fiche de poste quand vous en avez une — les rôles Swift-only posent des questions différentes des bases de code qui ont encore de l'Objective-C.

Pour la pratique d'architecture, lancez des sessions « System Design » avec des énoncés spécifiques iOS : app offline-first, client de chat temps réel, fonctionnalité AR, compagnon Watch. L'IA poussera sur les parties que le system design web ignore : gestion de l'énergie, limites du background, les pièges du lifecycle.

Un exercice qui paie vite : choisissez une fonctionnalité SwiftUI que vous avez livrée et faites mener à l'IA un entretien identité-et-state. « Déroulez-moi ce qui déclenche une réévaluation du body ici. » L'entretien blanc fait remonter les lacunes de votre propre modèle mental du framework — et ce sont exactement celles que trouvent les recruteurs.

Questions fréquentes