Claude für Mobile App Entwicklung: iOS mit Swift, Android mit Kotlin

1. Warum mobile App-Entwicklung von Claude profitiert

Mobile Entwicklung für iOS und Android verlangt tiefes Wissen über zwei unterschiedliche Plattformen mit eigenen UI-Frameworks, Lebenszyklen und Store-Richtlinien, was den Kontextwechsel zwischen beiden Ökosystemen aufwendig macht. Claude kennt die Eigenheiten von SwiftUI und Jetpack Compose gleichermaßen und hilft, plattformspezifische Muster korrekt anzuwenden, statt Konzepte unreflektiert von einer Plattform auf die andere zu übertragen, was in der mobilen Entwicklung besonders häufig zu subtilen Bugs führt.

Der praktische Nutzen zeigt sich vor allem bei wiederkehrenden Aufgaben: neue Screens mit korrektem State-Management aufsetzen, Berechtigungsanfragen nach den aktuellen Store-Richtlinien formulieren, Performance-Probleme in Listen identifizieren und plattformübergreifende Architekturentscheidungen fundiert abwägen. Die folgenden Abschnitte zeigen konkret, wie Claude bei SwiftUI, Jetpack Compose, Lebenszyklen, geteilter Logik und Store-Konformität unterstützt.

2. SwiftUI-State-Management mit Claude sauber entwerfen

SwiftUI bietet mehrere Property Wrapper für State-Management, deren korrekte Verwendung nicht immer offensichtlich ist: @State für lokalen View-Zustand, @StateObject für Objekte, die von der View selbst erzeugt und besessen werden, @ObservedObject für Objekte, die von außen übergeben werden, und @EnvironmentObject für Zustand, der über die View-Hierarchie hinweg geteilt wird. Ein häufiger Fehler ist, @StateObject und @ObservedObject zu verwechseln, was dazu führt, dass ein Observable-Objekt bei jedem Re-Render der Elternview neu erzeugt wird und seinen Zustand verliert.

Claude erkennt dieses Muster zuverlässig im Code-Review und erklärt den Unterschied konkret anhand der Objektlebensdauer: Wenn eine View das Objekt besitzt und für dessen Lebenszyklus verantwortlich ist, gehört @StateObject an diese Stelle. Wird das Objekt von einer übergeordneten View hereingereicht, ist @ObservedObject korrekt. Mit dem neueren @Observable-Makro aus dem Observation-Framework vereinfacht sich diese Unterscheidung zusätzlich, weil weniger explizite Wrapper nötig sind, Claude weist aber auch hier auf die verbleibenden Fallstricke bei der Objekterzeugung hin.

// OrderListView.swift - correct ownership with @StateObject vs @ObservedObject
import SwiftUI

// The view creates and owns this view model, so use @StateObject
struct OrderListView: View {
    @StateObject private var viewModel = OrderListViewModel()

    var body: some View {
        List(viewModel.orders) { order in
            OrderRowView(order: order)
        }
        .task {
            await viewModel.loadOrders()
        }
    }
}

// This view receives an already-created view model, so use @ObservedObject
struct OrderRowView: View {
    @ObservedObject var order: OrderRowViewModel

    var body: some View {
        HStack {
            Text(order.title)
            Spacer()
            Text(order.formattedTotal)
        }
    }
}

3. Jetpack Compose und Recomposition verstehen

Jetpack Compose folgt einem deklarativen Modell ähnlich SwiftUI, aber mit einem eigenen Recomposition-Mechanismus, der bei falscher Anwendung zu unnötigen Neuberechnungen ganzer Composable-Bäume führt. Ein klassisches Problem: eine Lambda-Funktion wird direkt in einem Composable-Parameter erzeugt, statt mit remember stabilisiert zu werden, wodurch Compose bei jeder Recomposition eine neue Instanz erkennt und unnötig neu zeichnet, selbst wenn sich die zugrunde liegenden Daten nicht geändert haben.

Claude prüft Composables gezielt auf fehlende Stabilität: Parameter, die keine @Stable- oder @Immutable-annotierten Typen sind, können Recomposition-Skipping verhindern, was bei Listen mit vielen Elementen spürbare Performance-Einbußen verursacht. Für LazyColumn und LazyRow schlägt Claude konsequent stabile key-Parameter vor, damit Compose Elemente über Listenänderungen hinweg korrekt zuordnen kann, statt bei jeder Änderung die gesamte Liste neu zu zeichnen.

