Comment réussir un entretien Swift : les meilleures questions de A à Z

Introduction : Pourquoi Swift est la clé d'un entretien réussi

L'entretien Swift n'est pas simplement une vérification de la syntaxe. L'écosystème Apple exige une compréhension des principes fondamentaux du langage, de la gestion de la mémoire et des frameworks modernes. Dans cet article, nous analyserons les meilleures questions qui vous seront posées à tous les niveaux — du Junior au Senior. Vous découvrirez non seulement les bonnes réponses, mais aussi les pièges typiques dans lesquels tombent les candidats.

Cet article est rédigé pour le portail éducatif PythonLib, mais adapté à Swift. Nous avons structuré le contenu pour que vous puissiez rapidement réviser les sujets clés avant l'entretien.

1. Bases de Swift : Optionnel, Types valeur vs référence

Qu'est-ce qu'un Optionnel et pourquoi est-il nécessaire ?

Un Optionnel est une énumération (enum) qui peut être soit .none (nil), soit .some(Wrapped). C'est la manière dont Swift gère en toute sécurité l'absence de valeur.

var name: String? = "Alice"\nvar age: Int? = nil\n\n// Extraction sécurisée\nif let unwrappedName = name {\n    print("Bonjour, \\(unwrappedName)")\n} else {\n    print("Le nom est nil")\n}

Erreur typique : Utiliser le force unwrap (!) sans vérification. Préférez toujours guard let ou if let.

Types valeur vs Types référence

Swift distingue strictement les types :

\n
• Types valeur (structures, énumérations, types de base) — sont copiés lors de l'affectation.
\n
• Types référence (classes) — sont transmis par référence.
\n

struct Point {\n    var x: Int\n    var y: Int\n}\n\nclass Car {\n    var model: String\n    init(model: String) { self.model = model }\n}\n\nvar point1 = Point(x: 1, y: 2)\nvar point2 = point1\npoint2.x = 5 // point1.x reste 1\n\nvar car1 = Car(model: "Tesla")\nvar car2 = car1\ncar2.model = "BMW" // car1.model devient aussi "BMW"

Question d'entretien : "Pourquoi Apple recommande-t-elle d'utiliser des structures plutôt que des classes ?" Réponse : sécurité des threads, prévisibilité, absence de surcharge ARC.

2. Gestion de la mémoire et ARC : Comment éviter les fuites

Comment fonctionne le comptage automatique de références (ARC) ?

L'ARC compte automatiquement les références aux objets des classes. Lorsque le compteur atteint zéro, la mémoire est libérée. Les problèmes surviennent avec les références cycliques.

class Person {\n    let name: String\n    var apartment: Apartment?\n    init(name: String) { self.name = name }\n    deinit { print("\\(name) désalloué") }\n}\n\nclass Apartment {\n    let unit: String\n    weak var tenant: Person?  // weak — référence faible\n    init(unit: String) { self.unit = unit }\n    deinit { print("Appartement \\(unit) désalloué") }\n}\n\nvar john: Person? = Person(name: "John")\nvar unit4A: Apartment? = Apartment(unit: "4A")\njohn?.apartment = unit4A\nunit4A?.tenant = john\njohn = nil\nunit4A = nil\n// Les deux objets seront libérés

Modificateurs clés :

\n
• weak — toujours optionnel, devient automatiquement nil lors de la libération.
\n
• unowned — non optionnel, suppose que l'objet est vivant (risque de crash).
\n

Question typique : "Quelle est la différence entre weak et unowned ?" Réponse : weak est plus sûr, unowned est plus pratique pour les dépendances obligatoires (exemple : délégué).

3. Frameworks : UIKit vs SwiftUI, GCD et Protocoles

UIKit : Cycle de vie du ViewController et Pattern Délégué

Comprendre viewDidLoad, viewWillAppear, viewDidDisappear — c'est la base. Mais en entretien, on demande souvent le pattern Délégué :

protocol MyDelegate: AnyObject {\n    func didTapButton()\n}\n\nclass MyView: UIView {\n    weak var delegate: MyDelegate?\n    \n    @objc func buttonTapped() {\n        delegate?.didTapButton()\n    }\n}\n\nclass MyViewControlle