Architektur: MVVM, und wann du es nicht brauchst

Das Problem: Wohin mit dem Code?

Je größer eine App wird, desto häufiger stellst du dir Fragen wie:

• Gehört diese Berechnung in die View oder woanders hin?
• Wo lade ich die Daten aus dem Internet?
• Wie teste ich, ob meine Logik stimmt, ohne jedes Mal die App zu starten?

Darauf gibt es keine einzige richtige Antwort, aber bewährte Muster. Das bekannteste in der Apple-Welt heißt MVVM. Es wird so oft empfohlen, dass viele Anfänger glauben, sie müssten es verwenden. Diese Lektion zeigt dir, was dahintersteckt, und wann es sinnvoll ist.

Was ist Architektur?

Architektur heißt in der Softwareentwicklung: Wie teilst du den Code auf, und wer darf mit wem sprechen? Gute Architektur sorgt dafür, dass

• jeder Teil eine klare Aufgabe hat,
• du Teile unabhängig ändern kannst,
• du Logik testen kannst, ohne die Oberfläche zu brauchen,
• sich auch ein anderer im Code zurechtfindet.

Schlechte Architektur merkt man daran, dass jede kleine Änderung an fünf Stellen etwas kaputt macht.

MVVM in drei Teilen

MVVM steht für Model – View – ViewModel:

┌──────────┐   liest / ruft auf   ┌─────────────┐   verwendet   ┌─────────┐
│   View   │ ───────────────────▶ │  ViewModel  │ ────────────▶ │  Model  │
└──────────┘ ◀─────────────────── └─────────────┘               └─────────┘
               beobachtet Änderungen

Die View kennt das ViewModel. Das ViewModel kennt das Model. Aber das ViewModel kennt keine View. Es weiß nicht, ob seine Daten als Liste, als Raster oder gar nicht angezeigt werden.

Ein Beispiel

Ein Bildschirm, der Bücher anzeigt, filtert und sortiert:

Model:

struct Book: Identifiable {
    let id = UUID()
    var title: String
    var author: String
    var isRead: Bool
}

ViewModel:

@Observable
class BookListViewModel {
    var books: [Book] = []
    var searchText = ""
    var showOnlyUnread = false

    var visibleBooks: [Book] {
        books
            .filter { !showOnlyUnread || !$0.isRead }
            .filter { searchText.isEmpty || $0.title.localizedCaseInsensitiveContains(searchText) }
            .sorted { $0.title < $1.title }
    }

    var summary: String {
        let unread = books.filter { !$0.isRead }.count
        return "\(unread) von \(books.count) ungelesen"
    }

    func toggleRead(_ book: Book) {
        guard let index = books.firstIndex(where: { $0.id == book.id }) else { return }
        books[index].isRead.toggle()
    }
}

View:

struct BookListView: View {
    @State private var viewModel = BookListViewModel()

    var body: some View {
        NavigationStack {
            List {
                Toggle("Nur ungelesene", isOn: $viewModel.showOnlyUnread)
                Section(viewModel.summary) {
                    ForEach(viewModel.visibleBooks) { book in
                        Button(book.title) {
                            viewModel.toggleRead(book)
                        }
                    }
                }
            }
            .navigationTitle("Bücher")
        }
    }
}

Die View enthält keine einzige Zeile Logik mehr. Filtern, Sortieren, Zusammenfassen, Umschalten: alles steht im ViewModel.

Der große Vorteil: Testbarkeit

Weil das ViewModel nichts von SwiftUI weiß, kannst du es ohne Oberfläche testen:

let viewModel = BookListViewModel()
viewModel.books = [
    Book(title: "Momo", author: "Ende", isRead: true),
    Book(title: "Krabat", author: "Preußler", isRead: false)
]
viewModel.showOnlyUnread = true

print(viewModel.visibleBooks.map(\.title))   // ["Krabat"]
print(viewModel.summary)                      // "1 von 2 ungelesen"

Das könntest du sogar in einem Playground ausprobieren. In Lektion 4.10 lernst du, solche Prüfungen als automatische Tests zu schreiben, die bei jeder Änderung laufen.

map(\.title) ist übrigens eine Kurzform für map { $0.title }, ein Key Path als Funktion.

Wann du MVVM nicht brauchst

