KMP w 2026 roku: Architektura, utworzenie i ekosystem wieloplatformowego Kotlin
Przez lata Kotlin Multiplatform (KMP) był nazywany „interesującym, ale jeszcze nie gotowym”. produkcja”. W 2026 roku ta narracja uległa definitywnej zmianie: KMP osiągnęła dojrzałość przedsiębiorstwo ze stabilnym API iOS, Compose Multiplatform stabilny na wszystkich głównych platformach, tj Szybki eksport co ostatecznie eliminuje potrzebę mostkowania Objective-C interoperacyjność z natywnym kodem Swift.
Ten przewodnik zawiera kompleksowy przegląd ekosystemu KMP w 2026 r.: co się zmieniło od tego czasu z poprzednimi latami, jak wypada na tle Flutter i React Native, jaka jest poprawna architektura dla projektu wieloplatformowego i jak ocenić, czy KMP jest właściwym wyborem dla Twojego przypadku użycia.
Czego się nauczysz
- Architektura KMP: moduły współdzielone, zestaw źródłowy i kod specyficzny dla platformy
- KMP vs Flutter vs React Native: porównanie techniczne zaktualizowane do 2026 r
- Swift Export i natywna współpraca z iOS
- Compose Multiplatform: aktualny stan i ograniczenia
- Ekosystem biblioteczny KMP 2026: Ktor, SQLDelight, Koin
- Kiedy wybrać KMP, a kiedy nie
Skok Jakościowy w latach 2025-2026
KMP 1.0 był już stabilny pod względem współdzielenia logiki biznesowej, ale miał ważne ograniczenia: Integracja z iOS wymagała automatycznie generowanych nagłówków Objective-C (niezbyt idiomatycznych dla Swift), a Compose Multiplatform nadal miało wiele interfejsów API w wersji alfa na iOS i komputery stacjonarne.
Główne zmiany, które zaszły w latach 2024-2026:
- Swift Export (stabilny w KMP 1.9+): Wygeneruj natywny interfejs Swift API z nazewnictwem idiomatyczne, protokoły, argumenty domyślne i brak pośredniego celu-C. Twórcy iOS zużywa teraz kod Kotlina tak, jakby był czystym Swiftem.
- Compose Multiplatform 1.7+ (stabilny na iOS): W pełni udostępniony interfejs użytkownika w Kotlin/Compose na Androida, iOS, komputer stacjonarny (JVM) i Internet (Wasm). Silniki renderujące specyficzne dla platformy są już dojrzałe, a wydajność jest akceptowalna nawet w przypadku złożonych aplikacji.
- System kompilacji Ampera (beta): uproszczona alternatywa dla Gradle dla projektów KMP, z konfiguracją YAML zamiast złożonego Kotlin DSL.
- Ulepszone oprzyrządowanie: Android Studio Biedronka i nowsze wersje obsługują KMP światowej klasy z refaktoryzacją międzyplatformową, debugowaniem na wbudowanym symulatorze iOS i profilowaniem.
Architektura projektu KMP
Podstawowa architektura KMP opiera się na separacji współdzielonego kodu (commonMain) i kod specyficzny dla platformy. Nie chodzi o to, by „pisać wszystko raz” jak obiecał React Native, ale aby podzielić się logiką, która ma sens, aby dzielić się i delegować na platformę to, co jest wewnętrznie rodzimy.
// Struttura tipica di un progetto KMP nel 2026
shared/
├── src/
│ ├── commonMain/kotlin/
│ │ ├── data/
│ │ │ ├── repository/ # Repository patterns condivisi
│ │ │ ├── network/ # Ktor client (HTTP multiplatform)
│ │ │ └── local/ # SQLDelight (DB multiplatform)
│ │ ├── domain/
│ │ │ ├── model/ # Data classes pure Kotlin
│ │ │ ├── usecase/ # Logica business
│ │ │ └── repository/ # Interfacce repository
│ │ └── presentation/ # ViewModels (Compose o altri)
│ │
│ ├── androidMain/kotlin/
│ │ └── actual/ # Implementazioni Android-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ ├── iosMain/kotlin/
│ │ └── actual/ # Implementazioni iOS-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ └── desktopMain/kotlin/ # (opzionale, per desktop JVM)
│
androidApp/ # App Android con UI nativa
iosApp/ # App iOS con UI nativa (Swift/SwiftUI)
desktopApp/ # App desktop (opzionale)
composeApp/ # (alternativa: UI condivisa con Compose MP)
Zasada przewodnia: udostępniaj jak najwięcej, w razie potrzeby korzystaj z natywnych interfejsów API. Zazwyczaj dojrzała aplikacja KMP udostępnia:
- 90-95% logiki biznesowej (warstwa domenowa)
- 80-85% warstwy danych (sieć, trwałość, buforowanie)
- 40-80% warstwy prezentacyjnej (w zależności od tego, czy używany jest Compose Multiplatform)
- 0–20% warstwy interfejsu użytkownika (w przypadku korzystania z natywnego interfejsu użytkownika specyficznego dla platformy)
KMP vs Flutter vs React Native: porównanie z 2026 r
Pytanie „którego frameworku wieloplatformowego użyć?” ma inne odpowiedzi w 2026 r. niż w 2022 r. Oto uczciwe porównanie:
// Matrice decisionale semplificata
| KMP | Flutter | React Native
--------------------|--------------|-------------|-------------
Linguaggio | Kotlin | Dart | TypeScript/JS
UI Engine | Nativa o CMP | Custom (Skia)| Nativa (bridge)
Performance | Ottima | Buona | Buona
Look nativo | Perfetto | Non nativo | Parziale
Team Android-first | Eccellente | Buono | Buono
Condivisione codice | ~70-80% | ~95% | ~80-90%
Ecosistema librerie | Crescente | Maturo | Maturo
Enterprise adoption | Alta (2026) | Alta | Diminuzione
Kluczowa różnica: Flutter używa do rysowania niestandardowego silnika renderującego (Impeller). cały interfejs użytkownika, zapewniając wieloplatformową spójność wizualną, ale kosztem „natywnego” wyglądu platforma. KMP z natywnym interfejsem użytkownika wygląda dokładnie tak, jak aplikacja natywna, ponieważ USA komponenty natywny dla platformy.
Kiedy wybrać KMP
KMP jest optymalnym wyborem, gdy:
- Zespół ma dużą wiedzę na temat Androida/Kotlina i chce przenieść tę logikę na iOS
- „Natywny” aspekt interfejsu użytkownika jest wymaganiem niepodlegającym negocjacjom (aplikacje bankowe, przedsiębiorstwa)
- Chcesz dzielić się logiką biznesową, zachowując jednocześnie całkowitą kontrolę nad interfejsem użytkownika specyficznym dla platformy
- Aplikacja ma złożoną logikę biznesową (najlepiej odizolować od problemów z interfejsem użytkownika)
- Dodajesz system iOS do istniejącej aplikacji na Androida bez przepisywania wszystkiego
Flutter lub React Native mogą być lepsze, gdy:
- Zespół ma umiejętności internetowe/React i chce je ponownie wykorzystać
- Chcesz zmaksymalizować udostępnianie interfejsu użytkownika (nie tylko logiki)
- Czas wprowadzenia produktu na rynek jest krytyczny, a zespół nie zna Kotlina
Swift Export: interoperacyjność iOS w 2026 r
Przed Swift Export współdzielony kod Kotlina był udostępniany iOS poprzez nagłówki Automatycznie wygenerowany Objective-C. Rezultatem było takie API:
// PRIMA (Objective-C headers generati da KMP):
// Swift deve usare classi con nomi generati automaticamente
let viewModel = SharedUserViewModel()
let users = viewModel.users as! [SharedUser]
viewModel.loadUsers(completionHandler: { users, error in
// Gestione callback non-idiomatica
})
// DOPO (Swift Export in KMP 1.9+):
// Swift idiomatico, direttamente da codice Kotlin
let viewModel = UserViewModel()
let users: [User] = viewModel.users
await viewModel.loadUsers() // async/await nativo Swift
Swift Export automatycznie tłumaczy współprogramy Kotlina na async/await Szybki,
klasy danych w strukturze Swift (z automatycznym równaniem), klasy zapieczętowane w wyliczeniach Swift,
i przepływa w AsyncSequence. W rezultacie programiści iOS korzystają z interfejsu API Kotlin
jakby był napisany w języku Swift.
Twórz na wielu platformach: bieżący stan
Compose Multiplatform (CMP) umożliwia udostępnianie całego interfejsu użytkownika napisanego w Compose Kotlin na Androidzie, iOS, Desktop JVM i Internecie (przez Kotlin/Wasm). W 2026 roku założono na iOS i znacznie ulepszone w porównaniu do początkowych wersji beta:
// commonMain: UI condivisa con Compose Multiplatform
@Composable
fun UserListScreen(
users: List<User>,
onUserClick: (User) -> Unit
) {
LazyColumn {
items(users) { user ->
UserCard(user = user, onClick = { onUserClick(user) })
}
}
}
@Composable
fun UserCard(user: User, onClick: () -> Unit) {
Card(
modifier = Modifier
.fillMaxWidth()
.padding(horizontal = 16.dp, vertical = 8.dp)
.clickable(onClick = onClick)
) {
Column(modifier = Modifier.padding(16.dp)) {
Text(user.name, style = MaterialTheme.typography.titleMedium)
Text(user.email, style = MaterialTheme.typography.bodySmall)
}
}
}
Interfejs tworzenia wiadomości jest identyczny na urządzeniach z Androidem i iOS. Renderowanie wykorzystuje Skiko (wiązanie Skia Kotlin) na iOS zamiast natywnych komponentów UIKit, co oznacza, że aplikacja ma spójny wygląd wieloplatformowa, ale nie identyczna z natywną aplikacją SwiftUI.
Ekosystem Biblioteczny KMP w 2026 roku
Ekosystem dojrzałych bibliotek jest niezbędny dla produktywności. W 2026 r. są to podstawowe biblioteki dla projektu KMP:
// build.gradle.kts (shared module)
kotlin {
sourceSets {
commonMain.dependencies {
// Network: client HTTP multiplatform
implementation("io.ktor:ktor-client-core:2.3.10")
implementation("io.ktor:ktor-client-content-negotiation:2.3.10")
implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.10")
// Database: SQL multiplatform
implementation("app.cash.sqldelight:runtime:2.0.2")
// Serialization
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")
// Coroutines multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.1")
// Dependency Injection
implementation("io.insert-koin:koin-core:3.5.6")
// DateTime multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.6.0")
// Logging multiplatform
implementation("co.touchlab:kermit:2.0.3")
}
androidMain.dependencies {
implementation("io.ktor:ktor-client-okhttp:2.3.10")
implementation("app.cash.sqldelight:android-driver:2.0.2")
}
iosMain.dependencies {
implementation("io.ktor:ktor-client-darwin:2.3.10")
implementation("app.cash.sqldelight:native-driver:2.0.2")
}
}
}
Kompletny przykład: Repozytorium wzorców w KMP
Zobaczmy jak zaimplementować proste repozytorium do zarządzania użytkownikami w KMP, pokazujący separację między kodem wspólnym i specyficznym dla platformy:
// commonMain: Interfaccia repository e modello
data class User(
val id: Long,
val name: String,
val email: String,
val createdAt: Instant
)
interface UserRepository {
suspend fun getUsers(): List<User>
suspend fun getUserById(id: Long): User?
suspend fun saveUser(user: User): User
}
// commonMain: Implementazione con Ktor + SQLDelight
class UserRepositoryImpl(
private val httpClient: HttpClient,
private val database: AppDatabase
) : UserRepository {
override suspend fun getUsers(): List<User> {
return try {
// Prima controlla il database locale
val cached = database.userQueries.selectAll().executeAsList()
if (cached.isNotEmpty()) {
cached.map { it.toDomain() }
} else {
// Poi scarica dalla rete e salva
val remote = httpClient.get("$BASE_URL/users").body<List<UserDto>>()
remote.forEach { database.userQueries.insert(it.toEntity()) }
remote.map { it.toDomain() }
}
} catch (e: Exception) {
// Fallback al cache anche se la rete fallisce
database.userQueries.selectAll().executeAsList().map { it.toDomain() }
}
}
}
Statystyki przyjęcia przedsiębiorstw (2026)
Według danych ekosystemu Kotlin zaktualizowanych do I kwartału 2026 r.:
- Wdrożenie KMP w firmach z listy Fortune 500: 18% (w 2023 r. było to 7%), z większość w branży fintech, e-commerce i aplikacji dla przedsiębiorstw B2B.
- Główne przypadki użycia: dzielenie logiki biznesowej pomiędzy Androidem i iOS (82%), Synchronizacja backendu JVM/Android (45%), aplikacje komputerowe (12%).
- Znane firmy: Aplikacja gotówkowa (blok), VMware, Philips, Touchlab i wiele MŚP Europejskie firmy technologiczne wykorzystują KMP w produkcji.
- Czas na wycenę: zespoły zgłaszają skrócenie czasu o 30–40%. wdrożenie funkcji po pierwszych 3 miesiącach wdrożenia.
Rozważania dotyczące przyjęcia do zespołu
Przed przyjęciem KMP należy wziąć pod uwagę następujące praktyczne czynniki:
- Umiejętności zespołowe: KMP wymaga programistów znających Kotlin. Idealnie byłoby, gdyby zespół Androida wprowadził KMP na iOS, a nie odwrotnie.
- Krzywa uczenia się stopniowania: system kompilacji KMP z Kotlin Multiplatform Wtyczka Gradle wymaga stromej krzywej uczenia się. Zainwestuj czas w zrozumienie zestawy źródeł przed rozpoczęciem.
- Kompatybilność bibliotek: nie wszystkie biblioteki Java/Android są kompatybilne z Kotlinem/Native (iOS). Zawsze sprawdzaj zgodność KMP przed dodaniem zależności.
- Czas budowy: Projekty KMP mają dłuższy czas kompilacji niż aplikacje jednoplatformowa, szczególnie dla iOS (kompilacja Kotlin/Native). Dobrze skonfigurowany CI/CD z buforowaniem i niezbędny.
Wnioski i dalsze kroki
Kotlin Multiplatform w 2026 roku to dojrzała, stabilna platforma z ekosystemem bibliotek jakość przedsiębiorstwa. Nie jest to dobre rozwiązanie dla wszystkich — jeśli Twój zespół nastawiony jest na reakcję, React Native lub Expo mają większy sens — ale dla zespołów korzystających z Androida, które chcą przenieść kod na iOS, idiomatycznie, KMP stał się preferowanym wyborem profesjonalistów.
Następny artykuł pokazuje, jak to zrobić Skonfiguruj od podstaw swój pierwszy projekt KMP: struktura zestawu źródłowego, katalog wersji Gradle, pierwsze funkcje oczekiwane/rzeczywiste i integracja z Android Studio, aby zapewnić produktywny przepływ prac programistycznych.
Seria: Kotlin Multiplatform — jedna baza kodu, wszystkie platformy
- Artykuł 1 (ten): KMP w roku 2026 — Architektura, establishment i ekosystem
- Artykuł 2: Skonfiguruj swój pierwszy projekt KMP — Android, iOS i komputer stacjonarny
- Artykuł 3: Architektura modułów współdzielonych — oczekiwana/rzeczywista, interfejsy i DI
- Artykuł 4: Sieć wieloplatformowa z klientem Ktor
- Artykuł 5: Trwałość wieloplatformowa z SQLDelight
- Artykuł 6: Twórz na wielu platformach — wspólny interfejs użytkownika na Androidzie i iOS
- Artykuł 7: Zarządzanie stanem KMP — ViewModel i Kotlin Flows
- Artykuł 8: Testowanie KMP — test jednostkowy, test integracyjny i test interfejsu użytkownika
- Artykuł 9: Swift Export — Idiomatyczna współpraca z iOS
- Artykuł 10: CI/CD dla projektów KMP — GitHub Actions i Fastlane
- Artykuł 11: Studium przypadku — aplikacja Fintech z KMP w produkcji







