# kmp Published articles for kmp. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Koko, KMP Starter Kit -- Part 3: Publishing: Your App in the Stores DevFeed: [Koko, KMP Starter Kit -- Part 3: Publishing: Your App in the Stores]() Original publisher: [Read original article]() Author: Mirzamehdi Karimov Published: 2026-09-14T04:48:22Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [App](), [Script](), [Development](), [configuration](), [GitHub]() Tags: [app](), [compose-multiplatform](), [configuration](), [development](), [github](), [how-to](), [kmp](), [kotlin](), [kotlin-multiplatform](), [script]() ### AI overview This tutorial explains the publishing phase of the KMP Starter Kit, covering store accounts, app identifiers, configuration checks, privacy and terms URLs, support email, and publishing both apps from GitHub without a Mac. It also describes Google Play's closed-testing requirement for individual accounts. ### Source excerpt Part 3 of 4: the third phase of the KMP contest starter kit. What to check when publishing, what the stores ask for, and how to publish both apps from GitHub without having a Mac. New here? Part 1 introduces the kit and gets your app running on your machine. Part 2 connects it to Firebase, sign in and a backend. You've finished the development part of your app, tested it, and it works. Screens done, data saved, maybe some services connected from part 2. Now comes the publishing part, and it can look complicated at first. But publishing is mostly a checklist, and the kit ships the checklist as a script: ./MobileApp/scripts/check_env.sh --phase publishing Or ask your AI coding assistant "is my app ready to publish?" and it runs this instead of guessing. It checks the things people forget: are the privacy policy and terms URLs real pages instead of placeholders? Is the contact email still support@example.com? Is your AI feature still calling providers directly with a key that would ship inside the binary? Each warning points at the fix. The rest of this post goes through the phase in order. A few steps involve waiting, so it's better to read it once first and start those early. Store accounts You need a developer account with each store. Google Play: $25, once. Apple: $99 per year. Start both today. Apple or Google can take days to verify a new account. Google Play has a testing rule: if you register as an individual (not a company), you can't publish to production until your app has run a closed test with at least 12 testers for 14 days, and then you apply for production access. Company accounts skip this, but need a registered business with a D-U-N-S number. For most first apps: register as an individual, collect 12 friends' emails now, and use those two weeks as your beta. App id and configuration Two things become permanent in this phase. The app id. Google Play ties your package name to the app on the first upload, and Apple ties the bundle id to the store record. ## Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide DevFeed: [Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide]() Original publisher: [Read original article]() Author: Gabriel Bronzatti Moro Published: 2026-09-07T12:01:03Z Content type: tutorial Language: en Sources: [Koin developers - Medium]() Topics: [Kotlin Multiplatform](), [compose-multiplatform](), [Kotlin](), [Android](), [iOS](), [ui]() Tags: [android](), [compose-multiplatform](), [dependencies](), [guide](), [implementation](), [ios](), [kmp](), [koin](), [kotlin](), [kotlin-multiplatform](), [mobile-app-development](), [module](), [viewmodel]() ### AI overview A step-by-step tutorial for setting up Koin in a Kotlin Multiplatform project targeting Android and iOS. It covers dependencies, data, domain, and UI modules, a platform bridge, platform entry points, and dependency injection in Composables. ### Source excerpt Hi everyone! 👋 In this article, we'll take a practical, step-by-step approach to setting up Koin in a real-world Kotlin Multiplatform (KMP) project. Instead of starting with an isolated example or a simple Hello World, we'll work with a project created by the CodandoTV community: the World Cup Best Team Simulator. The app allows users to browse football players by country and build their own dream team. It runs on both Android and iOS, using Kotlin Multiplatform for sharing business and data logic, and Compose Multiplatform to share the UI across platforms. Step 1: Add Koin Dependencies Add the Koin libraries to your version catalog: # gradle/libs.versions.toml [versions] koin = "4.2.2" [libraries] koin_core = { group = "io.insert-koin", name = "koin-core", version.ref = "koin" } koin_android = { group = "io.insert-koin", name = "koin-android", version.ref = "koin" } koin_compose = { module = "io.insert-koin:koin-compose", version.ref = "koin" } koin_compose_viewmodel = { module = "io.insert-koin:koin-compose-viewmodel", version.ref = "koin" } In the shared module shared/build.gradle.kts, split the dependencies by source set -- commonMain gets the shared Koin libraries, androidMain gets the Android-specific one: // shared/build.gradle.kts sourceSets { commonMain.dependencies { implementation(libs.koin.core) implementation(libs.koin.compose) implementation(libs.koin.compose.viewmodel) } androidMain.dependencies { implementation(libs.koin.android) } } In the Android app module androidApp/build.gradle.kts , add the Android Koin dependency: // androidApp/build.gradle.kts dependencies { implementation(libs.koin.android) implementation(libs.koin.core) }Step 2: Create the Data Module Create shared/src/commonMain/.../data/DataModule.kt . This module provides singleton instances -- repositories, and data sources that live for the entire app lifecycle. val dataModule = module { single { WorldCupRepositoryImpl(ioDispatcher = Dispatchers.IO) } }Step 3: Create ## Consuming SKIE Flows in SwiftUI - Gustavo Fão Valvassori DevFeed: [Consuming SKIE Flows in SwiftUI - Gustavo Fão Valvassori]() Original publisher: [Read original article]() Published: 2026-08-29T00:00:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [SwiftUI](), [Kotlin](), [Swift](), [Extension]() Tags: [boilerplate](), [community](), [extensions](), [interop](), [kmp](), [kotlin](), [kotlin-multiplatform](), [libraries](), [open-source](), [skie](), [swiftui]() ### AI overview This tutorial explains how to consume Kotlin Flows in SwiftUI using SKIE. It covers enabling SKIE extensions in Gradle and collecting StateFlow values through an async collect approach, a modifier, or a view wrapper to reduce repetitive UI-layer code. ### Source excerpt SKIE already makes the interop between Kotlin and Swift smooth, but SwiftUI adds a layer of complexity. We've included a series of extensions in SKIE to enable easy KMP usage from SwiftUI ## Why We Wrote a New JWT Library for Kotlin Multiplatform DevFeed: [Why We Wrote a New JWT Library for Kotlin Multiplatform]() Original publisher: [Read original article]() Published: 2026-08-07T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [JSON Web Tokens](), [Kotlin Multiplatform](), [Cryptography](), [Authentication](), [Authorization](), [Open Source](), [Library]() Tags: [authentication](), [authorization](), [community](), [cryptography](), [jwt](), [kmp](), [kotlin](), [kotlin-multiplatform](), [libraries](), [library](), [open-source]() ### AI overview The author explains how a security-focused Kotlin Multiplatform banking project led to research into cryptography and JWTs. After finding that JJWT was limited for cross-platform projects, they began developing a new JWT library as a personal open-source learning project. ### Source excerpt Earlier this year, we silently started working on and published a new KMP library. The reason it exists serves as a good lesson on how to start contributing to the open-source community. ## Bring your KMP library to NuGet DevFeed: [Bring your KMP library to NuGet]() Original publisher: [Read original article]() Author: Isuru Rajapakse Published: 2026-07-19T13:17:14Z Content type: tutorial Language: en Sources: [Stories by Isuru Rajapakse on Medium]() Topics: [Kotlin Multiplatform](), [NuGet](), [Kotlin](), [C#](), [.NET](), [Gradle](), [multiplatform](), [Library](), [API]() Tags: [android](), [android-app-development](), [androiddev](), [c-sharp](), [gradle](), [interfaces](), [kmp](), [kotlin](), [kotlin-multiplatform](), [library](), [multiplatform](), [net](), [nuget](), [nuget-package]() ### AI overview The article introduces kotlin-native-nuget, a Gradle plugin that packages Kotlin/Native libraries as NuGet packages with generated idiomatic C# bindings. It explains the motivation, configuration, publishing workflow, and supported mappings for Kotlin features such as classes, enums, data classes, coroutines, generics, interfaces, and exceptions. ### Source excerpt with kotlin-native-nuget plugin, you can bring your Kotlin to C# idiomaticallyhttps://medium.com/media/0f185efc67390bbf440bfc33f5675f42/href A little while ago, I gave a talk where I tried to take a library written in Kotlin and hand it to a .NET developer as a NuGet package. By hand. It is 30 minutes of me walking into every brick wall you can imagine - the C ABI, marshalling strings, keeping objects alive across the boundary, making any of it look like C# a human would actually want to use. Introducing kotlin-native-nuget 🪟kotlin-native-nuget plugin auto-binds your kotlin api into C# I turned all of that into a plugin, so you don't have to hit a single one of those walls. You write Kotlin, and out the other side comes a NuGet package with a proper, idiomatic C# API: classes, enums, data classes, coroutines, Flow, generics, interfaces, the works. No FFI boilerplate, no hand-written [DllImport], no "here's a C header, good luck". Your friends over in .NET just `dotnet add package` it and use it like it was C# all along. It's called kotlin-native-nuget, and it's a Gradle plugin. Here's the pitch: GitHub - xxfast/kotlin-native-nuget: A plugin that packages a Kotlin/Native library as a NuGet package with generated C# bindings, and consumes C# NuGet packages from Kotlin The pitch 🛗plugins { kotlin("multiplatform") id("io.github.xxfast.kotlin.native.nuget") version "" } kotlin { mingwX64 { binaries { sharedLib { baseName = "mycatlib" } } } macosArm64 { binaries { sharedLib { baseName = "mycatlib" } } } } nuget { publish { packageId = "MyCatLib" version = "1.0.0" authors = "yourname" description = "My Kotlin/Native library" rootPackage = "com.example.cats" } } That's it. Add the plugin, point it at your native targets, and run the publish task. Out pops a .nupkg. Why though? 🤔 It's a fair question. I got it a lot (even on that talk) Kotlin Multiplatform already reaches an absurd number of places: the JVM, Android, iOS, JS, Wasm, and native desktop. But there's th ## Our Droidcon US 2026 Picks - Sam Hill DevFeed: [Our Droidcon US 2026 Picks - Sam Hill]() Original publisher: [Read original article]() Published: 2026-07-14T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Mobile](), [multiplatform](), [Kotlin](), [kotlin-native](), [AI Development](), [Artificial Intelligence](), [Rust](), [Testing](), [Gradle](), [scaling]() Tags: [2026](), [ai](), [ai-development](), [android](), [droidcon](), [gradle](), [ios](), [js](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [multiplatform](), [rust]() ### AI overview Touchlab previews selected Droidcon USA 2026 talks covering AI and cross-platform mobile development, Kotlin Native project structures, KMP integration with Rust, migration decisions, and mobile testing. ### Source excerpt With Droidcon right around the corner, here are the talks we are most excited about ## Antigravity TagSpotter - Share data with Firebase DevFeed: [Antigravity TagSpotter - Share data with Firebase]() Original publisher: [Read original article]() Published: 2026-07-09T20:34:04Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [Firebase](), [Google](), [SDK](), [data](), [iOS]() Tags: [ai](), [ai-agents](), [antigravity](), [code](), [data](), [firebase](), [google](), [ios](), [kmp](), [sdk]() ### AI overview The article describes planning and implementing Firebase-based cloud storage for TagSpotter, including authentication, offline use, cross-device syncing, shared data packs, schema changes, migrations, and platform SDK constraints. It finds that defining requirements and edge cases required substantial planning before implementation. ### Source excerpt The challenge - Firebase with Google Plugins Now that I can see my graffiti spots on multiple platforms the obvious next step is I want to keep the data in the cloud so that I can capture spots when I'm out and about and then look at them and edit them on the laptop later. For this I need some kind of auth and data storage - like Firebase. Like before, can I do the implementation on a weekend. Easy enough? Well Antigravity 2.0 has firebase super powers in the form of Google shipped plugins but figuring out what I really want and what the edge cases are was not trivial. The prep grill-me grill-me grill-me For this exercise I was pretty confident antigravity could code up my solution. Just look at all these built in firebase skills. What I wasn't sure of was what I actually wanted. Let's get some ideas. I wanted users that didn't want to log in, not to be forced to do this. So there was the idea of an offline mode. Then when I do log in and I happen to change something on my phone and then on the desktop it should take the latest edit. I wanted it to update in the background but realistically only when I finish editing a spot. What happens when I delete a spot? How will it work when I import a pack? What happens when the photographer name is the same but the email differs? Can I have a way to save a pack of spots and just share a code to see it? What then, will I be able to change them? How does the db schema change? What migrations are needed? Will the old share packs work? How do I even set things up properly on firebase? What about desktop, there isn't an SDK for desktop? And so on and so on. I was clearly better at asking questions than building especially since I didn't know how to integrate the SDK on iOS. I spent about two evenings planning and changing my mind to come up with this plan It required multiple rounds of /grill-me and also asking antigravity for some suggestions on how things could work and picking the options I liked best. The plan had important s ## Antigravity TagSpotter - KotlinMultiPlatform evolve DevFeed: [Antigravity TagSpotter - KotlinMultiPlatform evolve]() Original publisher: [Read original article]() Published: 2026-06-14T19:10:33Z Content type: opinion Language: en Sources: [maiatoday]() Topics: [kotlinmultiplatform](), [multiplatform](), [Android](), [compose-multiplatform](), [Kotlin](), [iOS](), [Gradle](), [Web](), [Open Source]() Tags: [ai](), [ai-agents](), [android](), [antigravity](), [code](), [compose](), [compose-multiplatform](), [git](), [kmp](), [kotlin](), [kotlinmultiplatform](), [migration](), [tests]() ### AI overview The article documents an attempt to migrate the TagSpotter Android app toward Kotlin Multiplatform using Antigravity 2.0 and parallel agents. It describes preparation such as modularizing the codebase, adding tests, researching KMP migration, and planning support for iOS, Android, Desktop, and Web, while retaining Android-specific features such as the Wear app. ### Source excerpt The Challenge - bring on the subagents Can I make my TagSpotter Android app be multi-platform in a weekend using Antigravity 2.0 and a swarm of agents running in parallel? Can I do this even though I don't know how to use Xcode and I don't want to break my existing app. This was the question I had. TagSpotter is medium featured Android app I built two weeks ago. I use it to capture interesting and favourite spots in the city like unusual graffiti or yarn bombed sculptures. It has a fair few features including: Capture the places by camera with location Upload a photo AI lookup to find info on the internet from the photo, links, title, artist and suggested tags Export the spots in a zip file and import them again. This is how I share my favourite spots with friends. Make field notes by typing or speaking Share my favourites to Google maps for easy navigation Good category and location based filtering Wear app that can list started spots and navigate to a spot on the watch A good challenge because it isn't just a hello world app. The prep Because the clock would be ticking, I did a little bit of prep to make sure I had everything ready. Prep the codebase Clean up the app, no warnings, lint issues or unused imports Make sure the screens work in landscape, desktop mode will need this Split the app into feature based and pure kotlin modules. I know Compose multiplatform and pure kotlin modules can easily be re-used. Put some tests in place Checked everything works and make a tag in git incase Antigravity borked the project. Light research I collected a few salient links about KMP migration. A good blog post, some info on project structure and a link to the open source kmp libraries I might need. Nitty Gritty Friday evening, let's go. Make a plan I want to convert this app to a KMP app that supports iOS, Android, Desktop and Web. The other platforms do not have to support all features, e.g. the wear app. But Android still has to support this feature. I want to share as mu ## The Future of KMP's iOS Interop - Daniel Bertoldi DevFeed: [The Future of KMP's iOS Interop - Daniel Bertoldi]() Original publisher: [Read original article]() Published: 2026-06-12T00:00:00Z Content type: comparison Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Swift](), [Objective-C](), [Compiler](), [multiplatform]() Tags: [compare](), [experimental](), [interop](), [ios](), [kmp](), [kotlin](), [kotlin-multiplatform](), [native](), [objective-c](), [production](), [skie](), [swift](), [swift-export]() ### AI overview This comparison examines Kotlin Multiplatform iOS interoperability through Kotlin's experimental Swift Export and the Objective-C bridge enhanced by SKIE. It compares their generated output, capabilities, limitations, and tradeoffs. ### Source excerpt Kotlin's new Swift Export feature promises to eliminate the Objective-C middleman and generate native Swift APIs directly from your KMP code. But with SKIE already solving many of the same pain points in production today, which approach should your team bet on? We break down the capabilities, limitations, and tradeoffs of both. ## Koin Annotations Make expect/actual Obsolete in KMP DevFeed: [Koin Annotations Make expect/actual Obsolete in KMP]() Original publisher: [Read original article]() Author: Tezov Published: 2026-06-11T08:48:59Z Content type: tutorial Language: en Sources: [Koin developers - Medium]() Topics: [Kotlin Multiplatform](), [compose-multiplatform](), [Compiler](), [cross-platform](), [interfaces]() Tags: [compiler](), [compose-multiplatform](), [cross-platform](), [dependency-injection](), [development](), [interface](), [kmp](), [koin](), [kotlin](), [kotlinmultiplatformmobile]() ### AI overview A tutorial showing how Koin annotations and the Koin compiler can replace expect/actual declarations in Kotlin Multiplatform projects. It defines shared interfaces in commonMain, provides Android and iOS implementations through dependency injection, and uses Compose Multiplatform to resolve the platform-specific behavior. ### Source excerpt Source code available at the end of the article In Kotlin Multiplatform (KMP) projects, expect/actual is traditionally used to handle platform-specific implementations. In a previous story, I showed how to reduce expect/actual to only one per module using Koin DSL. Today, we can go further. With Koin annotations and the Koin compiler, you can completely bypass expect/actual. This method works seamlessly with Compose Multiplatform and lets you maintain a clean architecture while keeping platform-specific logic where it belongs. Previous Story Mastering Koin Annotations with the Koin Compiler Through Unit Tests -> link Next Story I don't know yet-> coming soon Setting the Stage Inside commonMain, Koin is initialized like this: @Module @ComponentScan( "com.tezov.store.shared.di", "com.tezov.store.shared.data", "com.tezov.store.shared.domain", "com.tezov.store.shared.presentation" ) class SharedModule @KoinApplication(modules = [SharedModule::class]) class SharedApplication val koinConfiguration = koinConfiguration { /* nothing here for the demo */ } I'm using: koinCompiler = "0.6.2" koinCompose = "4.2.1-RC1" koinComposeAnnotation = "4.2.1-RC1" The important part here is the @ComponentScan. Koin doesn't just scan commonMain. It also scans the platform modules: androidMain and iosMain. That detail is key because it lets Koin find all implementations without any manual wiring. Defining Contracts in commonMain Instead of expect, we define interfaces for domain and presentation layers. Domainpackage com.tezov.store.shared.domain interface PlatformDomainProtocol { fun description(): String }Presentationpackage com.tezov.store.shared.presentation import androidx.compose.runtime.Composable interface PlatformPresentationProtocol { @Composable fun ComposableFromPlatform() } Yes, you can even include a @Composable in an interface. This is powerful: your shared code can remain clean while delegating platform-specific behavior entirely to the DI container. When usi ## Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection DevFeed: [Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2026-05-24T17:30:00Z Content type: tutorial Language: en Sources: [FunkyMuse]() Topics: [Mobile](), [Code](), [Android](), [iOS](), [Java](), [Dagger]() Tags: [android](), [code](), [dagger](), [di](), [ios](), [jvm](), [kmp](), [kotlin](), [mobile]() ### AI overview This article describes migrating the mobile side of the Rudio Kotlin Multiplatform project from God Objects, custom thread-safe singletons, and manually managed lazy dependencies to Metro's compile-time dependency-injection graph. It explains different startup and platform-binding requirements for Android, iOS, and JVM desktop, including Android integration with Room and platform-specific Metro hooks. ### Source excerpt The Starting Point: God Object, Custom Singletons, and Lazy Maps In the previous article i talked about how the Ktor backend replaced a God Object BackendComponent with Metro's compile-time graph. The mobile side of Rudio had a remarkably similar story, except it was more interesting because there were actually two God Objects working together and someone (looks in the code, realizes it was me... ## SQLCipher and Firebase SPM symbol conflicts can disable encryption in Kotlin Multiplatform Room databases DevFeed: [SQLCipher and Firebase SPM symbol conflicts can disable encryption in Kotlin Multiplatform Room databases]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2026-05-12T13:30:00Z Content type: tutorial Language: en Sources: [FunkyMuse]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Encryption](), [Firebase](), [SQLite](), [iOS]() Tags: [cocoapods](), [encryption](), [firebase](), [ios](), [kmp](), [kotlin](), [sqlite]() ### AI overview This tutorial explains how adding Firebase iOS SDK packages through Kotlin's experimental Swift Package Manager integration caused a Kotlin Multiplatform Room database to use Apple's unencrypted sqlite3 instead of SQLCipher. It attributes the issue to identical SQLite symbols and linker precedence in statically linked frameworks. ### Source excerpt The Starting Point I know, long title... my creativity turned into lengthy title I recently needed encrypted database storage in my Kotlin Multiplatform app using AndroidX Room. After some research, i found Paris Tsiogas's excellent guide on Encrypted Room Database in KMP which walks through the full setup, Gradle dependencies, platform-specific implementations, and a custom SQLCipherNativeDriv... ## Why Decision-Makers Adopt Kotlin Multiplatform DevFeed: [Why Decision-Makers Adopt Kotlin Multiplatform]() Original publisher: [Read original article]() Published: 2026-04-29T18:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [Maintainability](), [Developer experience](), [jetbrains]() Tags: [adoption](), [business-value](), [developer](), [jetbrains](), [kmp](), [kotlin](), [kotlin-multiplatform](), [maintainability]() ### AI overview The article explains that Kotlin Multiplatform adoption depends on decision-makers seeing measurable business value, not only on developer enthusiasm. It highlights reduced duplicated work across iOS and Android, native UI and workflows, potentially less code, faster release cycles, and improved maintainability. ### Source excerpt KMP adoption is not driven by developer enthusiasm alone. It moves forward when leaders see a clear case for measurable business value. ## Using AI to Check Your KMP Readiness - Gabriel Souza DevFeed: [Using AI to Check Your KMP Readiness - Gabriel Souza]() Original publisher: [Read original article]() Published: 2026-03-20T18:00:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Android](), [Gradle](), [Artificial Intelligence](), [AI Agent]() Tags: [agents](), [ai](), [android](), [claude-code](), [gradle](), [kmp](), [kotlin-multiplatform]() ### AI overview This tutorial explains how to assess whether an Android project's dependencies are ready for Kotlin Multiplatform migration. It recommends using deterministic scripts for dependency checks, AI agents for research and code generation, and JSON schemas for validation. ### Source excerpt Before migrating an Android project to Kotlin Multiplatform, you need to answer one question: are your dependencies ready? Here's how to combine deterministic scripts with AI-powered research to check, without wasting time or money. ## Sharing ViewModels Across Android and iOS in Kotlin Multiplatform Projects DevFeed: [Sharing ViewModels Across Android and iOS in Kotlin Multiplatform Projects]() Original publisher: [Read original article]() Published: 2026-03-02T00:00:00Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [MVVM](), [multiplatform](), [Mobile](), [android-development](), [Compose]() Tags: [android](), [architecture](), [compose](), [design-patterns](), [ios](), [kmp](), [kotlin-multiplatform](), [multiplatform](), [mvvm](), [viewmodel]() ### AI overview This article explains the MVVM pattern and examines how sharing ViewModels across Android and iOS affects developer experience in Kotlin Multiplatform projects. It discusses separation of concerns, binders, Compose, SKIE, and Android ViewModel lifecycle behavior, including configuration changes. ### Source excerpt Sharing ViewModels between platforms affects the iOS developer experience. In this post we will discuss this topic and some possible solutions in KMP projects that respect the native feel of iOS and Android. ## Using Navigation 3 with Compose Multiplatform DevFeed: [Using Navigation 3 with Compose Multiplatform]() Original publisher: [Read original article]() Published: 2025-11-15T00:00:00Z Content type: tutorial Language: en Sources: [John O'Reilly]() Topics: [compose-multiplatform](), [navigation](), [Compose](), [Google](), [Kotlin](), [ui]() Tags: [adaptive](), [compose-multiplatform](), [google](), [kmp](), [kotlin](), [material3](), [multiplatform](), [navigation](), [ui]() ### AI overview A tutorial on using Navigation 3 with Compose Multiplatform in a shared Kotlin Multiplatform project. It covers dependencies, back-stack-based navigation, route mapping, and adaptive list/detail layouts using Material3 Adaptive Navigation3. ### Source excerpt Navigation 3 is a new Compose based navigation library from Google that's designed with ease of use and flexibility in mind. ## Setting up Compose Multiplatform previews DevFeed: [Setting up Compose Multiplatform previews]() Original publisher: [Read original article]() Author: Márton Braun Published: 2025-07-29T07:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [compose-multiplatform](), [Kotlin Multiplatform](), [Android Studio](), [IntelliJ IDEA](), [Tooling]() Tags: [android](), [android-studio](), [compose-multiplatform](), [how-to](), [intellij](), [intellij-idea](), [kmp](), [kotlin](), [marton-braun](), [multiplatform](), [tooling](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview A tutorial on setting up Compose Multiplatform previews for common code. It explains how to install the Kotlin Multiplatform IDE plugin, create a correctly configured project with the KMP wizard, and use previews in IntelliJ IDEA or Android Studio. An Android target is required. ### Source excerpt Compose Multiplatform now has support for previews in common code. Here's how you can get started with using them. ## Initial exploration of using Koog for developing Kotlin based AI agents DevFeed: [Initial exploration of using Koog for developing Kotlin based AI agents]() Original publisher: [Read original article]() Published: 2025-06-21T23:00:00Z Content type: tutorial Language: en Sources: [John O'Reilly]() Topics: [AI Agent](), [Kotlin](), [MCP](), [Model Context Protocol](), [Kotlin Multiplatform](), [Android Studio](), [Jetpack Compose](), [IntelliJ IDEA]() Tags: [ai-agents](), [android-studio](), [anthropic](), [compose](), [gemini](), [ide](), [kmp](), [kotlin](), [kotlin-multiplatform](), [mcp](), [mcp-server](), [ollama](), [openai](), [plugin](), [run-agent](), [tool]() ### AI overview This article explores Koog, a Kotlin-based framework for building and running AI agents. It demonstrates an agent using Google Gemini, MCP servers, climate-emissions data, and Compose UI code added to an Android Studio project, and discusses support for multiple LLM providers and custom tools. ### Source excerpt Koog, announced recently at KotlinConf, is a new Kotlin-based framework designed to build and run AI agents. This article will outline initial exploration of using Koog along with a number of configured MCP servers (specifically mcp-jetbrains which we'll use to control the IntelliJ/Android Studio IDE and also one based on the ClimateTraceKMP Kotlin Multiplatform (KMP) sample built using the Kotlin MCP SDK). ## Wrapping Android XR For KMP DevFeed: [Wrapping Android XR For KMP]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2024-12-19T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android XR](), [compose-multiplatform](), [multiplatform](), [cross-platform](), [Jetpack Compose]() Tags: [android-xr](), [compose-multiplatform](), [cross-platform](), [jetpack-compose](), [kmp]() ### AI overview A tutorial showing how to wrap Android XR functionality for Kotlin Multiplatform projects. It defines shared XR behavior, provides an Android-specific implementation, uses expect/actual declarations for platform differences, and exposes the session through Jetpack Compose CompositionLocals. ### Source excerpt Recently I've been finding myself immersed in Compose Multiplatform, a way to build cross platform mobile applications with Jetpack Compose UI. Of course, when Android announced their extended reality framework Android XR this week, I initially worried I wouldn't be able to try it out in my newest side projects. However, one of the biggest benefits of KMP is how seamless it is to provide platform specific functionality for your shared code. So let's do that with Android XR. ## Declarative Gradle EAP2 - November 2024 Update DevFeed: [Declarative Gradle EAP2 - November 2024 Update]() Original publisher: [Read original article]() Author: Paul Merlin Published: 2024-11-18T05:00:00Z Content type: release Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Android Gradle Plugin](), [configuration](), [Android Studio](), [ide](), [Kotlin Multiplatform]() Tags: [experimental](), [features](), [gradle](), [here](), [ide](), [improvements](), [kmp](), [kotlin](), [kotlin-multiplatform](), [plugin](), [preview](), [tooling](), [update]() ### AI overview This update announces Declarative Gradle EAP2, an experimental second Early Access Preview of Gradle's declarative model. It describes the Declarative Configuration Language, Software Types, improved IDE and tooling support, starter-project generation, and direct exposure of Android Gradle Plugin models through the new AGP ecosystem plugin. The release is intended for community feedback and is not ready for production use. ### Source excerpt Introduction A year ago, we announced a new experimental project called Declarative Gradle. That blog post presented our vision for a declarative model for Gradle. It also introduced our concept of a developer-centric software definition. This was followed by the first Early Access Preview release in July 2024, accompanied by the First Look at Declarative Gradle blog post. The first EAP introduced a configuration model called Software Types, a new Declarative Configuration Language (DCL), and demonstrated the potential for tooling improvements and better IDE support. It is now easier to try Declarative Gradle. The first EAP was based on separate Declarative Gradle prototype plugins. These prototype plugins implement Software Types wrapping existing plugins like Android Gradle Plugin (AGP) and Kotlin Multiplatform (KMP), making them usable from DCL. Since then, we've worked with the Android Studio team to expose their existing model of the Android Gradle Plugin as a Software Type directly in DCL to demonstrate Declarative Gradle on a real-world plugin with elaborate DSL. We also experimented with other IDEs and enhanced gradle init to generate starter projects that use DCL. With those efforts concluded, we are happy to announce the second EAP release! This blog post provides an update on the project's progress and outlines how you can provide feedback and influence our next steps. Declarative Gradle is still in an experimental stage and is not ready for production use. We are providing a second early access preview to gather more feedback from the community. We invite you to try out the samples and the demo applications and to share your feedback. Official Android Software Type Preview We worked with the Android Studio team to enable the Android Gradle Plugin (AGP) to expose its existing models, aka. Project extensions, directly as Software Types, to make them available in DCL. The new AGP ecosystem plugin now exposes androidApp and androidLibrary Software Types, whi ## Compose Multiplatform for Cross-Platform Mobile App Development DevFeed: [Compose Multiplatform for Cross-Platform Mobile App Development]() Original publisher: [Read original article]() Published: 2024-10-11T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [compose-multiplatform](), [Compose](), [cross-platform](), [Mobile](), [Kotlin Multiplatform](), [Android](), [iOS](), [Flutter](), [React Native]() Tags: [compose-mp](), [compose-multiplatform](), [cross-platform](), [flutter](), [kmp](), [kotlin](), [kotlin-multiplatform](), [mobile](), [mobile-development](), [react]() ### AI overview This article presents Compose Multiplatform as an option for building Android and iOS mobile apps from a single codebase. It explains that the technology combines Kotlin Multiplatform with Compose UI while retaining access to native platforms, and compares it with React Native and Flutter. ### Source excerpt If you are building a mobile product, you are probably considering React Native, Flutter, or some flavor of HTML. Maybe you're even considering fully native apps. If so, you should learn about Compose Multiplatform. Compose provides full cross-platform efficiency, and can be as native as you need, minus the risk. ## Piloting Kotlin Multiplatform is Easy. Scaling is Hard. - Kevin Galligan DevFeed: [Piloting Kotlin Multiplatform is Easy. Scaling is Hard. - Kevin Galligan]() Original publisher: [Read original article]() Published: 2024-08-07T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [scaling](), [Mobile](), [multiplatform](), [Development]() Tags: [development](), [kmp](), [kotlin](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [scaling](), [swift](), [xcode]() ### AI overview The article explains why scaling Kotlin Multiplatform is more difficult than initial experimentation for native mobile teams. It argues that teams need to use KMP in feature development, reconsider library publishing and repository organization, and adopt an approach tailored to native Android and iOS teams. ### Source excerpt When native mobile teams explore KMP, getting started is pretty easy. The difficulty emerges when they try to scale. To get the most out of KMP for your team, and for KMP as a platform to succeed, we need to make scaling easy as well. ## Livestream: Close the Swift/Kotlin Platform Gap - Touchlab DevFeed: [Livestream: Close the Swift/Kotlin Platform Gap - Touchlab]() Original publisher: [Read original article]() Published: 2024-07-26T00:00:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Swift](), [multiplatform](), [iOS](), [Mobile](), [Developer experience]() Tags: [coroutines](), [developer-experience](), [interop](), [ios](), [kmp](), [kotlin](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [swift](), [xcode]() ### AI overview This livestream introduces the Swift/Kotlin platform gap in Kotlin Multiplatform development. It uses a "Bad Swift Simulation" to show how Kotlin APIs can lose modern features when exported to Swift, then discusses tools, best practices, and SKIE for improving Swift interoperability and developer experience. ### Source excerpt Calling Kotlin Multiplatform from Swift can be a painful experience. Kotlin engineers new to KMP rarely understand the issues. The "Bad Swift Simulation" helps Kotlin engineers "feel the pain" by replicating the experience directly in Kotlin. With that experience, understanding how to fix the situation, and why you need to, is much simpler. ## KMP Team Adoption for Native Mobile: Workflow and Management Guidance DevFeed: [KMP Team Adoption for Native Mobile: Workflow and Management Guidance]() Original publisher: [Read original article]() Published: 2024-07-19T16:24:40Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [multiplatform](), [scaling](), [Mobile](), [Development](), [Kotlin](), [cross-platform]() Tags: [kmp](), [kotlin](), [management](), [mobile](), [native](), [scaling](), [teams](), [technology](), [workflow]() ### AI overview This article introduces the challenges teams face when adopting Kotlin Multiplatform for native mobile development. It argues that although KMP is stable and capable of sharing business logic, existing tooling and sample structures are largely designed for individual developers, making team-scale adoption difficult without new approaches and guidance. ### Source excerpt KMP for native mobile is mature technology. Best practice guidance for how teams should apply it is not. KMP has amazing potential, but presents unique workflow and management problems. Understanding these problems, and having a plan, is critical. [Next page]()