Unowned Reference: Was es ist, Syntax und Anwendung in mobilen Anwendungen

Was ist Unowned Reference?

Unowned Reference ist ein nichtbesitzender Verweis auf ein Objekt in ARC, der dessen Retain Count nicht erhöht. Im Gegensatz zu weak wird eine unowned-Referenz nach der Freigabe des Objekts nicht nullgesetzt: Sie zeigt weiterhin auf bereits freigegebenen Speicher. Der Zugriff auf eine solche Referenz verursacht einen Laufzeitabsturz mit EXC_BAD_ACCESS.

Der Begriff „nichtbesitzend“ spiegelt die Semantik wider: Das Objekt existiert, aber niemand ist für seine Lebensdauer verantwortlich. Der Entwickler erklärt explizit: „Ich garantiere, dass dieses Objekt leben wird, solange ich darauf verweise.“ Der Compiler überprüft diese Garantie nicht — es ist ein Vertrag auf Entwicklerebene.

Laut Swift.org Documentation, 2026 werden unowned-Referenzen in Szenarien mit garantierter Lebensdauer gegenüber weak bevorzugt, weil sie: keinen optionalen Typ benötigen (sauberer Code), kein Unwrap benötigen (weniger force-unwrap oder guard let) und keinen Overhead für die Verwaltung einer Nullsetzungs-Weak-Tabelle haben. Jede Verletzung des Vertrags führt jedoch zu einem Absturz.

Unowned-Syntax in Swift

In Swift werden unowned-Referenzen mit dem Schlüsselwort unowned vor let oder var deklariert. Im Gegensatz zu weak kann unowned sowohl let als auch var sein und benötigt keinen optionalen Typ. Diese Eigenschaft macht unowned praktisch für Referenzen, die durch die Domänenlogik nicht nil sein können.

class Country {
    let name: String
    var capital: City!           // wird nach der Initialisierung gesetzt
    init(name: String) { self.name = name }
}

class City {
    let name: String
    unowned let country: Country   // ✅ unowned let — Lebensdauergarantie

    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

// Verwendung
let france = Country(name: "France")
let paris = City(name: "Paris", country: france)
france.capital = paris
// ✅ Country → City (strong), City → Country (unowned) — kein Retain Cycle

In diesem Beispiel: City unowned let country — eine Stadt kann ohne ein Land nicht existieren. Wenn das Land verschwindet, verlieren die Stadt (und der Verweis) ihre Bedeutung. Semantisch ist dies ein idealer Fall für unowned: Lebensdauergarantie besteht, Optional wird nicht benötigt, Retain Cycle tritt nicht auf.

unowned var

unowned var ist erlaubt, aber weniger gebräuchlich. Es wird verwendet, wenn der Verweis ersetzt werden kann (z. B. Neuzuweisung eines Kindes zu einem anderen Elternteil). Bei der Neuzuweisung liegt die Freigabe des alten Objekts in der Verantwortung des externen Besitzers.

Unowned Optional

In Swift 5.0+ wurde die Unterstützung für unowned optional (unowned let x: Type?) eingeführt. Dies ist ein Kompromiss: unowned garantiert, dass das Objekt lebt, wenn der Verweis nicht nil ist. Das Verhalten bei Freigabe ist ein Absturz, wie bei normalem unowned.

Unowned vs Weak: Wann was verwenden

Die Wahl zwischen unowned und weak ist eine der häufigen Entscheidungen beim Entwurf von Swift-Architekturen. Betrachten wir die Kriterien und Empfehlungen für jeden Fall.

Praktische Regel

Verwenden Sie weak, wenn auch nur der geringste Zweifel an der Lebensdauer des Objekts besteht. Weak ist sicher, klar und benötigt keinen Beweis. Verwenden Sie unowned nur, wenn Sie alle Szenarien ausschließen können, in denen das Objekt früher freigegeben werden könnte. Typische Fälle: ein Kind, das ohne Elternteil nicht existiert; ein Closure, das synchron ausgeführt wird; Zugriff auf ein Objekt innerhalb seines Initialisierers.

Laut Airbnb Swift Style Guide, 2025 wird in großen Codebasen empfohlen, standardmäßig weak zu verwenden und unowned nur mit einem expliziten Kommentar, der die Lebensdauergarantie erklärt. Dies reduziert das Risiko von nicht offensichtlichen Abstürzen bei der Refaktorierung.

Unowned self in Closures

Closures sind nach Eltern-Kind-Beziehungen der zweithäufigste Anwendungsfall für unowned. Die Capture-Liste [unowned self] wird verwendet, wenn garantiert ist, dass self das Closure überlebt. Betrachten wir richtige und falsche Szenarien.

Wann unowned self sicher ist

Synchronen Closures — sorted, filter, map. Sie werden sofort im aktuellen Thread ausgeführt, self ist definitiv lebendig. Eine Capture-Liste mit unowned ist hier akzeptabel und ergibt saubereren Code.

class DataProcessor {
    var items: [Int] = [3, 1, 4, 1, 5]