// OrderList.kt - stable keys and remembered callbacks for correct recomposition
@Composable
fun OrderList(
    orders: List<Order>,
    onOrderClick: (String) -> Unit,
) {
    LazyColumn {
        items(
            items = orders,
            key = { order -> order.id }, // stable key avoids full redraw
        ) { order ->
            OrderRow(
                order = order,
                onClick = remember(order.id) { { onOrderClick(order.id) } },
            )
        }
    }
}

@Composable
fun OrderRow(order: Order, onClick: () -> Unit) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .clickable(onClick = onClick)
            .padding(16.dp),
    ) {
        Text(order.title, modifier = Modifier.weight(1f))
        Text(order.formattedTotal)
    }
}

4. Plattformspezifische Lebenszyklen richtig behandeln

iOS und Android unterscheiden sich fundamental im Umgang mit App-Lebenszyklen: Android kann eine Activity jederzeit durch das System beenden und später mit gespeichertem Zustand wiederherstellen, während iOS-Apps beim Wechsel in den Hintergrund typischerweise vollständig im Speicher verbleiben, aber nach längerer Inaktivität ebenfalls beendet werden können. Claude weist bei neuem Code konsequent darauf hin, wenn Zustand nicht überlebensfähig gespeichert wird, etwa über SavedStateHandle unter Android oder NSUserActivity und Scene-Restoration unter iOS.

Ein häufiger Fehler, den Claude im Review findet, ist die Annahme, dass ein ViewModel oder eine Observable-Klasse über den gesamten App-Lebenszyklus hinweg im selben Zustand bleibt. Unter Android überlebt ein ViewModel zwar Konfigurationsänderungen wie Bildschirmrotation, nicht aber einen Prozess-Kill durch das System unter Speicherdruck. Claude schlägt deshalb konsequent vor, kritischen Zustand zusätzlich in SavedStateHandle zu sichern, statt sich allein auf den In-Memory-Zustand des ViewModels zu verlassen.

5. Geteilte Geschäftslogik: Kotlin Multiplatform als Option

Kotlin Multiplatform, kurz KMP, erlaubt es, Geschäftslogik, Netzwerkschicht und Datenmodelle einmal in Kotlin zu schreiben und sowohl von iOS als auch von Android aus zu nutzen, während die UI-Schicht weiterhin nativ mit SwiftUI beziehungsweise Jetpack Compose bleibt. Claude hilft bei der Entscheidung, welche Schichten sich für KMP eignen: Netzwerkaufrufe, Serialisierung, Caching-Logik und Validierungsregeln lassen sich gut teilen, während UI-nahe Logik mit starker Plattformabhängigkeit meist besser plattformspezifisch bleibt.

Bei der Umsetzung schlägt Claude vor, die geteilte Schicht über ein klares Interface zu kapseln, das von beiden Plattformen aus konsumiert wird, statt Implementierungsdetails der geteilten Bibliothek in die native UI-Schicht durchsickern zu lassen. Diese Trennung erleichtert es, bei Bedarf später einzelne Teile doch plattformspezifisch zu implementieren, ohne die gesamte Architektur umzubauen.

6. Berechtigungen, Datenschutz und Store-Richtlinien

App-Store- und Play-Store-Richtlinien ändern sich regelmäßig, insbesondere bei Berechtigungsanfragen und Datenschutzerklärungen, und Verstöße führen zuverlässig zur Ablehnung im Review-Prozess. Claude kennt die aktuellen Anforderungen an Info.plist-Nutzungsbeschreibungen unter iOS, etwa dass eine Berechtigungsanfrage für Standortdaten eine spezifische, nachvollziehbare Begründung enthalten muss, statt einer generischen Formulierung, die Apple im Review häufig zurückweist.

Unter Android hilft Claude beim korrekten Umgang mit Runtime-Permissions und der Unterscheidung zwischen normalen und gefährlichen Berechtigungen, sowie bei der Formulierung der Datenschutzangaben für die Play-Store-Datensicherheitssektion. Ein wiederkehrendes Problem, das Claude im Review findet: Eine App fragt eine Berechtigung beim App-Start ab, statt sie erst im konkreten Nutzungskontext anzufordern, was sowohl der empfohlenen Praxis widerspricht als auch die Nutzerakzeptanz senkt.

