.task { } — was ist das, async-Modifikator und Datenladen in View

Was ist .task { } in SwiftUI

.task { } ist ein View-Modifikator, der einen Task in einem async-Kontext erstellt, wenn die View auf dem Bildschirm erscheint. SwiftUI führt den übergebenen Closure im Hintergrundthread aus und lässt den Hauptthread für UI-Operationen frei. Wenn die View verschwindet, bricht SwiftUI den Task automatisch über den Structured-Concurrency-Mechanismus ab — dies stellt sicher, dass die asynchrone Operation nicht weiterläuft, nachdem ihr Ergebnis nicht mehr benötigt wird.

Laut Apple — Swift Programming Language (2025) verwendet .task das Konzept der Structured Concurrency, das in Swift 5.5 eingeführt wurde. Jeder .task erstellt einen Kind-Task innerhalb des Tasks der Eltern-View. Wenn der Eltern-Task abgebrochen wird (die View verschwindet), werden alle Kind-Tasks ebenfalls automatisch abgebrochen. Dies vereinfacht die Verwaltung des Lebenszyklus asynchroner Operationen im Vergleich zum manuellen Speichern von Referenzen auf DispatchWorkItem oder AnyCancellable radikal.

Im Gegensatz zum traditionellen Ansatz mit @State + manuellem Aufruf in .onAppear erfordert .task keine Speicherung einer Referenz auf den Task für den späteren Abbruch. SwiftUI erledigt dies automatisch, reduziert Boilerplate-Code und eliminiert das Risiko, einen Task-Abbruch zu vergessen.

struct ArticlesView: View {
    @State var articles: [Article] = []
    @State var error: Error?
    
    var body: some View {
        List(articles) { article in
            Text(article.title)
        }
        .task {
            do {
                articles = await APIClient().fetchArticles()
            } catch {
                self.error = error
            }
        }
    }
}

.task vs .onAppear: Hauptunterschiede

Viele Entwickler sind es gewohnt, Daten in .onAppear zu laden, aber mit dem Aufkommen von async/await und .task ist dieser Ansatz veraltet. .onAppear führt Code synchron aus — für asynchrone Operationen innerhalb von .onAppear muss der Aufruf in Task { } gewrappt und manuell eine Referenz für den möglichen Abbruch vorgehalten werden. .task erledigt dies automatisch.

.onAppear ist weiterhin nützlich für synchrone Operationen — zum Beispiel Logging oder initiale UI-Einrichtung. Aber für asynchrones Datenladen, Netzwerkanfragen, Datenbank- oder Dateisystemoperationen verwenden Sie .task. Es ist sicherer und architektonisch sauberer.