Jetzt der wichtige Teil: MVVM ist kein Muss. In SwiftUI ist die View selbst schon sehr leichtgewichtig und deklarativ. Für viele Bildschirme wäre ein eigenes ViewModel reiner Mehraufwand.

Kein ViewModel nötig, wenn:

• die View nur anzeigt, was sie bekommt,
• die Logik aus ein, zwei Zeilen besteht,
• der Zustand nur diese View betrifft, etwa ein offenes Sheet,
• die Daten bereits aus einem geteilten Store oder aus SwiftData kommen.

// Braucht kein ViewModel
struct BookRow: View {
    let book: Book

    var body: some View {
        VStack(alignment: .leading) {
            Text(book.title).font(.headline)
            Text(book.author).foregroundStyle(.secondary)
        }
    }
}

Ein pragmatischer Ansatz

Für die meisten Apps in diesem Kurs bewährt sich diese Aufteilung:

1. Models sind Structs (oder später SwiftData-Klassen) mit Daten und kleinen Regeln, wie Habit.isDoneToday oder Habit.streak.
2. Ein oder wenige Stores (@Observable) verwalten die Daten der App und bieten Methoden zum Ändern an. Sie liegen meist in der Umgebung (Lektion 3.3).
3. Views lesen aus Stores und Models und rufen deren Methoden auf.
4. Ein ViewModel für einen Bildschirm kommt erst dazu, wenn dieser Bildschirm eigene, nicht triviale Logik hat, etwa Laden aus dem Internet, komplexes Filtern oder mehrstufige Formulare.

Projektstruktur

Unabhängig vom Muster hilft eine klare Ordnerstruktur. Ein bewährter Vorschlag:

MyApp/
 ├─ App/
 │   └─ MyApp.swift
 ├─ Models/
 │   ├─ Book.swift
 │   └─ BookStore.swift
 ├─ Features/
 │   ├─ BookList/
 │   │   ├─ BookListView.swift
 │   │   ├─ BookListViewModel.swift
 │   │   └─ BookRow.swift
 │   └─ Settings/
 │       └─ SettingsView.swift
 ├─ Components/
 │   └─ Card.swift
 └─ Resources/
     └─ Assets.xcassets

Ordnen nach Funktionen (Features) statt nach Typen hat einen großen Vorteil: Alles, was zu einem Bildschirm gehört, liegt beieinander. Willst du die Bücherliste ändern, musst du nicht in drei Ordnern suchen.

Typische Fehler

ViewModel kennt die View

@Observable
class LoginViewModel {
    var errorText: Text?   // ⚠️ SwiftUI-Typ im ViewModel
}

Das ViewModel sollte keine Views oder SwiftUI-Typen enthalten. Speichere einen String, und die View macht daraus einen Text.

Daten doppelt halten

Zwei ViewModels haben je eine eigene Kopie derselben Bücherliste. Ändert sich die eine, ist die andere veraltet. Geteilte Daten gehören in einen Store, ViewModels greifen darauf zu.

ViewModel ohne @State

let viewModel = BookListViewModel()   // ⚠️

Wie jedes eigene Objekt: Die View, die das ViewModel erzeugt, hält es mit @State (Lektion 3.1).

FAQ

Übungen

Zusammenfassung

• Architektur bestimmt, wie Code aufgeteilt ist und wer mit wem spricht.
• MVVM: Model (Daten), View (Darstellung), ViewModel (Aufbereitung und Logik für einen Bildschirm).
• Das ViewModel ist eine @Observable-Klasse, die keine Views kennt und sich dadurch gut testen lässt.
• Nicht jede View braucht ein ViewModel. Fang einfach an und zieh Logik heraus, wenn es nötig wird.
• Ordne Projekte nach Features statt nach Dateitypen.

Spickzettel

// Model
struct Book: Identifiable { let id = UUID(); var title: String; var isRead: Bool }

// ViewModel
@Observable
class BookListViewModel {
    var books: [Book] = []
    var searchText = ""
    var visibleBooks: [Book] { books.filter { searchText.isEmpty || $0.title.localizedCaseInsensitiveContains(searchText) } }
    func toggleRead(_ book: Book) { ... }
}

// View
struct BookListView: View {
    @State private var viewModel = BookListViewModel()
    var body: some View { List(viewModel.visibleBooks) { ... } }
}