Kotlin Multiplatform vs React Native Vergleich

Teile nur die Geschäftslogik, lass die UI nativ

VS
React Native

UI und Geschäftslogik gemeinsam aus einer einzigen Codebasis

10 Min. LesezeitCross-Platform

Schnelles Fazit

Es gibt keinen klaren Gewinner – das Szenario entscheidet. Wenn die UI nativ bleiben soll und nur die Netzwerk-/Daten-/Geschäftslogik geteilt werden soll und dein Team Kotlin/Android-nah ist, wähle KMP: Das offizielle Tutorial beschreibt genau, wie du das Shared Module zu Android hinzufügst und es als Xcode-Framework an iOS anbindest. Wenn du Bildschirme aus einer einzigen Codebasis erzeugen und das Web-Team ins Mobile-Projekt einbinden willst, liegt React Native vorn: Das Ökosystem mit 126.703 Stars und der offizielle Leitfaden „Integration with Existing Apps“ unterstützen das.

Kotlin MultiplatformReact Native
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Kotlin Multiplatform und React Native — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieKotlin MultiplatformReact Native
Performance
8/10
7/10
Erlernbarkeit
6/10
7/10
Ökosystem
6/10
9/10
Community
6/10
9/10
Arbeitsmarkt
6/10
7/10
Zukunftssicherheit
8/10
8/10

Vor- und Nachteile

Kotlin Multiplatform

Vorteile

  • Keine neue Sprache zu lernen für ein Kotlin/Android-Team
  • UI bleibt nativ – Plattformgefühl und Barrierefreiheit werden automatisch beibehalten
  • Shared Module lässt sich mit wenig Eingriff in ein bestehendes Gradle-Projekt einfügen
  • Offizieller, langfristiger Support von JetBrains (Kotlin 2.4.20, Support bis 2027)
  • Mit expect/actual plattformspezifischen Code an einer Stelle verwalten
  • Bei Bedarf mit Compose Multiplatform zu optionaler vollständiger UI-Freigabe erweiterbar
  • Apache-2.0-lizenziert, vollständig Open Source und kostenlos

Nachteile

  • Das Ökosystem multiplattform-nativer Bibliotheken ist im Vergleich zu RN klein und jung
  • Erfordert Swift/Xcode-Kenntnisse auf der iOS-Seite (Lernkurve, wenn das Team rein Android-fokussiert ist)
  • Für plattformspezifischen SDK-Zugriff musst du oft eine eigene Brücke schreiben
  • GitHub-Stars (53.451) sind rund 42 % von RN, also weniger als die Hälfte (Repo der Kotlin-Sprache; KMP hat keine eigene Stern-Zahl) – begrenztere Community-Ressourcen
  • Die Gradle-Multiplatform-Konfiguration kann bei der Ersteinrichtung komplex wirken

Am besten geeignet für

Teams mit Kotlin/Android-Skills, die auch die Netzwerk-/Datenschicht an iOS teilen wollenKomplexe, plattformspezifische Bildschirme, bei denen native UI kritisch istSzenarien, in denen eine bestehende Gradle-/Xcode-Pipeline mit minimalem Eingriff erweitert werden sollUnternehmensteams, die eine langfristige, von JetBrains unterstützte Lösung suchen

React Native

Vorteile

  • Web-/React-Kenntnisse übertragen sich direkt, das Team ist schnell produktiv
  • Riesiges npm-Ökosystem – für die meisten nativen Module gibt es bereits eine fertige Bridge
  • Große, aktive Community mit 126.703 GitHub-Stars (etwa das 2,4-Fache von JetBrains/kotlin)
  • Der offizielle Leitfaden „Integration with Existing Apps“ beschreibt klare Schritte zur Einbindung in ein bestehendes Projekt
  • Die New Architecture (Fabric/TurboModules) ist seit 2024 in Metas eigenen Produktionsapps bewährt
  • Mit RN 0.87 ist die Strict-TypeScript-API standardmäßig aktiv – sicherer, typgeprüfter Code
  • MIT-lizenziert, vollständig Open Source und kostenlos

Nachteile

  • Native Komponenten laufen weiterhin über eine JS-Runtime (via JSI) – auch wenn die Bridge seit 0.76 entfernt wurde, entsteht eine zusätzliche Runtime-/JS-Thread-Last; bei KMP wird die UI bereits vom nativen Framework der Plattform selbst gezeichnet
  • Die Mindest-Toolchain von RN 0.87 (Node.js 22, AGP 9, Kotlin 2.0+) erfordert bei älteren Projekten zunächst ein Upgrade
  • Der Wechsel zur Strict-TS-API kann alte Deep-Imports aus internen Pfaden brechen (Breaking Change)
  • Der Integrationsschritt in eine bestehende App ist umfangreicher als bei KMP (Neuordnung der Projektverzeichnisstruktur)
  • Für plattformspezifische Bildschirme mit tiefer Systemintegration muss eine native Modul-Bridge geschrieben werden

