Swift 3 @objc inference déprécié : que faire dans Swift 4

Pourquoi Swift 3 @objc inference devient-il obsolète ?

Si vous avez déjà mis à jour un projet de Swift 3 vers Swift 4, vous avez probablement rencontré l'avertissement inquiétant du compilateur :

The use of Swift 3 @objc inference in Swift 4 mode is deprecated. \nPlease address this deprecated @objc inference warning, \nor disable the warning by setting the "Swift 3 @objc Inference" \nbuild setting to "Default" for the "Swift 4" target.

Ce message n'est pas une simple formalité. Il cache un changement important dans la philosophie du langage. Dans Swift 3, le compilateur décidait lui-même quelles méthodes et propriétés devaient être visibles pour Objective-C. C'était pratique, mais cela créait des problèmes cachés : la taille du binaire augmentait et les performances diminuaient. Swift 4 a décidé d'en finir avec cette « devinette » et a rendu le contrôle au développeur.

Dans cet article, nous allons voir ce qu'est @objc inference, pourquoi il a été déprécié, comment corriger l'avertissement et quelles sont les meilleures pratiques à utiliser dans les projets modernes. C'est parti !

Qu'est-ce que @objc inference et comment fonctionnait-il dans Swift 3 ?

Dans Swift 3, il existait une conversion implicite vers @objc. Cela signifiait que si une classe héritait de NSObject ou utilisait un protocole @objc, le compilateur rendait automatiquement toutes ses méthodes visibles pour Objective-C. Ce mécanisme s'appelait @objc inference (déduction implicite).

Exemple avec Swift 3 :

class MyViewController: UIViewController {\n    func buttonTapped() {\n        print("Button tapped")\n    }\n}

Dans Swift 3, la méthode buttonTapped() devenait automatiquement @objc. Vous pouviez la passer dans #selector ou l'utiliser comme cible pour UIControl. Pratique ? Oui. Mais le prix était un gonflement injustifié du binaire et une perte d'optimisations.

Pourquoi Apple a-t-elle décidé d'abandonner la déduction automatique ?

Plusieurs raisons, toutes liées à l'efficacité et au contrôle :

\n
• Taille de l'application. Chaque méthode marquée comme @objc génère une enveloppe supplémentaire pour le runtime Objective-C. Dans les grands projets, cela pouvait ajouter des mégaoctets de code inutile.
\n
• Performances. Swift est un langage à typage statique avec une optimisation puissante. Dès qu'une méthode devient @objc, le compilateur perd la possibilité d'appliquer certaines optimisations (par exemple, l'inlining).
\n
• Explicite. Swift 4 a pris un cap vers l'explicite. Le développeur doit décider lui-même ce qui doit être accessible depuis Objective-C. Cela simplifie la compréhension du code et réduit les erreurs inattendues.
\n
• Avenir de Swift. Apple s'éloigne progressivement de la dépendance à Objective-C. Moins il y a de ponts implicites, plus Swift pourra rapidement devenir un langage complètement autonome.
\n

À quoi ressemble l'avertissement en pratique ?

Supposons que vous ayez un projet écrit en Swift 3. Vous basculez le paramètre "Swift Language Version" sur Swift 4.0 et vous obtenez des dizaines (voire des centaines) d'avertissements comme celui-ci :

class LegacyViewController: UIViewController {\n    // Avertissement : The use of Swift 3 @objc inference in Swift 4 mode is deprecated\n    func legacyAction() {\n        // ...\n    }\n\n    @objc func explicitAction() {\n        // Cette méthode est déjà marquée @objc — tout va bien\n    }\n}

Le compilateur se plaint de legacyAction(), car elle n'est pas marquée @objc, mais auparavant le compilateur le faisait automatiquement. Il faut maintenant une solution.

Trois façons de corriger l'avertissement

Vous avez trois options. Choisissez celle qui convient