    func processSorted() {
        // ✅ unowned self — sorted wird synchron ausgeführt, self ist garantiert lebendig
        let sorted = items.sorted { [unowned self] a, b in
            return self.customCompare(a, b)
        }
    }

    func customCompare(_ a: Int, _ b: Int) -> Bool { return a < b }
}

Wann unowned self gefährlich ist

Asynchrone Closures — mit Verzögerungen, Netzwerkanfragen, Animationen. Self kann zwischen der Planung des Closures und seiner Ausführung freigegeben werden. Hier führt unowned self zu einem Absturz. Verwenden Sie [weak self].

class NetworkLoader {
    func loadData() {
        // ❌ GEFÄHRLICH: unowned self in asynchronem Closure
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // ABSTURZ wenn self freigegeben wird
        }.resume()
    }

    func handleResponse(_ data: Data?) { }

    // ✅ RICHTIG: weak self + guard
    func loadDataSafe() {
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            guard let self else { return }
            self.handleResponse(data)
        }.resume()
    }
}

Merken Sie sich die Regel: unowned self — nur für synchrone Closures, die sofort ausgeführt werden. Für asynchrone Closures verwenden Sie immer weak self + guard let. Ausnahme: wenn Sie explizit einen Verweis auf das Objekt halten, bis das Closure abgeschlossen ist (z. B. durch Halten einer starken Referenz in einer anderen Variablen).

Risiken von unowned und wie man sie vermeidet

Unowned ist ein mächtiges, aber gefährliches Werkzeug. Betrachten wir reale Szenarien, in denen unowned zu Abstürzen führen kann, und Methoden zur Risikominimierung.

Refaktorierung und Änderung von Garantien

Das Hauptrisiko von unowned ist eine Änderung der Geschäftslogik, die die Lebensdauergarantie ungültig macht. Ein Entwickler refaktoriert den Code: ändert die Besitzverhältnisse, führt verzögerte Freigabe ein, fügt Caching hinzu — und die unowned-Referenz wird zur Zeitbombe. Der Compiler wird nicht warnen — nur ein Absturz auf dem Gerät des Benutzers.

Empfehlung: Verwenden Sie unowned nur, wenn die Lebensdauergarantie offensichtlich und dokumentiert ist. Fügen Sie jedem unowned einen Kommentar hinzu: warum dieser Verweis sicher ist und unter welchen Bedingungen er verletzt werden könnte.

Unowned in UIKit-Hierarchien

UIKit ist ein Hochrisikobereich für unowned. Ein ViewController kann jederzeit während der Navigation (Pop, Dismiss), Speicherentladung oder Orientierungsänderungen freigegeben werden. Wenn Sie einen ViewController mit unowned self an ein Closure übergeben, kann self bei der Rückkehr aus dem Hintergrund oder nach Abschluss einer Animation nil sein.

Bewährte Praktiken

Befolgen Sie diese Regeln, um das Risiko bei der Verwendung von unowned zu reduzieren:

• Bevorzugen Sie standardmäßig weak — weak ist sicher, unowned ist eine Optimierung, kein Standard
• Dokumentieren Sie Garantien — schreiben Sie für jedes unowned einen Kommentar mit Begründung
• Vermeiden Sie unowned in ViewController — der UIKit-Lebenszyklus ist für unowned-Garantien unvorhersehbar
• Verwenden Sie unowned nur für synchrone Closures — sorted, filter, map sind sichere Kandidaten
• Prüfen Sie bei der Code-Review — jedes unowned benötigt eine Begründung vom Code-Autor
• Migrieren Sie zu weak beim geringsten Zweifel — der Verlust an Lesbarkeit (ein guard let) ist geringer als ein Absturz in der Produktion

// Beispiel: dokumentierte unowned-Referenz mit expliziter Begründung
class InvoiceLineItem {
    let productName: String
    let price: Decimal

    // unowned Invoice — InvoiceLineItem kann ohne Invoice nicht existieren.
    // Invoice erstellt Item und entfernt es, wenn es gelöscht wird.
    // Garantie: Invoice lebt mindestens so lange wie Item.
    unowned let invoice: Invoice

    init(productName: String, price: Decimal, invoice: Invoice) {
        self.productName = productName
        self.price = price
        self.invoice = invoice
    }
}

// Dies ist eine starke Garantie: Invoice entfernt alle Items in deinit.
// Garantieverletzung = ein Fehler in der Geschäftslogik, der behoben werden muss.

Die Dokumentation von Garantien ist ein professioneller Standard. In großen Projekten (Airbnb, Uber) erfordert die Code-Review eine Begründung für jedes unowned. Wenn die Garantie nicht offensichtlich ist, verwenden Sie weak. Ein Kommentar zu unowned hilft zukünftigen Entwicklern zu verstehen, warum hier weak nicht verwendet wurde und welche Bedingungen die Garantie brechen könnten.