7. Performance-Probleme in Listen und Animationen finden

Ruckelnde Listen und Animationen sind eines der sichtbarsten Qualitätsprobleme mobiler Apps, und die Ursache liegt in den meisten Fällen in unnötiger Arbeit während des Renderings: teure Berechnungen direkt im Body einer SwiftUI-View statt in einem gecachten Wert, fehlende key-Parameter in Compose-Listen, oder Bilder, die in voller Auflösung geladen werden, obwohl nur eine kleine Vorschau benötigt wird. Claude prüft diese Muster gezielt beim Review von Listen- und Animationscode.

Für Bildlisten schlägt Claude konsequent Bild-Caching und Downsampling auf die tatsächlich benötigte Anzeigegröße vor, statt großformatige Originalbilder direkt zu dekodieren und im Speicher zu halten. Bei Animationen weist Claude darauf hin, wenn eine Animation auf dem Hauptthread berechnet wird, statt die von der Plattform bereitgestellten, GPU-beschleunigten Animationsprimitive wie SwiftUI-withAnimation oder Compose-animateFloatAsState zu nutzen.

8. UI-Tests für SwiftUI und Compose generieren lassen

Für SwiftUI schlägt Claude UI-Tests mit dem XCTest-Framework vor, die über Accessibility-Identifier auf Elemente zugreifen, statt sich auf sichtbaren Text zu verlassen, der sich bei Lokalisierung ändert. Für Jetpack Compose empfiehlt Claude die ComposeTestRule mit semantischen Matchern, die ebenfalls unabhängig von der angezeigten Sprache funktionieren. In beiden Fällen achtet Claude darauf, dass Tests nicht auf feste Wartezeiten, sondern auf tatsächliche UI-Zustände warten, um Flakiness zu vermeiden.

Für Geschäftslogik außerhalb der UI-Schicht schlägt Claude klassische Unit-Tests vor, die unabhängig vom UI-Framework laufen, was die Testsuite deutlich schneller macht als reine UI-Tests. Diese Trennung zwischen schnellen Unit-Tests für Logik und langsameren UI-Tests für die eigentliche Bedienbarkeit folgt der klassischen Testpyramide und wird von Claude bei neuen Testvorschlägen konsequent eingehalten.

// OrderListScreenTest.kt - Compose UI test with semantic matchers
@get:Rule
val composeTestRule = createComposeRule()

@Test
fun orderList_showsOrderTitles() {
    composeTestRule.setContent {
        OrderList(
            orders = listOf(Order(id = "1", title = "Test Order", total = 42.0)),
            onOrderClick = {},
        )
    }

    composeTestRule
        .onNodeWithText("Test Order")
        .assertIsDisplayed()
}

9. iOS- und Android-Entwicklung im direkten Vergleich

Viele Konzepte in SwiftUI und Jetpack Compose ähneln sich konzeptionell, unterscheiden sich aber in der konkreten Umsetzung und den typischen Fallstricken deutlich.

Der gemeinsame Nenner beider Plattformen ist das deklarative UI-Paradigma, das jedoch unterschiedliche Stabilitäts- und Ownership-Regeln mit sich bringt. Claude hilft, diese Unterschiede korrekt anzuwenden, statt Muster unreflektiert von einer Plattform auf die andere zu übertragen.

10. Zusammenfassung

Claude unterstützt mobile App-Entwicklung am wirkungsvollsten dort, wo plattformspezifisches Wissen entscheidend ist: korrektes State-Management mit @StateObject und remember, stabile Recomposition in Jetpack Compose, robuste Behandlung von Prozess-Kills und Lebenszyklen sowie die Einhaltung aktueller Store-Richtlinien für Berechtigungen und Datenschutz. Bei korrekter Anleitung unterscheidet Claude zuverlässig zwischen iOS- und Android-typischen Mustern, statt Konzepte unreflektiert zu übertragen.

Der größte praktische Nutzen entsteht bei wiederkehrenden Aufgaben wie neuen Screens, Performance-Reviews für Listen und der Entscheidung zwischen nativer und geteilter Logik über Kotlin Multiplatform. Wer diese Muster konsequent mit Claude als Pair-Programming-Partner umsetzt, reduziert sowohl Store-Ablehnungen als auch subtile Performance-Probleme deutlich.

11. FAQ: Claude für Mobile App Entwicklung