Blog

You have probably seen “MCP” everywhere lately. Every AI tool seems to support it now. But what is it actually? The problem before MCP Imagine you have 10 AI tools and 20 data sources. Databases, APIs, file systems, Slack, GitHub. Each AI tool needed its own custom integration with each data source. That is 200 different integrations to build and maintain. Developers called this the N×M problem. What MCP does Model Context Protocol is a standard. Like USB-C, but for AI. ...

In the previous tutorial, we built the shared data layer with Ktor, SQLDelight, and offline-first sync. The data layer works, but the UI is basic. You can only see a list of notes with a “+” button that creates placeholder notes. In this tutorial, we build a proper UI layer. You will add navigation between screens, a note editing screen with a color picker, pull-to-refresh sync, and loading and error states. All of this works on both Android (Compose) and iOS (SwiftUI). ...

In the previous tutorial, we set up the Notes app architecture with a local database and shared ViewModels. Everything works offline. But real apps need to sync with a server. In this tutorial, we build the shared data layer — adding a Ktor API client, Data Transfer Objects (DTOs), an offline-first sync pattern, and a database migration. All of this code lives in commonMain and runs on both Android and iOS. ...

Welcome to Part 4 of our KMP series — Build a Real App. In the next four tutorials, we build a complete cross-platform Notes app from scratch. This article covers the planning phase: architecture decisions, tech stack, project structure, and the initial setup that makes everything work on both Android and iOS. By the end of this tutorial, you will have a working project skeleton with shared business logic, a SQLDelight database, Koin dependency injection, and basic UI on both platforms. ...

Your app will crash. The network will fail. The server will return unexpected data. The database will be empty when it should not be. The question is not if errors happen — it is how you handle them. Good error handling makes the difference between an app that shows a helpful message and an app that shows a blank screen. In KMP, you need error handling that works on every platform. No Android-specific exceptions, no iOS-specific patterns. Shared error handling for shared code. ...

You have shared code running on Android and iOS. But how do you know it works correctly on both platforms? You test it. KMP has built-in support for testing. Tests written in commonTest run on every platform automatically. Write once, verify everywhere. Test Source Sets KMP projects have test source sets that mirror the main source sets: shared/src/ ├── commonMain/ → shared code ├── commonTest/ → tests for shared code (runs on all platforms) ├── androidMain/ → Android-specific code ├── androidTest/ → Android-specific tests ├── iosMain/ → iOS-specific code └── iosTest/ → iOS-specific tests Tests in commonTest are the most valuable — they verify your shared logic on every target platform with a single test file. ...

Your app has multiple screens. A note list, a note detail, a settings page, a profile screen. Users need to move between them. On Android, Jetpack Compose uses navigation-compose. On iOS with SwiftUI, you use NavigationStack. Two different APIs for the same concept. In Compose Multiplatform, you can share navigation too. The navigation-compose library now works on all platforms — Android, iOS, Desktop, and Web. Navigation Options in CMP There are several navigation libraries for Compose Multiplatform: ...

You have learned Ktor for networking, SQLDelight for databases, Koin for dependency injection, and shared ViewModels. You have all the building blocks. But how do you organize them? Without structure, your project becomes a mess. Networking code mixed with UI logic. Database queries inside ViewModels. Platform code scattered everywhere. Clean Architecture solves this. It gives you clear layers with clear rules about what goes where and what can depend on what. ...

On Android, ViewModels hold UI state and survive configuration changes. On iOS, ObservableObjects do the same job. Two platforms, two patterns, two codebases. But the logic is often identical. Loading a user list, handling errors, managing form state — the business logic does not change between platforms. Only the UI does. With KMP, you can write your ViewModel once in commonMain and use it on both Android and iOS. Since androidx.lifecycle:lifecycle-viewmodel version 2.8, ViewModel officially supports Kotlin Multiplatform. ...

In the previous tutorials, we created Ktor clients, SQLDelight databases, and DataStore instances by hand. We passed them manually to repositories, which we passed to ViewModels, which we passed to screens. That works for small apps. But as your app grows, the wiring becomes painful. You need a way to automatically connect everything together. That is what Koin does. It is a lightweight dependency injection framework for Kotlin — and it works perfectly in KMP. ...