Compose Multiplatform vs SwiftUI Vergleich

Eine einzige UI-Codebasis in Kotlin für Android + iOS + Desktop + Web

VS
SwiftUI

Apples natives, deklaratives UI-Framework — die gemeinsame Sprache der gesamten Plattformfamilie

21 Min. LesezeitCross-Platform

Schnelles Fazit

Wenn du ein starkes Android/Kotlin-Team hast und mit möglichst geringem Zusatzaufwand auf iOS expandieren willst, ist Compose Multiplatform sinnvoll: Das iOS-Target ist seit Mai 2025 Stable. Aber in einem Produkt, bei dem iOS das Schaufenster ist und Neuerungen wie Liquid Glass (iOS 26+) ab Tag 0 genutzt werden müssen, ist SwiftUI kaum zu schlagen — sogar die offizielle Dokumentation empfiehlt dafür eine native SwiftUI-Hülle. Bei der Größe stehen offizielle ~9 MB einem in einem unabhängigen Einzelfall gemeldeten 12-fachen Unterschied gegenüber; miss dein eigenes Prototyp auf einem echten Gerät.

Compose MultiplatformSwiftUI
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Compose Multiplatform und SwiftUI — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieCompose MultiplatformSwiftUI
Performance
7/10
9/10
Erlernbarkeit
6/10
7/10
Ökosystem
6/10
9/10
Community
6/10
9/10
Arbeitsmarkt
5/10
9/10
Zukunftssicherheit
7/10
9/10

Vor- und Nachteile

Compose Multiplatform

Vorteile

  • Der Großteil des UI-Codes lässt sich zwischen Android und iOS teilen — die Respawn-App ist mit einer Teilungsrate von 96 % in Produktion
  • Ein einziges Kotlin-Team kann beide Plattformen gleichzeitig entwickeln, ohne ein separates iOS-Team aufzubauen
  • Das iOS-Target ist seit Mai 2025 (1.8.0) offiziell Stable und produktionsreif
  • VoiceOver, AssistiveTouch und Full Keyboard Access kommen mit offizieller erstklassiger Unterstützung
  • Scroll-Physik, Textauswahl und Navigationsgesten wurden dem nativen iOS-Verhalten angenähert
  • Es gibt Interop mit UIKit und SwiftUI — bestehende native Screens lassen sich schrittweise an Compose anbinden
  • Der klibs.io-Katalog und die Multiplatform-Unterstützung der Jetpack-Bibliotheken wachsen schnell
  • Auch die Targets Desktop (Stable) und Web (Kotlin/Wasm, Beta) lassen sich aus derselben Codebasis öffnen

Nachteile

  • In einem unabhängigen Entwicklerfall lag die App-Größe deutlich über JetBrains' Angabe von ~9 MB (zwischen zwei separaten Apps wurde ein bis zu 12-facher Unterschied gemeldet)
  • Für Systemebenen-Designsprachen (Liquid Glass seit iOS 26) empfiehlt die offizielle Dokumentation den Rückgriff auf eine native SwiftUI-Hülle
  • Barrierefreiheit läuft über eine Mapping-Schicht von Compose-Semantics zu iOS-Objekten — nicht wie bei SwiftUI auf derselben Ebene wie das System selbst
  • Es gibt kein Live-Preview-Erlebnis auf Xcode-Previews-Niveau — Compose Preview benötigt ein Android-Target, Hot Reload ist auf iOS-Seite nur für Desktop-JVM offiziell
  • Kennt das Team kein Kotlin, bringen Lernkurve und Plattformbrücken (expect/actual) zusätzliche Komplexität mit sich

Am besten geeignet für

Unternehmen mit bereits starkem Android/Compose-Team, die mit möglichst geringem Zusatzaufwand auf iOS expandieren wollenMittelgroße Produkte, deren Geschäftslogik größtenteils schon in Kotlin liegt und die auch die UI teilen wollenInterne Tools und B2B-Anwendungen, die gleichzeitig Android + iOS + Desktop anvisierenProdukte, bei denen das Designsystem plattformübergreifend eins zu eins konsistent sein mussTeams, die in einer schnellen MVP-/Validierungsphase mit einem einzigen Team gleichzeitig in beiden Stores erscheinen wollen

SwiftUI

Vorteile

  • Bietet ab Tag 0 nativen Zugriff auf jede neue Systemkomponente von iOS (z. B. Liquid Glass in iOS 26/27)
  • Bietet mit Xcode Previews ein Live-Preview-Erlebnis mit Feedback in Sekundenschnelle
  • VoiceOver und die Accessibility-API-Oberfläche sind tiefgehend und offiziell lückenlos dokumentiert
  • Da es Apples eigenes Framework ist, verlaufen App-Store-Review und HIG-Konformität reibungslos
  • Lässt sich mit einer einzigen Sprache (Swift) auf iPhone, iPad, Mac, Apple Watch, Apple TV und Vision Pro ausweiten
  • Scroll-Physik, Tastaturverhalten und Zurück-Geste sind eins zu eins identisch mit dem System — weil es das System selbst ist
  • Direkter, brückenloser Zugriff auf tiefe Plattform-APIs (Core Animation, AVFoundation, Metal)
  • Apples langfristiger, erstpriorisierter Investitionsbereich — jede WWDC bringt eine große Erweiterung

