5 erreurs de débutants en Swift qui font pleurer Xcode

Introduction : pourquoi Swift mord, même si vous l'aimez

Vous avez décidé de devenir développeur iOS. Vous avez installé Xcode, écrit votre premier « Hello, World! » — et vous vous êtes senti presque comme Tim Cook. Et puis ça a commencé : Xcode râle à cause de mystérieux nil, le code ne compile pas, et l'application plante dès la première pression sur un bouton. Ça vous dit quelque chose ?

Bienvenue dans le monde de Swift — un langage adoré pour sa sécurité, mais détesté pour sa rigueur. Dans cet article, nous allons décortiquer les erreurs lors de l'apprentissage de Swift que commettent 90% des débutants. Vous apprendrez à les éviter, à économiser vos nerfs et à arrêter de maudire Apple. C'est parti !

Erreur n°1 : Ignorer les Optionals et travailler avec nil « à l'arrache »

Swift est le premier langage où nil n'est pas simplement « vide », mais toute une philosophie. Les débutants essaient souvent de travailler avec les optionals comme en Python ou JavaScript : « bon, peut-être qu'il y a quelque chose, peut-être pas ». Et ils obtiennent un crash.

À quoi ça ressemble dans le code

// ❌ Erreur typique de débutant\nvar userName: String? = nil\nprint("Bonjour, \\(userName.uppercased())!") // Fatal error: Unexpectedly found nil\n

Ici, userName est un optionnel (String?). Vous avez oublié de vérifier s'il contient une valeur, et vous avez essayé d'appeler la méthode uppercased() sur nil. L'application plante.

L'approche correcte

// ✅ Extraction sécurisée\nif let safeName = userName {\n    print("Bonjour, \\(safeName.uppercased())!")\n} else {\n    print("Nom non défini")\n}\n\n// Ou avec guard\nguard let unwrappedName = userName else {\n    print("Erreur : nom absent")\n    return\n}\nprint("Bonjour, \\(unwrappedName.uppercased())!")\n

Conseil : Demandez-vous toujours : « Est-ce que cette variable peut être nil ? ». Si oui — utilisez if let ou guard let. C'est l'une des erreurs de débutants en Swift les plus fréquentes, qui fait perdre du temps en débogage.

Erreur n°2 : La peur des closures et l'utilisation de @escaping

Les closures en Swift sont comme des fonctions anonymes. Les débutants en ont peur, écrivent d'énormes méthodes au lieu de closures compactes, puis s'étonnent que le code soit illisible. Et quand vient l'asynchrone, l'enfer avec @escaping commence.

Exemple de peur des closures

// ❌ Code qui pourrait être réduit de 3 fois\nfunc fetchData(completion: (String) -> Void) {\n    let result = "Données chargées"\n    completion(result)\n}\n\n// Appel\nfetchData { data in\n    print(data)\n}\n

Tout est beau ? Oui. Mais les débutants écrivent comme ça :

// ❌ Style horrible\nfunc fetchData() {\n    let result = "Données chargées"\n    handleResult(result: result)\n}\n\nfunc handleResult(result: String) {\n    print(result)\n}\n

Et quand il faut faire une requête asynchrone, ils oublient @escaping :

// ❌ Erreur : closure non escaping\nfunc loadUser(id: Int, completion: (User) -> Void) {\n    DispatchQueue.global().async {\n        let user = User(id: id)\n        completion(user) // Erreur de compilation !\n    }\n}\n

Xcode dira : « La closure doit être @escaping ». On corrige :

// ✅ Correct\nfunc loadUser(id: Int, completion: @escaping (User) -> Void) {\n    DispatchQueue.global().async {\n        let user = User(id: id)\n        completion(user)\n    }\n}\n

Conclusion : N'ayez pas peur des closures. Ce sont vos amis. Et @escaping n'est qu'un drapeau qui dit : « Cette closure sera appelée plus tard, conserve-la ». Retenez cela — et la moitié des erreurs Swift pour débutants disparaîtra.

Erreur n°3 : Confusion entre classes et structures

En Swift, il y a les classes (type référence) et les structures (type valeur). Les débutants utilisent souvent les classes partout parce qu'« ils ont l'habitude d'un autre