Swift 3 @objc inference deprecated: Was tun in Swift 4

Warum gehört Swift 3 @objc inference der Vergangenheit an?

Wenn Sie jemals ein Projekt von Swift 3 auf Swift 4 aktualisiert haben, sind Sie sicherlich auf die beängstigende Compiler-Warnung gestoßen:

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.

Diese Meldung ist keine bloße Formalität. Dahinter steckt eine wichtige Änderung der Sprachphilosophie. In Swift 3 entschied der Compiler selbst, welche Methoden und Eigenschaften für Objective-C sichtbar gemacht werden sollten. Das war praktisch, schuf aber versteckte Probleme: Die Binärgröße wuchs und die Leistung sank. Swift 4 hat beschlossen, mit diesem „Raten“ Schluss zu machen und die Kontrolle an den Entwickler zu übergeben.

In diesem Artikel werden wir untersuchen, was @objc inference ist, warum es als deprecated eingestuft wurde, wie man die Warnung behebt und welche Best Practices in modernen Projekten angewendet werden sollten. Los geht's!

Was ist @objc inference und wie funktionierte es in Swift 3?

In Swift 3 gab es eine implizite Umwandlung zu @objc. Das bedeutete, dass, wenn eine Klasse von NSObject erbte oder ein @objc-Protokoll verwendete, der Compiler automatisch alle ihre Methoden für Objective-C sichtbar machte. Dieser Mechanismus hieß @objc inference (implizite Ableitung).

Beispiel aus Swift 3:

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

In Swift 3 wurde die Methode buttonTapped() automatisch zu @objc. Sie konnten sie an #selector übergeben oder als target für UIControl verwenden. Praktisch? Ja. Aber der Preis war eine unnötige Aufblähung der Binärdatei und der Verlust von Optimierungen.

Warum hat Apple sich entschieden, die automatische Ableitung aufzugeben?

Es gibt mehrere Gründe, und alle drehen sich um Effizienz und Kontrolle:

\n
• App-Größe. Jede als @objc markierte Methode generiert einen zusätzlichen Wrapper für die Objective-C-Laufzeit. In großen Projekten konnte dies Megabyte an überflüssigem Code hinzufügen.
\n
• Leistung. Swift ist eine Sprache mit statischer Typisierung und leistungsstarker Optimierung. Sobald eine Methode @objc wird, verliert der Compiler die Möglichkeit, eine Reihe von Optimierungen (z. B. Inlining) anzuwenden.
\n
• Explizitheit. Swift 4 hat einen Kurs in Richtung Explizitheit eingeschlagen. Der Entwickler sollte selbst entscheiden, was von Objective-C aus zugänglich sein soll. Dies vereinfacht das Verständnis des Codes und reduziert unerwartete Fehler.
\n
• Zukunft von Swift. Apple entfernt sich allmählich von der Abhängigkeit von Objective-C. Je weniger implizite Brücken, desto schneller kann Swift zu einer vollständig eigenständigen Sprache werden.
\n

Wie sieht die Warnung in der Praxis aus?

Angenommen, Sie haben ein Projekt, das in Swift 3 geschrieben wurde. Sie stellen die Einstellung "Swift Language Version" auf Swift 4.0 um und erhalten Dutzende (wenn nicht Hunderte) solcher Warnungen:

class LegacyViewController: UIViewController {\n    // Warnung: The use of Swift 3 @objc inference in Swift 4 mode is deprecated\n    func legacyAction() {\n        // ...\n    }\n\n    @objc func explicitAction() {\n        // Diese Methode ist bereits mit @objc markiert – alles in Ordnung\n    }\n}

Der Compiler beanstandet legacyAction(), da es nicht mit @objc markiert ist, aber früher der Compiler dies automatisch tat. Jetzt ist eine Lösung erforderlich.

Drei Möglichkeiten, die Warnung zu beheben

Sie haben drei Handlungsoptionen. Wählen Sie die, die zu Ihrem