L4 / IC3 · 3 à 5 ans
Préparation entretien iOS Engineer, ce qui vous attend
Si vous préparez un process iOS Engineer, la trame est reconnaissable dans la plupart des boîtes tech : un pré-screen recruteur, un round de coding Swift, un round de system design à la sauce mobile, souvent un deep-dive sur un projet de votre CV, et un comportemental avec le hiring manager. La barre, c'est l'aisance en Swift, le confort avec le cycle de vie iOS et le modèle de threading, et la capacité à parler architecture UI sans se réfugier derrière un « de toute façon on est passés à SwiftUI ».
Le point clé à comprendre : on évalue si vous écrivez du Swift comme un ingénieur iOS de production (sémantique de valeur, weak self, MainActor, cycle de vie), pas seulement la justesse algorithmique. Les loops Apple sont un cas à part (rounds de coding plus longs, moins de LeetCode) ; ce guide reflète la barre iOS plus large, des équipes mobiles des grands produits français comme des filiales tech américaines. Le candidat L4 / IC3 est calibré sur le fait de porter une feature ou un écran de bout en bout : design, implémentation, A/B test, rollout.
Version personnalisée
Ce guide couvre la barre générale pour iOS Engineer. L'extension Chrome applique la même préparation à chaque offre que vous ouvrez, questions prédites pour cette entreprise précise, entraînement vocal avec votre coach IA sur chaque réponse, benchmark de salaire, analyse des écarts, plus brouillons de lettre de motivation et d'auto-présentation. Premier rapport gratuit ; plans payants à partir de 3,99 $. Ou lancez un scan unique sur une offre, sans installer.
Mise à jour 2026
Ce guide couvre la barre générale pour iOS Engineer. Quelques choses ont changé en France en 2026, l'AI Act encadre le recrutement IA à partir du 2 août, 31 % des candidats utilisent déjà l'IA pour préparer (APEC), les mises en situation remplacent les tests classiques, et le cycle de recrutement reste à 12 semaines. Lire ce qui a changé en 2026 →
Ce qui sera attendu de vous
- Porter une feature ou un écran de bout en bout : spec, implémentation, A/B test, rollout progressif
- Écrire du Swift de production : Swift Concurrency (async/await, actors), Combine, UIKit et/ou SwiftUI
- Cadrer les contrats d'API avec le back-end ; gérer explicitement les chemins offline et réseau dégradé
- Participer à l'astreinte sur l'app ; débugger les crashs et les freezes en production
- Optimiser la taille de l'app, la batterie et le temps de démarrage à froid ; produire les rapports Instruments associés
- Faire les code reviews des juniors ; faire monter les conventions Swift de l'équipe au fil du temps
Process d'entretien typique
La plupart des entreprises suivent une trame similaire pour les entretiens iOS Engineer. Délai calendaire total : 3 à 5 semaines du pré-screen recruteur jusqu'à l'offre.
Questions types à anticiper
Représentatives de ce que les entreprises demandent à ce niveau, pas une liste exhaustive. Lancez le scan gratuit ci-dessus pour des questions prédites liées à une offre d'emploi précise. L'extension Chrome ajoute l'entraînement vocal avec coaching IA sur chaque réponse (technique, design système, comportemental, motivation).
- “Quelle est la différence entre sémantique de valeur et sémantique de référence en Swift ? Quand choisissez-vous un struct plutôt qu'une class, et qu'est-ce que ça change pour la mutation et le partage d'état ?”
- “Vous capturez self dans une closure passée à un service réseau qui retient cette closure. Qu'est-ce qui se passe niveau mémoire, et comment l'écrivez-vous correctement ? Détaillez weak self, unowned, et quand l'un casse plutôt que l'autre.”
- “Expliquez MainActor et l'isolation des actors. Vous avez une fonction qui met à jour une vue depuis un callback réseau, comment garantissez-vous qu'elle s'exécute sur le main thread avec Swift Concurrency, et qu'est-ce que le compilateur vérifie pour vous ?”
- “Déroulez le cycle de vie d'un UIViewController (et l'équivalent SwiftUI). Où placez-vous le chargement de données, où libérez-vous les ressources, et quel piège classique guette si on s'abonne à un publisher dans viewDidLoad ?”
- “Implémentez une classe qui télécharge des images depuis une liste d'URLs en concurrence, les met en cache par URL, et ne dépasse jamais 4 téléchargements simultanés. Utilisez Swift Concurrency.”
- “Une app iOS voit sa mémoire grimper régulièrement pendant un scroll, sans crasher, juste en montant. Comment déterminez-vous si c'est une fuite, un retain cycle ou une croissance de cache ? Quels outils Instruments, dans quel ordre ?”
- “Designez une app de to-do offline-first qui se synchronise au back-end quand l'appareil revient en ligne. Couvrez la résolution de conflits et ce qui se passe si une sync est interrompue en plein vol.”
- “Designez une librairie de chargement d'images type SDWebImage ou Kingfisher. Couvrez cache mémoire vs disque, l'annulation, et la gestion d'une image de 10 Mo qui arrive sur une cellule de liste.”
- “Designez le feed d'images d'une app sociale (style Instagram ou le feed Vinted) : préchargement, recyclage des cellules, décodage hors main thread, et pagination quand on scrolle vite.”
- “Designez un handler de notifications push qui doit mettre à jour des données locales et afficher une UI personnalisée avant que l'utilisateur n'ouvre l'app. Couvrez le comportement en background et le chemin du silent push.”
- “Parlez-moi d'une feature que vous avez shipée et qui a cassé en production. Comment l'avez-vous découvert, et qu'avez-vous changé dans les pratiques de l'équipe ?”
- “Racontez une fois où vous avez tenu tête à un designer ou un PM sur une feature que vous pensiez infaisable proprement sur iOS.”
- “Décrivez une optimisation de taille d'app ou de performance que vous avez faite. Quelle métrique, et qu'avez-vous mesuré pour prouver que ça marchait ?”
Benchmark de salaire
Salaire médian pour iOS Engineer dans les grandes boîtes tech US, chiffres principaux en USD. Paris / Berlin / Singapour paient typiquement 30 à 50 % de moins en base ; les ratios d'equity varient selon le stade de l'entreprise.
Pour repère, un iOS L4 en FAANG tourne autour de 260–340 k$ de TC au 50e percentile, et suit la grille L4 SWE chez Meta / Google / Stripe. À Paris, un iOS Engineer mid se situe plutôt autour de 50–70 k€ de base selon l'employeur (scale-up produit, grand compte, ou filiale tech américaine). Apple paie un cran au-dessus de cette bande au niveau ICT3 équivalent, avec un loop structuré différemment.
Comment se préparer, cinq conseils tactiques
Ouvrez vos réponses comportementales avec la méthode STAR, Situation, Tâche, Action, Résultat. Les conseils tactiques ci-dessous s'appuient sur cette structure pour ce rôle précis.
- Drillez Swift à froid : closures, async/await, actors, sémantique valeur vs référence, generics. Le round de coding suppose une aisance que la pratique en take-home ne peut pas simuler
- Maîtrisez un pattern d'architecture en profondeur (MVVM, MVC, ou The Composable Architecture) et sachez le défendre sans vous rabattre sur « c'est ce que l'équipe utilise »
- Préparez-vous à dérouler une feature que vous avez shipée : choix liés au cycle de vie, le cas limite qui vous a mordu, ce que vous referiez autrement. Le deep-dive attend du concret
- Regardez les sessions WWDC des 2 dernières années sur les features que la boîte utilise (Observation, Swift Macros, isolation MainActor, @Observable en SwiftUI)
- Entraînez-vous sur 2 ou 3 system designs mobiles à froid : sync offline-first, cache d'images, handler de push. Vous pattern-matcherez le reste
- Ne négligez pas le round d'algos : même léger, c'est lui qui élimine les profils mobiles qui n'ont jamais fait de LeetCode. Comptez 40 à 60 mediums sur tableaux, strings, hashmaps
Les pièges fréquents au niveau iOS Engineer
Quelques erreurs fréquentes qui font recaler les candidats iOS Engineer même quand ils sont par ailleurs solides. Mieux vaut les repérer en mock interview avant qu'elles n'apparaissent en vrai.
Résoudre le problème de coding de façon optimale mais ignorer la couche iOS : aucune conscience du main thread, aucun raisonnement valeur vs référence, aucune mention de l'endroit où un retain cycle pourrait se former.
Pourquoi ça rate
Au L4 la barre n'est pas « savez-vous coder ». C'est « écrivez-vous du Swift comme quelqu'un qui a shipé en prod ». Une solution juste qui ne mentionne pas le weak self dans une closure, ou qui prend une class là où un struct suffit, donne l'image d'un « ingénieur générique qui a appris Swift récemment ». L'intervieweur attend le commentaire sur la couche iOS, pas l'algorithme.
Comment rattraper
Après chaque solution, narrez la couche iOS à voix haute : où ça s'exécute (quel thread), si le type devrait être struct ou class, où des fuites mémoire peuvent se former (retain cycles dans les closures ou les pipelines Combine), et où vous prendriez un actor plutôt qu'une serial queue.
Designer une feature iOS comme si c'était une feature web : happy path, connectivité parfaite, serveur toujours joignable.
Pourquoi ça rate
Le system design mobile n'a pas les mêmes contraintes que le back-end. L'offline, le réseau capricieux, le cycle de vie de l'app (foreground / background / terminée), le background refresh, les réveils par push : rien de tout ça n'est optionnel. Un design qui les ignore donne l'image de « quelqu'un qui pense back-end et qui écrit du Swift par accident ». L'intervieweur attend la question de clarification sur le comportement offline, pas que vous fonciez sur un design serveur-d'abord.
Comment rattraper
Dans les cinq premières minutes de tout system design iOS, posez les questions offline : que se passe-t-il sans connectivité, quelle est la stratégie de sync, quelle est la règle de résolution de conflits, quel travail tourne en background et quand. Ensuite construisez le design autour des réponses.
Décrire son travail iOS passé en termes de features construites : pas de DAU, pas de crash rate, pas de récit de rollout App Store, pas de chiffres d'A/B.
Pourquoi ça rate
Les intervieweurs iOS calibrent contre l'expérience de mise en prod. « J'ai construit le nouvel écran d'onboarding » ne leur dit rien. « J'ai construit le flow d'onboarding utilisé par 800k DAU, fait baisser l'abandon du tunnel de 22 % à 14 % via la refonte du troisième écran, et le rollout progressif de la 2.4.1 a remonté un crash sur iOS 16 qu'on a patché en deux jours » leur permet de vous situer. Les chiffres de prod séparent les candidats L4 des L3 plus encore que la profondeur technique.
Comment rattraper
Pour vos 3 ou 4 meilleures histoires, attachez trois chiffres chacune : échelle (DAU ou téléchargements), impact (la métrique qui a bougé), et un détail opérationnel (crash rate, rollout, retour de review App Store). Des chiffres approximatifs valent mieux que pas de chiffres.
Ressources recommandées
Livres, cours et outils qui reviennent le plus dans la préparation iOS Engineer. Sans lien d'affiliation.
- 01The Swift Programming Language (gratuit, swift.org) →La référence officielle Swift. Relisez les chapitres Concurrency, Memory Safety et Generics avant tout loop chargé en Swift.
- 02Swift Concurrency (Apple Developer) →La doc canonique sur async/await, actors et MainActor. Les questions sur le threading et l'isolation tombent à chaque round de coding récent.
- 03Hacking with Swift (Paul Hudson) →Les tutoriels iOS les plus cités en pratique. Utile pour les patterns et les apps d'exemple qui reviennent dans les rounds de coding.
- 04Kodeco (ex-raywenderlich.com) →Tutoriels et livres de référence sur l'architecture et les frameworks iOS. Bon pour défendre un choix d'architecture dans le round de system design.
- 05iOS Interview Questions (GitHub) →Repo communautaire de questions d'entretien iOS classées par thème. À parcourir pour pattern-matcher les questions Swift et cycle de vie qui tombent vraiment.
Scénarios courants
Je suis dev iOS en agence / ESN (ou en freelance) depuis 4 ans, j'ai livré une dizaine d'apps clients sous UIKit. Comment je transitionne vers une boîte produit française (Doctolib, BlaBlaCar, Leboncoin, Back Market) où le code reste plusieurs années ?
Le piège du parcours agence / ESN, c'est que vous avez livré beaucoup d'apps mais jamais vécu une seule sur la durée : pas de crash rate suivi sur 12 mois, pas d'A/B test, pas de dette technique que vous avez dû payer vous-même. Les boîtes produit recrutent exactement pour ça. Avant le loop, ressortez 2 ou 3 apps et ré-écrivez-les côté décisions et pas côté livrables : « j'ai choisi telle archi pour telle raison, voici le cas limite qui m'a mordu, voici ce que je referais ». Sur le coding round, votre Swift sera probablement solide mais centré UIKit ; le système design mobile est le vrai écart, drillez sync offline-first, cache d'images et handler de push à froid. Attention au round d'algos : en agence on fait rarement du LeetCode, comptez 40 à 60 mediums minimum. Et ne sous-vendez pas l'expé clients (livrer sous contrainte de délai, jongler les specs qui changent) ; reformatez-la en « livré sous contrainte » plutôt qu'en prestation.
Je code en UIKit depuis des années et je n'ai presque jamais touché SwiftUI. Les offres parlent toutes de SwiftUI maintenant. Est-ce que je dois tout réapprendre avant de passer des entretiens chez Lydia, Qonto ou Sorare ?
Non, et c'est une erreur fréquente de croire qu'il faut basculer 100 % SwiftUI avant de candidater. La réalité des grosses apps françaises (Doctolib, Leboncoin, BlaBlaCar) c'est un codebase mixte : du UIKit historique sur les écrans critiques, du SwiftUI sur les nouvelles features, et beaucoup de ponts entre les deux (UIHostingController, UIViewRepresentable). Les intervieweurs le savent. Ce qu'ils testent, ce n'est pas « savez-vous tout SwiftUI », c'est « comprenez-vous le modèle déclaratif et savez-vous quand l'un bat l'autre ». Préparez-vous à expliquer la différence de cycle de vie (viewDidLoad vs body / @State / @Observable), à parler de la gestion d'état en SwiftUI, et à dire honnêtement où vous mettriez encore du UIKit (animations fines, perf sur des listes lourdes). Construisez une petite app SwiftUI avec un appel réseau et un peu d'état partagé sur 2 ou 3 week-ends, ça suffit pour le niveau de la discussion. Le piège, c'est de bluffer une maîtrise SwiftUI que vous n'avez pas, l'intervieweur le voit en deux questions.
Je suis dev Android (ou cross-platform Flutter / React Native) et je veux passer sur du natif iOS. Comment je prépare un loop iOS quand mon Swift est encore frais ?
L'avantage : vous comprenez déjà les contraintes mobiles (cycle de vie, threading, offline, perf de liste), et ça, c'est la moitié de la barre iOS. L'écart, c'est l'idiome Swift et l'écosystème Apple. Sur le coding round, ne vous contentez pas d'un Swift « qui marche » : drillez la sémantique valeur vs référence, weak self dans les closures, async/await et MainActor, parce que c'est précisément là qu'un profil venu d'Android se fait repérer (on écrit du Swift comme du Kotlin). Côté system design, votre intuition Android sur la sync offline et le cache se transpose presque directement, apprenez juste les noms iOS (URLSession, background fetch, silent push, Core Data / SwiftData vs Room). Pour Flutter / React Native, l'écart est plus grand : vous avez probablement délégué le natif au framework, donc le threading et la mémoire iOS sont à reconstruire. Comptez 6 à 8 semaines : Swift à fond, une vraie app native sans framework cross-platform, et les 2 dernières WWDC sur la concurrence. En behavioral, assumez la transition franchement, les boîtes produit voient d'un bon œil quelqu'un qui choisit le natif en connaissance de cause.
Je suis dev iOS autodidacte, très à l'aise pour construire des apps complètes, mais le round d'algos me terrifie. À quel point c'est éliminatoire dans un loop iOS en France ?
C'est moins lourd que pour un poste back-end, mais ce n'est pas décoratif : le round d'algos est précisément l'endroit où les profils mobiles autodidactes ou venus de l'agence se font sortir. La plupart des loops iOS gardent un seul round d'algos (souvent un medium en 40 minutes) plutôt que deux ou trois comme pour un SWE. Les filiales tech américaines à Paris et les scale-ups exigeantes (Qonto, Sorare, Back Market) maintiennent une vraie barre dessus ; certaines boîtes plus petites le remplacent par un exercice plus appliqué. Le plan : 40 à 60 LeetCode mediums sur tableaux, strings, hashmaps et arbres, pas besoin d'aller jusqu'aux graphes avancés ou à la programmation dynamique pointue. Entraînez-vous à parler de votre approche avant de coder et à donner la complexité, parce que sur un round iOS l'intervieweur pardonne plus volontiers une solution non optimale si le raisonnement est propre. Ne sacrifiez pas pour autant la prep Swift et system design : l'algo vous fait passer le filtre, mais c'est la couche iOS qui décide du niveau et de l'offre.
Questions fréquentes
Ce guide est-il utile si je suis dev back-end / web et que je passe sur iOS ?
Oui, la barre L4 / IC3 décrite ici s'applique que vous veniez du web, du back-end, ou directement de l'iOS. Les transitions SWE-vers-iOS ont en général la base algorithmique mais doivent driller les patterns spécifiques iOS (cycle de vie, threading, sémantique de valeur, retain cycles). Le plus gros écart, c'est le round de coding qui attend des idiomes Swift fluides, pas seulement du code juste. Préparez ce gap en premier.
Combien de temps prévoir avant un onsite iOS Engineer ?
Le process prend 3 à 5 semaines. Ajoutez 4 à 6 semaines de prep si vous êtes rouillé sur le Swift / SwiftUI actuel ; 2 à 3 semaines si vous shipez de l'iOS tous les jours. Regarder les 2 dernières WWDC sur les features que la boîte utilise est le geste à plus fort levier à ce niveau.
Quelle est l'erreur la plus fréquente des candidats au niveau iOS Engineer ?
Traiter le round de coding iOS comme un test d'algos. L'intervieweur note si vous écrivez du Swift comme un ingénieur iOS de production : sémantique de valeur, weak self, MainActor, les hooks du cycle de vie. La justesse algorithmique sans cette couche donne l'image d'un dev back-end qui joue à l'iOS.
Et si mon process d'entretien diffère de celui décrit ici ?
L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.
Comment ce guide se compare-t-il au scan gratuit ?
Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.
Prêt à préparer un vrai poste ?
Collez n'importe quelle offre iOS Engineer, découvrez votre coach en moins de 30 secondes.
Déposez une URL LinkedIn, Greenhouse, Lever ou Levels.fyi, ou collez le texte de l'offre. Votre coach prédit les questions pour cette entreprise, fait ressortir vos écarts d'expérience, et calibre un benchmark de salaire pour le poste et la localisation. PDF par e-mail. L'entraînement vocal avec retour IA sur chaque réponse vit dans l'extension Chrome.
Installation libre · Aperçu sur chaque offre · Plans payants à partir de 3,99 $