# Kotlin Multiplatform Kotlin Multiplatform is a technology for creating applications across platforms by sharing code while retaining native programming benefits. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork DevFeed: [Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork]() Original publisher: [Read original article]() Author: Sajid Ali Published: 2026-09-14T04:24:43Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [compose-multiplatform](), [tvOS](), [Kotlin Multiplatform](), [Gradle]() Tags: [apple](), [build](), [compiler](), [compose-multiplatform](), [gradle](), [gradle-plugin](), [ios](), [jetbrains](), [multiplatform](), [source]() ### AI overview This tutorial explains the build setup for adding tvOS support to a Compose Multiplatform fork. It covers Kotlin Multiplatform targets, source-set organization shared between iOS and tvOS, and the build-layer work used to identify missing modules and dependencies. ### Source excerpt Compose Multiplatform on tvOS This series: Compose Multiplatform on tvOS My Journey Making Compose Multiplatform Work on tvOS, and What I Learned Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork (this post) Rendering (coming soon) Siri Remote input (coming soon) Siri Remote trackpad (coming soon) Screen density and text input (coming soon) Porting tv-material (coming soon) The Gradle plugin and third-party libraries (coming soon) Maintaining the fork (coming soon) Building a real app on it (coming soon) Part 1 was why this fork exists. This one is the build layer, and it comes before any Compose code, because in Kotlin Multiplatform a target is not a flag you flip at the end. It decides which source sets compile, which dependencies resolve, which klibs get published, which linker flags get passed. Until the build knows about tvosArm64, nothing tells you what is missing. So the first commits were build files. Once the targets were on, the compiler listed what was missing, module by module, and I worked through that list. Source set layout on the tvos branch I started on a branch called tvos, based on upstream. Back then JetBrains called iOS "uikit" in this repository and the source set was uikitMain. Because tvOS is also UIKit underneath, it made sense to have a common source parent for both iOS and tvOS. But iOS was already being called uikit, so I chose uiKitCommonMain as the source set name and moved all the UIKit files there, keeping only the iOS specific files in uikitMain and putting the tvOS specific files in a new source set, tvosMain. The problem with this approach was how to keep up with upstream. I tried a symlink to the uikit source set, and then overriding the tvOS files in a separate target. The override worked but complicated the process. At that time my goal was to make it runnable on tvOS however possible, so we would have a proof of concept. So I did a lot of hacks in the tvos branch to make it runnable, and af ## Announcing ADK for Kotlin 1.0: Building Production-Ready AI Agents in Kotlin, Android, and Beyond DevFeed: [Announcing ADK for Kotlin 1.0: Building Production-Ready AI Agents in Kotlin, Android, and Beyond]() Original publisher: [Read original article]() Author: Guillaume Laforge Published: 2026-09-12T11:04:33.891311Z Content type: release Language: en Sources: [Google Developers Blog]() Topics: [Artificial Intelligence](), [Kotlin](), [AI Development](), [Android](), [Kotlin Multiplatform](), [multiplatform](), [Orchestration](), [Google](), [Persistence](), [Agent Skill](), [LiteRT](), [Cloud]() Tags: [agent-skill](), [agents](), [ai](), [ai-agent](), [ai-agents](), [android](), [building](), [database](), [development-kit](), [firebase](), [incident](), [kotlin](), [multiplatform](), [orchestration](), [persistence](), [production]() ### AI overview Google announces the 1.0 general availability release of the Agent Development Kit (ADK) for Kotlin, a production-ready toolkit for building multi-agent applications with Kotlin, Java, and Android. Built on Kotlin Multiplatform, it provides feature parity with the ADK 1.0 Core and adds Android-first extensions for on-device agents with LiteRT-LM and ML Kit, hybrid cloud workflows through Firebase AI Logic, and state persistence with Room and AppSearch. The release also includes type-safe, compile-time function calling through KSP and declarative agent skills. ### Source excerpt Google has officially released version 1.0 of the Agent Development Kit (ADK) for Kotlin, achieving full feature parity with the Python and Java ADK cores to enable idiomatic, multi-agent AI development. Built on Kotlin Multiplatform (KMP), the framework leverages Kotlin Symbol Processing (KSP) for zero-reflection, type-safe function calling, alongside advanced orchestration capabilities like human-in-the-loop workflows and context compaction. Additionally, the release introduces a robust suite of Android-first extensions, allowing mobile developers to integrate local models via LiteRT-LM, cloud reasoning through Firebase AI, session persistence using Room, and semantic memory powered by AppSearch. ## Our LDX3 New York 2026 Picks - Justin Mancinelli DevFeed: [Our LDX3 New York 2026 Picks - Justin Mancinelli]() Original publisher: [Read original article]() Published: 2026-09-08T13:00:00Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Software Engineering](), [AI Engineering](), [Mobile](), [Kotlin Multiplatform](), [decision-making]() Tags: [2026](), [ai](), [community](), [conference](), [kotlin](), [kotlin-multiplatform](), [leadership](), [mobile]() ### AI overview Touchlab's Justin Mancinelli previews the LDX3 New York 2026 talks the company is most interested in, highlighting software engineering leadership, AI's effects on engineering and management, innovation practices, and mobile development with Kotlin Multiplatform. ### Source excerpt LDX3 is back in NYC and Touchlab will be in attendence. Here are the talks we're most excited about. ## 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 ## Running golf swing analysis on an Android device with a fine-tuned Gemma 4 model DevFeed: [Running golf swing analysis on an Android device with a fine-tuned Gemma 4 model]() Original publisher: [Read original article]() Published: 2026-08-29T23:00:00Z Content type: tutorial Language: en Sources: [John O'Reilly]() Topics: [Kotlin Multiplatform](), [gemma4](), [LiteRT](), [On-device AI](), [Fine-tuning]() Tags: [ai](), [android](), [cross-platform](), [fine-tuning](), [gemma](), [gemma-4](), [kotlin](), [kotlin-multiplatform](), [litert](), [model](), [multiplatform](), [on-device-ai]() ### AI overview This article explains how FormAI adds Android on-device golf-swing analysis using a small Gemma 4 model fine-tuned to imitate Gemini for a narrow coaching task. It covers generating training data with Gemini, fine-tuning with LoRA, converting the model for LiteRT-LM, and the current fallback to cloud analysis on other platforms. ### Source excerpt FormAI is a Kotlin Multiplatform app that analyses a video of your golf swing, basketball shot or running form and gives you coaching feedback. Up to now that has always meant uploading the video to Gemini and getting the response back over the network. We've added an option to do the golf swing analysis entirely on an Android device instead, using a small Gemma 4 model that we fine-tuned to imitate Gemini for that one task. LiteRT-LM, the runtime we use for this, is itself cross platform (Android, iOS, desktop and web), but we've only wired up the Android side so far, so this path lives in androidMain and the other targets report it as unavailable and fall back to the cloud. ## Droidcon Orlando 2026 Recap - Tadeas Kriz DevFeed: [Droidcon Orlando 2026 Recap - Tadeas Kriz]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Android](), [iOS](), [Coroutines](), [Concurrency]() Tags: [2026](), [android](), [community](), [coroutines](), [demo](), [droidcon](), [experience](), [ios](), [kotlin](), [kotlin-interpreter](), [kotlin-multiplatform](), [multiplatform](), [recap](), [speaking]() ### AI overview A recap of Droidcon USA in Orlando, covering the conference venue, talks, and a demo of Kotlin Multiplatform Hot Reload. The author explains that file changes were propagated to an application running on Android and iOS, while Kotlin Interpreter work continues. ### Source excerpt Droidcon USA moved to Orlando this year. Tadeas recaps his experience attending and speaking at the new venue. ## Keep Kotlin Multiplatform bindings at the platform boundary DevFeed: [Keep Kotlin Multiplatform bindings at the platform boundary]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [Koin - Cloud-Inject.io -Kotzilla]() Topics: [Kotlin Multiplatform](), [Kotlin](), [implementation](), [modules](), [configuration](), [test]() Tags: [configuration](), [implementation](), [kotlin](), [kotlin-multiplatform](), [module](), [multiplatform](), [test](), [verification]() ### AI overview A guide to keeping Kotlin Multiplatform dependency bindings at platform boundaries. It recommends defining small capability interfaces in common code, implementing them in platform source sets, organizing modules around capabilities and product features, and testing both shared contracts and real platform bindings. ### Source excerpt Kotlin Multiplatform makes source-set boundaries visible, but a dependency container can blur them again. A shared module should state a capability such as secure storage, HTTP transport, or local time. The platform source set should supply the implementation. Put contracts where consumers can see them Define the smallest useful interface in common code. Avoid copying a platform API into that interface. A storage contract might expose read, write, and remove; it does not need to expose Android preferences or an Apple keychain type. ## 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. ## Practical Kotlin Multiplatform: Implementing the Firebase Sign-up Operation with Ktor DevFeed: [Practical Kotlin Multiplatform: Implementing the Firebase Sign-up Operation with Ktor]() Original publisher: [Read original article]() Author: hitherejoe Published: 2026-07-26T07:37:53Z Content type: tutorial Language: en Sources: [Joe Birch]() Topics: [Kotlin Multiplatform](), [Firebase](), [Ktor](), [Authentication](), [Android](), [interfaces](), [iOS](), [Exception]() Tags: [android](), [authentication](), [code](), [exception](), [firebase](), [interfaces](), [ios](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [ktor](), [multiplatform]() ### AI overview A tutorial on implementing a Firebase sign-up API request in a Kotlin Multiplatform application using Ktor. It defines an authentication repository interface and service implementation for Android and iOS clients, including API key, email, and password parameters and exception handling. ### Source excerpt This post is part four of a series adapted from Practical KMP, my book on building production Kotlin Multiplatform apps for Android and iOS. Part two built the authentication remote store and modelled its response. Implementing the Sign-up Endpoint Now that we've created the models for receiving back an authentication response, it's time for us... Continue reading -> ## 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 ## Practical Kotlin Multiplatform: Creating the Firebase Auth Remote Store with Ktor DevFeed: [Practical Kotlin Multiplatform: Creating the Firebase Auth Remote Store with Ktor]() Original publisher: [Read original article]() Author: hitherejoe Published: 2026-07-18T15:17:19Z Content type: tutorial Language: en Sources: [Joe Birch]() Topics: [Kotlin Multiplatform](), [Authentication](), [Firebase](), [Ktor](), [Android](), [HTTP](), [iOS]() Tags: [android](), [api](), [authentication](), [firebase](), [ios](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [ktor](), [networking](), [tests]() ### AI overview This tutorial, part two of a Kotlin Multiplatform series, explains how to build a Firebase Authentication remote store with Ktor. It models Firebase Authentication's REST API behind a shared interface for Android and iOS, covering account operations, token refresh, dependency injection, and tests with a mocked client. ### Source excerpt This post is part two of a series adapted from Practical KMP, my book on building production Kotlin Multiplatform apps for Android and iOS. If you missed it, part one covered setting up the shared networking module. Introduction With our shared module now set up, we have the foundations that we need to start building... Continue reading -> ## A Local-to-Backend Workflow for Iterating on AI Features in Kotlin Multiplatform Apps DevFeed: [A Local-to-Backend Workflow for Iterating on AI Features in Kotlin Multiplatform Apps]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2026-07-17T11:49:09Z Content type: tutorial Language: en Sources: [YAZIO Engineering - Medium]() Topics: [Artificial Intelligence](), [Kotlin Multiplatform](), [LLMs](), [Kotlin](), [Mobile]() Tags: [ai](), [kotlin](), [kotlin-multiplatform](), [llm](), [llms](), [mobile](), [mobile-app-development]() ### AI overview The article presents a workflow for building AI features in a Kotlin Multiplatform mobile app: define an app interface, implement and iterate on the prompt locally with Koog, then move the completed logic to a backend. It uses a voice-based nutrition-tracking example that converts natural-language input into typed proposed actions. ### Source excerpt TLDR: Define the interface in the app, iterate locally with Koog, move the logic to the backend when it's done. AI features have a weird reputation among mobile developers. The model sits behind an API, the prompt lives on a server someone else owns, and every change means a ticket, a review, a deploy. So the whole topic feels like backend territory. But an AI feature is just a feature. Text in, structured data out, some logic in between. The only unusual part: the core of that logic is a prompt. And prompts are not designed, they are iterated. You try an input, look at the output, adjust, try again. Dozens of times. So the real problem is not building the feature. It's making that loop fast. The pattern I would like to show: define an interface in the app, build the real UI against it, implement it locally with Koog, iterate until the output is solid, then move the implementation to the backend. In Kotlin that last step is mostly copy paste. The example: track everything in one sentence We build Yazio, a nutrition tracking app, as Kotlin Multiplatform: one shared codebase for iOS and Android. That matters here, because everything below is written once and runs on both platforms. Tracking today is many small interactions: search a food, pick a portion, add water, log a workout. Now imagine the user just says what happened: "I had two scrambled eggs and a coffee for breakfast, drank half a liter of water, went for a 30 minute run, and for lunch I ate the same as yesterday."Users can track using voice The app answers with a list of proposed actions. The user deletes the wrong ones, speaks again to add what's missing, and confirms everything at once. Speech to text is solved on both platforms, so from our side the input is just a string. Messy natural language in, exact typed data out. That's what LLMs are good at. It's also the kind of logic you won't get right on the first try. The constraint: the key can't live in the app You can't ship an OpenAI or Anthropic API ke ## Building AI Features in Kotlin Multiplatform Apps with Local Prompt Iteration DevFeed: [Building AI Features in Kotlin Multiplatform Apps with Local Prompt Iteration]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2026-07-17T11:49:08Z Content type: tutorial Language: en Sources: [Stories by Paul Woitaschek on Medium]() Topics: [Kotlin Multiplatform](), [LLMs](), [Mobile](), [API](), [Back end](), [voice ai](), [anthropic](), [OpenAI]() Tags: [ai](), [anthropic](), [api](), [backend](), [kotlin](), [kotlin-multiplatform](), [llm](), [llms](), [mobile](), [mobile-app-development](), [openai](), [speech](), [voice]() ### AI overview This tutorial presents a workflow for building AI features in Kotlin Multiplatform mobile apps. It recommends defining the app interface first, implementing the feature locally with Koog to iterate quickly on prompts, and moving the implementation to a backend once the output is reliable. The example uses natural-language and voice-based nutrition tracking, with LLM output converted into proposed structured actions. ### Source excerpt TLDR: Define the interface in the app, iterate locally with Koog, move the logic to the backend when it's done. AI features have a weird reputation among mobile developers. The model sits behind an API, the prompt lives on a server someone else owns, and every change means a ticket, a review, a deploy. So the whole topic feels like backend territory. But an AI feature is just a feature. Text in, structured data out, some logic in between. The only unusual part: the core of that logic is a prompt. And prompts are not designed, they are iterated. You try an input, look at the output, adjust, try again. Dozens of times. So the real problem is not building the feature. It's making that loop fast. The pattern I would like to show: define an interface in the app, build the real UI against it, implement it locally with Koog, iterate until the output is solid, then move the implementation to the backend. In Kotlin that last step is mostly copy paste. The example: track everything in one sentence We build Yazio, a nutrition tracking app, as Kotlin Multiplatform: one shared codebase for iOS and Android. That matters here, because everything below is written once and runs on both platforms. Tracking today is many small interactions: search a food, pick a portion, add water, log a workout. Now imagine the user just says what happened: "I had two scrambled eggs and a coffee for breakfast, drank half a liter of water, went for a 30 minute run, and for lunch I ate the same as yesterday."Users can track using voice The app answers with a list of proposed actions. The user deletes the wrong ones, speaks again to add what's missing, and confirms everything at once. Speech to text is solved on both platforms, so from our side the input is just a string. Messy natural language in, exact typed data out. That's what LLMs are good at. It's also the kind of logic you won't get right on the first try. The constraint: the key can't live in the app You can't ship an OpenAI or Anthropic API ke ## Practical Kotlin Multiplatform: Setting up the Kotlin Multiplatform Networking Module with Ktor DevFeed: [Practical Kotlin Multiplatform: Setting up the Kotlin Multiplatform Networking Module with Ktor]() Original publisher: [Read original article]() Author: hitherejoe Published: 2026-07-10T16:16:31Z Content type: tutorial Language: en Sources: [Joe Birch]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Ktor](), [networking](), [REST API](), [Authentication](), [Firebase](), [Gradle](), [implementation](), [Android](), [iOS]() Tags: [android](), [android-app-development](), [android-development](), [androiddev](), [app-development](), [authentication](), [firebase](), [gradle](), [implementation](), [ios](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [ktor](), [library](), [mobile-app-development](), [module](), [networking](), [rest-api]() ### AI overview A tutorial series installment that sets up a Kotlin Multiplatform networking module with Ktor for shared Android and iOS code. It describes building a portable Firebase Authentication and Firestore REST API layer without relying on platform-specific SDKs. ### Source excerpt This post is part one of a series adapted from Practical KMP, my book on building production Kotlin Multiplatform apps for Android and iOS. Part 1: Creating the Kotlin Multiplatform Module In this part of the book, we'll build the complete authentication remote store, defining a repository that handles every operation our app needs for... Continue reading -> ## Introducing the Composables CLI and MCP server DevFeed: [Introducing the Composables CLI and MCP server]() Original publisher: [Read original article]() Author: Alex Styl Published: 2026-07-07T00:00:00Z Content type: release Language: en Sources: [Composables - Concise, no-fluff video tutorials for Android developers]() Topics: [Command-line interface](), [MCP](), [MCP Server](), [compose-multiplatform](), [Kotlin Multiplatform](), [Documentation]() Tags: [cli](), [compose-multiplatform](), [documentation](), [kotlin-multiplatform](), [mcp](), [mcp-server](), [npm]() ### AI overview The Composables CLI is a command-line tool for creating native apps and modules with Composables UI preconfigured. It provides an interactive setup wizard, supports Kotlin Multiplatform project structure, can search live Composables UI documentation from the terminal, and can run an MCP server to help coding agents access component guidance and examples. ### Source excerpt Start native apps with Composables UI without setting up every platform by hand. ## 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 ## Kotlin Multiplatform in Production: Two Real-World Use Cases from Booking.com DevFeed: [Kotlin Multiplatform in Production: Two Real-World Use Cases from Booking.com]() Original publisher: [Read original article]() Author: Diego Gómez Olvera Published: 2026-06-05T15:09:18Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [Kotlin Multiplatform](), [compose-multiplatform](), [experiments](), [A/B Testing](), [Android](), [iOS](), [Design system](), [Mobile](), [Development]() Tags: [a-b-testing](), [android](), [booking](), [bookingcom](), [compose](), [compose-multiplatform](), [concepts](), [consistency](), [data](), [development](), [engineering](), [experiment](), [experimentation](), [experiments](), [ios](), [java](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [objective-c]() ### AI overview This article describes two Booking.com engineering use cases for Kotlin Multiplatform and Compose Multiplatform: a shared experimentation library for consistent experiment assignments across Android and iOS, and hosting an Android design system in a web browser. ### Source excerpt Introduction For the majority of Booking.com travelers, mobile is the primary channel for researching, planning, and booking trips. Recent data shows that over 80% of travelers rely on a mobile app during the research phase, with more than half of all bookings occurring on mobile devices. Consequently, the Android and iOS platforms are critical to the company's product strategy; engineering choices made here have significant repercussions for the entire organisation. To maintain agility at this scale, two elements must function in unison: Strict decision validation: At any time, Booking.com manages over 1,000 simultaneous experiments across its product suite, with hundreds active on mobile. Every minor adjustment undergoes A/B testing via our proprietary experimentation library before reaching the user. A unified design system ensures product consistency and makes design goals transparent to all contributors, not just maintenance engineers. This article examines two specific engineering challenges solved using Kotlin Multiplatform (KMP) and Compose Multiplatform (CMP): Developing a shared experimentation library to ensure uniform experiment assignments across Android and iOS. Using Compose Multiplatform to host our Android design system in a web browser, bridging the gap between design concepts and implementation. While both cases use the same underlying technology, each provides unique insights into multiplatform development. Use case 1: shared experimentation library on Android and iOSThe problem with two implementations Historically, our internal experimentation library, responsible for managing experiment assignments, evaluations, and tracking on mobile, was maintained as two distinct codebases: a mix of Java and Kotlin for Android and Objective-C for iOS. While intended to be identical, managing two languages with fluctuating team resources inevitably led to logic drift. Discrepancies in event-tracking and experiment-fetching behaviours emerged, though they wer ## Koin Compiler 1.0: DSL and Annotations, Koin now Compile-Safe DevFeed: [Koin Compiler 1.0: DSL and Annotations, Koin now Compile-Safe]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-06-03T12:01:01Z Content type: release Language: en Sources: [Koin developers - Medium]() Topics: [Compiler](), [Kotlin](), [Kotlin Multiplatform](), [Gradle]() Tags: [android](), [build](), [compiler](), [dependency](), [dependency-injection](), [gradle](), [koin](), [kotlin](), [kotlin-compiler](), [kotlin-multiplatform](), [plugin]() ### AI overview Koin Compiler 1.0 introduces a native Kotlin compiler plugin that verifies Koin dependency graphs at build time. The release supports both DSL and annotation-based wiring, requires no KSP or generated files, and supports Kotlin Multiplatform. ### Source excerpt Koin Compiler 1.0: DSL and Annotations, Now Compile-Safe Hello, dear Koin Community 👋 Koin Compiler 1.0 is out. Koin's DSL and annotations now sit on a native Kotlin compiler plugin that verifies your dependency graph at build time: the missing-definition error that used to wait for a get() call no longer makes it past gradlew build: e: [Koin] Missing dependency: UserRepository (required by UserService) No KSP, no generated files, full Kotlin Multiplatform support out of the box. It's the biggest ergonomic shift we've made in Koin's nine-year history. Koin Logo with KotlinConf '26 LogoSetup 👀 If you use a Gradle version catalog (the modern default): [versions] koin = "4.2.1" koin-plugin = "1.0.0" [libraries] koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" } koin-annotations = { module = "io.insert-koin:koin-annotations", version.ref = "koin" } [plugins] koin-compiler = { id = "io.insert-koin.compiler.plugin", version.ref = "koin-plugin" } Or the equivalent inline in build.gradle.kts: plugins { id("io.insert-koin.compiler.plugin") version "1.0.0" } dependencies { implementation("io.insert-koin:koin-core:4.2.1") implementation("io.insert-koin:koin-annotations:4.2.1") } koin-annotations is only needed if you use the annotations on your classes for the constructor, or use the annotations flow. On the DSL flow, the plugin works against koin-core alone. The DSL flow -- Safer DSL ✨ Take two classes: class MyDatabase() class MyRepository(val db: MyDatabase) Wiring them up with Koin has progressively required less typing: // 1. Manual -- the wiring is explicit module { single { MyDatabase() } single { MyRepository(get()) } } // 2. Reflection-free constructor binding module { singleOf(::MyDatabase) singleOf(::MyRepository) } // 3. Compiler-intercepted - same DSL, new mechanism module { single() single() } The third form looks like nothing is happening. That's the point: the compiler plugin sees single(), walks the ## 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. ## From Vibe-Coding to Reality: Building MarvinSync DevFeed: [From Vibe-Coding to Reality: Building MarvinSync]() Original publisher: [Read original article]() Author: Thomas Künneth Published: 2026-04-03T13:17:03Z Content type: opinion Language: en Sources: [Thomas Künneth]() Topics: [Vibe coding](), [Artificial Intelligence](), [cursor](), [macOS](), [Swift](), [SwiftUI](), [Filesystems](), [Kotlin Multiplatform](), [Android](), [Wireless Debugging]() Tags: [adb](), [ai](), [android](), [coding](), [community](), [cursor](), [development](), [engineering](), [files](), [inclusive](), [kotlin-multiplatform](), [macos](), [software](), [swift](), [swiftui](), [vibe-coding]() ### AI overview A post-mortem on building MarvinSync, a macOS utility that synchronizes local music libraries with Android devices through ADB. The author describes using Cursor for AI-assisted Swift development, choosing SwiftUI for a native Mac experience, and replacing unreliable metadata scanning with a folder-based library structure. ### Source excerpt If you saw my posts back in February on LinkedIn and Mastodon, you know I've been deep in a Cursor session. I promised to pull back the curtain on how MarvinSync--my new macOS utility for syncing local music to Android--came to life through the lens of AI-assisted development. Before we get to the binaries (which are coming soon, I promise!), I want to share the vibe-coding post-mortem of how the first version actually took shape. If you want to follow along with the code as I describe it, the full project is already live on Codeberg. What is MarvinSync? (And why Vibe-Code it?) MarvinSync is a utility designed for a specific niche: people who still believe in local media ownership. It bridges the gap between a curated macOS music library and an Android device. No streaming, no cloud--just your folders, your metadata, and a clean sync via ADB (Android Debug Bridge). But there's a meta-story here. As an Android GDE, I spend my life deep in Kotlin, Compose, and Kotlin Multiplatform. Naturally, KMP would have been the logical choice for a cross-platform sync tool. However, I wanted to take this opportunity to go fully native on the Mac side using Swift and SwiftUI. I'll be the first to admit: I am no Swift expert. This is where vibe-coding comes in. I used Cursor to bridge the gap between my architectural knowledge and my lack of Swift syntax fluency. I provided the vibe--the logic, the structure, and the constraints--and the AI handled the boilerplate and the nuances of a language I'm still learning. Trusting the folder, not the tag One of the first big hurdles was handling music metadata. Initially, we tried the traditional route of scanning ID3 tags using standard APIs. The result was a mess of duplicates and wrong titles that didn't match how my files were actually organized. The solution was to stop being smart with metadata and start being literal with the file system. We shifted to a strict folder-based hierarchy where the directory structure itself defines the librar ## Build Your Own Landscapist Image Plugin in Jetpack Compose DevFeed: [Build Your Own Landscapist Image Plugin in Jetpack Compose]() Original publisher: [Read original article]() Author: Jaewoong Eum Published: 2026-03-28T01:23:30Z Content type: tutorial Language: en Sources: [Stories by Jaewoong Eum on Medium]() Topics: [Compose](), [Jetpack Compose](), [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [Library](), [interfaces](), [Android]() Tags: [android](), [build](), [compose](), [compose-multiplatform](), [interfaces](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [library]() ### AI overview A tutorial on building custom Landscapist image-loading plugins for Jetpack Compose and Kotlin Multiplatform. It explains the ImagePlugin architecture, its five lifecycle hook points, plugin dispatch through a DSL, and built-in plugins such as placeholders, shimmer effects, circular reveals, palettes, and zooming. ### Source excerpt Upsplash@susan_wilkinson Landscapist provides a composable image loading library for Jetpack Compose and Kotlin Multiplatform. Among its image composables, LandscapistImage stands out as the recommended choice: it uses Landscapist's own standalone loading engine built from scratch for Jetpack Compose and Kotlin Multiplatform, with no dependency on platform-specific loaders like Glide or Coil. It handles fetching, caching, decoding, and display internally, and it works identically across Android, iOS, Desktop, and Web. On top of that, LandscapistImage exposes a plugin system through the ImagePlugin sealed interface, giving you five distinct hook points into the image loading lifecycle where you can inject custom behavior without modifying the loader itself. In this article, you'll explore the ImagePlugin architecture, examining each of the five plugin types and why they exist, how ImagePluginComponent collects and dispatches plugins through a DSL, and how built in plugins like PlaceholderPlugin, ShimmerPlugin, CircularRevealPlugin, PalettePlugin, and ZoomablePlugin implement these interfaces in practice. Why LandscapistImage for plugins Before diving into the plugin system, it is worth understanding why LandscapistImage is the best foundation for plugin based image loading. LandscapistImage uses its own standalone engine (landscapist-core) rather than delegating to Glide, Coil, or Fresco. This means every stage of the image loading pipeline, from network fetching through memory caching to bitmap decoding, is controlled by a single Kotlin Multiplatform implementation. The benefit for plugins is direct: when LandscapistImage transitions from loading to success, it knows the exact moment the bitmap becomes available. It passes that bitmap directly to PainterPlugin and SuccessStatePlugin without any adapter layer or platform specific conversion. The plugin receives a real ImageBitmap, not a wrapped platform object. This also means LandscapistImage works on every Compose ## 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. [Next page]()