// ❌ Legacy-Ansatz: Task in .onAppear ohne Abbruch
var loadTask: Task<Void, Never>?
func body() { var body: some View { Text("") }
    .onAppear {
        loadTask = Task { await loadData() }
    }
    .onDisappear { loadTask?.cancel() }

// ✅ Moderner Ansatz: .task verwaltet Abbruch
func body() { var body: some View { Text("") }
    .task { await loadData() }

.task(id:) — Neustart bei Datenänderung

Der .task(id:)-Modifikator akzeptiert einen zusätzlichen Parameter — einen Identifikator. Wenn sich der Wert des Identifikators ändert, bricht SwiftUI den aktuellen Task ab und startet einen neuen mit dem neuen Identifikator. Dies ist ideal für Bildschirme, bei denen Daten von einem ausgewählten Parameter abhängen — zum Beispiel eine Artikelliste nach Kategorie oder Produktdetails nach ID.

struct CategoryView: View {
    let categoryId: Int
    @State var items: [Item] = []
    
    var body: some View {
        List(items) { item in
            Text(item.name)
        }
        .task(id: categoryId) {
            await loadItems(for: categoryId)
        }
    }
    
    func loadItems(for id: Int) async {
        do {
            items = await APIClient().fetchItems(categoryId: id)
        } catch {
            // Fehler behandeln
        }
    }
}

Wenn sich categoryId ändert, bricht SwiftUI die vorherige Anfrage ab und startet eine neue. Dies ist besonders wichtig bei schnellen Kategoriewechseln — alte Anfragen konkurrieren nicht mit neuen um die Statusaktualisierung. Ohne .task(id:) müssten Sie Änderungen manuell über .onChange verfolgen und den Task manuell verwalten.

Task-Abbruch und isCancelled-Prüfung

Obwohl .task den Task beim Verschwinden der View automatisch abbricht, muss die asynchrone Operation selbst kooperativ den Abbruch prüfen. Swift verwendet ein kooperatives Abbruchmodell — Task.cancel() stoppt die Ausführung nicht zwangsweise, sondern setzt lediglich das Flag isCancelled. Der Code innerhalb des Tasks sollte dieses Flag regelmäßig prüfen.

struct LoadingView: View {
    @State var progress: Double = 0
    
    var body: some View {
        ProgressView(value: progress)
            .task {
                for i in 0..<100 {
                    // Abbruch prüfen
                    try Task.checkCancellation()
                    
                    await Task.sleep(nanoseconds: 50_000_000)
                    progress = Double(i + 1) / 100.0
                }
            }
    }
}

Task.checkCancellation() wirft CancellationError, wenn der Task abgebrochen wurde. Dies ist die einfachste Prüfmethode — sie funktioniert in jedem async-Kontext. Eine Alternative ist die manuelle Prüfung von Task.isCancelled vor aufwändigen Operationen. Bei URLSession werden Netzwerkanfragen automatisch abgebrochen, wenn der Task abgebrochen wird, da URLSession Structured Concurrency nativ unterstützt.

Praktische .task-Beispiele

.task eignet sich für viele Szenarien: vom einfachen JSON-Laden bis zu komplexen parallelen Operationen mit TaskGroup. Betrachten wir drei typische Anwendungsfälle.

Laden mit Fehlerbehandlung

struct ProfileView: View {
    @State var profile: Profile?
    @State var isLoading = true
    
    var body: some View {
        Group {
            if isLoading {
                ProgressView()
            } else if let profile {
                Text(profile.name)
            } else {
                Text("Laden fehlgeschlagen")
            }
        }
        .task {
            defer { isLoading = false }
            do {
                profile = await APIClient().fetchProfile()
            } catch {
                // Profil bleibt nil
            }
        }
    }
}

Paralleles Laden mit TaskGroup

struct DashboardView: View {
    @State var stats: DashboardStats?
    
    var body: some View {
        Text("Dashboard")
            .task {
                stats = await Task {
                    await withThrowingTaskGroup { group in
                        group.addTask { await API().fetchUsers() }
                        group.addTask { await API().fetchOrders() }
                        group.addTask { await API().fetchRevenue() }
                        
                        return DashboardStats(
                            users: try await group.next(),
                            orders: try await group.next(),
                            revenue: try await group.next()
                        )
                    }
                }.value
            }
    }
}

Häufige .task-Fehler

Der häufigste Fehler ist das Mutieren von UI-Eigenschaften innerhalb von .task ohne Umschalten auf den Hauptthread. Obwohl SwiftUI Aktualisierungen automatisch an den Hauptthread zurückgibt, wenn @State in einem async-Kontext geändert wird, können direkte Manipulationen von UIKit-Elementen innerhalb von .task einen Absturz verursachen.

• try/catch vergessen — .task behandelt Fehler nicht automatisch. Alle throwing-Funktionen müssen in do/catch eingewickelt werden, sonst stürzt die App ab.
• Race Condition — wenn mehrere .task(id:) mit verschiedenen ids gestartet werden und denselben Status aktualisieren, können Wettlaufsituationen auftreten. Verwenden Sie separate Eigenschaften für verschiedene Datenquellen.
• Lange synchrone Operationen — .task macht synchronen Code nicht asynchron. Wenn innerhalb von .task schwere synchrone Arbeit anfällt, wickeln Sie sie in Task.detached oder verschieben Sie sie in eine separate async-Methode.
• CancellationError ignorieren — bei der Prüfung von Task.checkCancellation() sollte CancellationError nach oben propagiert, nicht unterdrückt werden. Das Unterdrücken von Abbruch kann zu Speicherlecks führen.

// ❌ Fehler: keine Fehlerbehandlung
.task {
    let data = await fetchData() // stürzt bei Fehler ab!
    items = data
}

// ✅ Richtig: do/catch
.task {
    do {
        items = await fetchData()
    } catch {
        errorMessage = error.localizedDescription
    }
}