Am besten geeignet für

Teams, deren Web-/JS-Team sich auf Mobile ausweitet und die Produktbildschirme schnell erzeugen wollenProdukte mit häufigen A/B-Tests und UI-Iterationen, die Bildschirm-Updates gleichzeitig auf beiden Plattformen wollenProjekte, die fertige Komponenten/Bibliotheken aus dem riesigen npm-Ökosystem nutzen wollenTeams, die die bei Meta im großen Maßstab bewährte New Architecture (Fabric/TurboModules) sicher einführen wollen

Code-Vergleich

Kotlin Multiplatform
// KMP shared module — Hinzufügen zu bestehender Android/iOS App
// shared/src/commonMain/kotlin/data/UserRepository.kt

package com.app.shared.data

import kotlinx.coroutines.flow.Flow
import kotlinx.serialization.Serializable

@Serializable
data class User(val id: String, val name: String, val avatarUrl: String)

// Hinweis: kotlin.Result ist eine value class und wird nicht ins Objective-C exportiert;
// der Rückgabetyp ist direkt User, der Fehlerpfad läuft über throws/completion error.
class UserRepository(private val api: UserApi) {
    suspend fun fetchUser(id: String): User = api.getUser(id)
}

// expect/actual: plattformspezifischer Teil (iOS Keychain / Android EncryptedSharedPreferences)
expect class SecureStorage {
    fun save(key: String, value: String)
    fun read(key: String): String?
}

// shared/build.gradle.kts (Zusammenfassung)
kotlin {
    androidTarget()
    listOf(iosX64(), iosArm64(), iosSimulatorArm64()).forEach {
        it.binaries.framework { baseName = "Shared" }
    }
    sourceSets {
        commonMain.dependencies {
            implementation("io.ktor:ktor-client-core:3.6.0")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.11.0")
        }
    }
}

// Einbindung auf der iOS-Seite als Xcode-Framework (Swift)
import Shared

let repo = UserRepository(api: UserApiImpl())
repo.fetchUser(id: "42") { user, error in
    if let user = user { print(user.name) }
}
React Native
// React Native — Integration in bestehende App; index.js: Bildschirm registrieren

import { AppRegistry } from 'react-native';
import ProfileScreen from './src/ProfileScreen';

AppRegistry.registerComponent('ProfileScreen', () => ProfileScreen);

// src/ProfileScreen.tsx — Strict TypeScript API (Standard seit RN 0.87)
import { View, Text } from 'react-native';

export default function ProfileScreen({ userId }: { userId: string }) {
  return (
    <View style={{ padding: 16 }}>
      <Text style={{ fontSize: 17 }}>Benutzer {userId}</Text>
    </View>
  );
}

// android/app/build.gradle — RN Gradle Plugin (Zusammenfassung)
apply plugin: "com.facebook.react"

react { autolinkLibrariesWithApp() }

// MyReactActivity.kt — Muster aus dem offiziellen Leitfaden
import com.facebook.react.ReactActivity
import com.facebook.react.ReactActivityDelegate
import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.fabricEnabled
import com.facebook.react.defaults.DefaultReactActivityDelegate

class MyReactActivity : ReactActivity() {
  override fun getMainComponentName(): String = "ProfileScreen"
  override fun createReactActivityDelegate(): ReactActivityDelegate =
    DefaultReactActivityDelegate(this, mainComponentName, fabricEnabled)
}

// AndroidManifest.xml: <activity android:name=".MyReactActivity"
//   android:theme="@style/Theme.AppCompat.Light.NoActionBar" />
// aus deiner bestehenden Activity: startActivity(Intent(this, MyReactActivity::class.java))

Fazit

Es gibt keinen klaren Gewinner – das Szenario entscheidet. Wenn die UI nativ bleiben soll und nur die Netzwerk-/Daten-/Geschäftslogik geteilt werden soll und dein Team Kotlin/Android-nah ist, wähle KMP: Das offizielle Tutorial beschreibt genau, wie du das Shared Module zu Android hinzufügst und es als Xcode-Framework an iOS anbindest. Wenn du Bildschirme aus einer einzigen Codebasis erzeugen und das Web-Team ins Mobile-Projekt einbinden willst, liegt React Native vorn: Das Ökosystem mit 126.703 Stars und der offizielle Leitfaden „Integration with Existing Apps“ unterstützen das.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Es gibt keine eindeutige Antwort, das hängt vom Team-Skillset ab: Bist du ein Kotlin/Android-Team und soll die UI nativ bleiben, wähle KMP. Bist du ein Web-/React-Team und willst Bildschirme aus einer einzigen Codebasis erzeugen, wähle React Native. Beide unterstützen offiziell die schrittweise Integration in eine bestehende App.

Verwandte Blogartikel

Alle Artikel ansehen
Alle Vergleiche