Nachteile

  • Läuft nur auf Apple-Plattformen — für die Android-Seite ist ein separates Team/eine separate Codebasis nötig
  • Bei einem zweiplattformigen (Android+iOS) Produkt lässt sich der UI-Code nicht teilen, die Geschäftslogik muss in einer separaten Schicht gehalten werden
  • Bei manchen komplexen, individuellen Layout- und Zeichenszenarien muss man noch auf UIKit/Core Graphics zurückgreifen
  • Soll die App im App Store vertrieben werden, ist eine Registrierung im Apple Developer Program (99 USD/Jahr) verpflichtend

Am besten geeignet für

Unternehmen, bei denen iOS das Hauptschaufenster des Produkts ist und HIG-Konformität sowie neue OS-Funktionen ab Tag 0 genutzt werden müssenApps, die auf Apple-Plattformen ohne UIKit erscheinen, wie Vision Pro/visionOS oder watchOSProdukte, die tief in das Apple-Ökosystem eingebunden sind (Widget, Live Activities, App Intents)Projekte kleiner bis mittelgroßer Teams, die sich mit schneller Iteration auf eine einzige Plattform (iOS) konzentrierenTeams, die eine bestehende, große SwiftUI/UIKit-Codebasis unverändert weiter ausbauen

Code-Vergleich

Compose Multiplatform
// Compose Multiplatform - commonMain: geteilte Profilkarte
// (build.gradle.kts: kotlin { androidTarget(); iosArm64(); iosSimulatorArm64() })
import androidx.compose.foundation.layout.*
import androidx.compose.foundation.shape.CircleShape
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.*
import androidx.compose.ui.draw.clip
import androidx.compose.ui.unit.dp
import coil3.compose.AsyncImage

@Composable
fun ProfileCard(user: User, modifier: Modifier = Modifier) {
    var isFollowing by remember { mutableStateOf(false) }

    Row(
        modifier = modifier.fillMaxWidth().padding(16.dp),
        verticalAlignment = Alignment.CenterVertically
    ) {
        AsyncImage(
            model = user.avatarUrl,
            contentDescription = user.name,
            modifier = Modifier.size(64.dp).clip(CircleShape)
        )
        Spacer(Modifier.width(12.dp))
        Column(modifier = Modifier.weight(1f)) {
            Text(user.name, style = MaterialTheme.typography.titleMedium)
            Text(user.title, style = MaterialTheme.typography.bodySmall)
        }
        OutlinedButton(onClick = { isFollowing = !isFollowing }) {
            Text(if (isFollowing) "Nicht mehr folgen" else "Folgen")
        }
    }
}

// iosMain: CMP-View als UIViewController exportieren
fun MainViewController() = ComposeUIViewController { ProfileCard(user = sampleUser) }
SwiftUI
// SwiftUI - Profilkarte
import SwiftUI

struct ProfileCard: View {
    let user: User
    @State private var isFollowing = false

    var body: some View {
        HStack(spacing: 12) {
            AsyncImage(url: user.avatarURL) { image in
                image.resizable().scaledToFill()
            } placeholder: {
                ProgressView()
            }
            .frame(width: 64, height: 64)
            .clipShape(Circle())

            VStack(alignment: .leading) {
                Text(user.name)
                    .font(.headline)
                Text(user.title)
                    .font(.subheadline)
                    .foregroundStyle(.secondary)
            }

            Spacer()

            Button(isFollowing ? "Nicht mehr folgen" : "Folgen") {
                withAnimation(.spring(response: 0.3)) {
                    isFollowing.toggle()
                }
            }
            .buttonStyle(.bordered)
        }
        .padding()
    }
}

#Preview {
    ProfileCard(user: .sample)
}

Fazit

Wenn du ein starkes Android/Kotlin-Team hast und mit möglichst geringem Zusatzaufwand auf iOS expandieren willst, ist Compose Multiplatform sinnvoll: Das iOS-Target ist seit Mai 2025 Stable. Aber in einem Produkt, bei dem iOS das Schaufenster ist und Neuerungen wie Liquid Glass (iOS 26+) ab Tag 0 genutzt werden müssen, ist SwiftUI kaum zu schlagen — sogar die offizielle Dokumentation empfiehlt dafür eine native SwiftUI-Hülle. Bei der Größe stehen offizielle ~9 MB einem in einem unabhängigen Einzelfall gemeldeten 12-fachen Unterschied gegenüber; miss dein eigenes Prototyp auf einem echten Gerät.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Ja — JetBrains hat im Mai 2025 mit CMP 1.8.0 das iOS-Target offiziell als Stable und produktionsreif erklärt; typsichere Navigation, erstklassige VoiceOver-Unterstützung und SwiftUI/UIKit-Interop wurden abgeschlossen. Aber „bereit“ bedeutet nicht für jedes Projekt die richtige Wahl: Ein am 2. August 2026 veröffentlichter, unabhängiger Erfahrungsbericht eines Entwicklers berichtet bei einer produktiven CMP-App von erheblichen Kompromissen bei Größe und nativem Gefühl (Erfahrung eines einzelnen Entwicklers). Triff die Entscheidung nicht ohne eigene Messung.

Verwandte Blogartikel

Alle Artikel ansehen

Verwandte Projekte

Alle Projekte ansehen
Alle Vergleiche