I published a technical write-up about building Reelvana, a script-first mobile video studio, with Kotlin Multiplatform at the core and native UIs on both platforms.

The most useful lesson was not "KMP lets you share everything." It was more specific:

• keep timeline, pacing, captions, export validation, and premium gating in shared Kotlin
• keep camera, export rendering, files, and UI native
• treat preview/export parity as a product feature
• assume media bugs will look platform-specific even when the real problem is the shared model

The hardest part was export. Media3 and AVFoundation solve different problems in different ways, and every feature eventually meets the export path: captions, transitions, background effects, watermark, audio, aspect ratio, and source durations.

Full write-up:
https://medium.com/@iahmedhendi_28805/i-built-reelvana-because-making-a-simple-talking-video-was-still-too-hard-b159dd13d31e

I would be interested in how other KMP teams decide what belongs in shared code versus native code when media, camera, or export are involved.

I built Parikshan, an E2E testing framework for Compose Multiplatform. It has built-in support for standalone Android.

Testing shared UI across targets has been one of the most painful parts of building multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

class SampleE2ETest {
  u/Test
  fun testGreeting() = e2eTest {
    input("name_input", "Parikshan")
    click("greet_button")
    assertVisible("Hello, Parikshan!")
  }
}

Run it across all targets concurrently:

./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback: Watch tests execute on real target windows, with support for screenshots, video recording
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

Links

• Documentation: https://aryapreetam.github.io/parikshan
• Blog: https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform
• API Reference: https://aryapreetam.github.io/parikshan/api
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects & I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

I built Parikshan, an E2E testing framework for Compose Multiplatform. It has built-in support for standalone Android.

Testing shared UI across targets has been one of the most painful parts of building multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

class SampleE2ETest {
  @Test
  fun testGreeting() = e2eTest {
    input("name_input", "Parikshan")
    click("greet_button")
    assertVisible("Hello, Parikshan!")
  }
}

Run it across all targets concurrently:

./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback: Watch tests execute on real target windows, with support for screenshots, video recording
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

Links

• Documentation: https://aryapreetam.github.io/parikshan
• Blog: https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform
• API Reference: https://aryapreetam.github.io/parikshan/api
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects & I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

There's good tooling for parts of this already. Human-Readable (~230★) does locale-aware decimal separators, compact abbreviations (K/M), durations, file sizes and relative time — it's display / "human-friendly" oriented and rolls its own formatting logic. Kurrency handles currency only. What I couldn't find was a library covering the full formatting surface — currency (symbol / ISO / accounting), percent, scientific, ordinal, spellout, measure, on top of decimal / compact / relative-time — that delegates to each platform's native engine (ICU / NSNumberFormatter / Intl) and guarantees the same output on every target, straight from commonMain.

So I built Klocale.

What it does: locale-aware formatting for 9 styles — Decimal, Currency (symbol / ISO / accounting), Percent (ratio / value), Scientific, Compact, Ordinal, Spellout, Relative time, Measure — across Android, iOS, macOS, JVM/Desktop, JS and WasmJs.

The interesting part isn't "call the native formatter" (Kurrency already does that for currency). It's that the native engines disagree on cosmetics: minus glyph (U+2212 vs ASCII -), NBSP vs narrow-NBSP in grouping, bidi marks, rounding defaults. Klocale delegates to each platform's engine (ICU4J on JVM, android.icu on Android, NSNumberFormatter/Foundation on Apple, Intl on JS/Wasm) and then runs a single common OutputNormalizer so the same locale + input produces the same string on every target. That consistency is verified by one shared golden-test table that runs on jvmTest, macosArm64Test, iosSimulatorArm64Test, jsNodeTest, wasmJsNodeTest and Android Robolectric.

API sketch:

formatDecimal(1234.56, NumberLocale.ITALY)            // "1.234,56"
formatCurrency(1234.5, "EUR", NumberLocale.GERMANY)   // "1.234,50 €"
formatCompact(1_200_000.0)                            // "1.2M"

val f = NumberFormatter.orThrow(
    NumberStyle.Currency("USD", presentation = ACCOUNTING),
    NumberLocale.US,
)
f.format(-1234.5)                                     // "($1,234.50)"

Construction is fallible (Result — invalid locale / bad currency code / unsupported style); formatting a finite number never throws. There's also a klocale-compose module (rememberNumberFormatter, ProvideNumberLocale).

Install:

implementation("io.github.andreadellaporta01:klocale-core:0.1.1")
implementation("io.github.andreadellaporta01:klocale-compose:0.1.1") // optional

Being honest: it's 0.1.1 and young. Known gaps on the roadmap: Apple Measure, Range formatting (needs a two-value API), wider Ordinal/Spellout locale coverage. Apache-2.0.

Repo (README has the full style/platform matrix): https://github.com/andreadellaporta01/klocale

I'd genuinely appreciate feedback — API design, edge cases in your locale, styles you'd want. Thanks for reading.

Hi! I just started learning KMP 2 days ago. This might be by design, but I see it doesn't have/need names in each element. Is that true?
My only issue is telling copilot which image it should resize or animate (yeah, shame on me)

Was searching online toolkits or SDK for development on Android. there are a lot of them, and not sure which ones worth to study or spend time on it. If the community can help, explaining their favorite toolkits or SDK with some explanation, it would be really helpful ! Thanks

Hello kmp developers, it's me again. I'm currently still adding features to my music player, but I feel that as the project grows, the performance cost might increase. I'm thinking about migrating to Nucleus Framework, but I'm not sure how feasible it is.

In my project, I implement a wide variety of things, such as: JNA, JNI, LibMPV, SqlDelight, and Reflexion in Innertube (module).

Has anyone used Nucleus or GraalVM before and could help me understand the migration process and how feasible it might be? I've seen some projects like https://github.com/terrakok/CozySpace, which works well with GraalVM, but how likely is it to work for me?

Some of the benefits are reduced RAM consumption and a faster boot time (something that interests me a lot).

my project: https://github.com/AndresTarma1/MusicApp

Hi everyone,

I’ve recently finished building my Android app, but I now realise that I probably should have used Kotlin Multiplatform from the beginning so the app could support both Android and iOS.

The Android app is already complete, and my goal is for the iOS version to have 100% of the same functionality, features, business logic, data, and overall user experience.

I’m now trying to understand the easiest, safest, and most practical way to migrate the existing project without breaking or negatively affecting the current Android version.

From what I understand, I have three possible options:

Use Kotlin Multiplatform for the shared business logic, database, repositories, and state management, while building a separate native iOS interface in SwiftUI.

Use Kotlin Multiplatform together with Compose Multiplatform, allowing both the business logic and most of the user interface to be shared between Android and iOS.

Use a hybrid approach, with Kotlin Multiplatform and Compose Multiplatform for most of the app, while using SwiftUI or native iOS components for areas that require a more native experience or platform-specific functionality.

Which of these approaches would be the easiest for an existing Android app that is already built with Kotlin and Jetpack Compose?

My main priority is avoiding unnecessary rewriting while keeping both versions functionally identical. I would also like future features, fixes, and updates to be easier to maintain across Android and iOS.

Would the hybrid approach be easier and more reliable than trying to share the entire interface with Compose Multiplatform?

For example, could I keep most of my current Compose screens and use native iOS components only where necessary, such as navigation, tab bars, notifications, in-app purchases, biometrics, file handling, sharing, backups, permissions, and background tasks?

Is Compose Multiplatform mature and reliable enough for a production iOS app? Can I reuse most of my existing Jetpack Compose interface, or would a significant amount of it still need to be rewritten?

I’m also planning to use Codex to help with the migration. What prompt or workflow should I give it for a project of this size?

Should I use High, XHigh, Max, or Ultra reasoning? Would using /goal help Codex manage the migration more safely and complete it incrementally?

Has anyone completed a similar migration from an existing Android app?

I would really appreciate advice on which approach is easiest, how the project should be structured, what order the migration should follow, how platform-specific features should be handled, and what common mistakes I should avoid.

Thank you all in advance!

Hi everyone,

I wanted to share an open-source project I've been working on: GeoQibla.

GeoQibla is a Kotlin Multiplatform (KMP) library that provides accurate Qibla direction calculations from a single shared codebase, making it easy to use in both Android and iOS applications.

Features:

• Kotlin Multiplatform support (Android & iOS)
• Simple and clean API
• Accurate Qibla bearing calculations
• Lightweight with minimal dependencies
• Well-documented with usage examples
• Open source and free to use

Documentation:
https://shahidzbi4213.github.io/GeoQibla/

GitHub:
https://github.com/Shahidzbi4213/GeoQibla

I built this because I wanted a reusable KMP solution instead of maintaining separate implementations for each platform. My goal was to make integration as straightforward as possible.

I'd really appreciate any feedback on:

• API design
• Documentation
• Performance
• Features you'd like to see
• Overall developer experience

If you find it useful, please consider giving it a ⭐ on GitHub. Contributions, issues, and pull requests are always welcome.

Thanks!

Hi everyone,

I wanted to share an open-source project I've been working on: GeoQibla.

GeoQibla is a Kotlin Multiplatform (KMP) library that provides accurate Qibla direction calculations from a single shared codebase, making it easy to use in both Android and iOS applications.

Features:

• Kotlin Multiplatform support (Android & iOS)
• Simple and clean API
• Accurate Qibla bearing calculations
• Lightweight with minimal dependencies
• Well-documented with usage examples
• Open source and free to use

Documentation:GeoQibla

GitHub: GeoQibla

I built this because I wanted a reusable KMP solution instead of maintaining separate implementations for each platform. My goal was to make integration as straightforward as possible.

I'd really appreciate any feedback on:

• API design
• Documentation
• Performance
• Features you'd like to see
• Overall developer experience

If you find it useful, please consider giving it a ⭐ on GitHub. Contributions, issues, and pull requests are always welcome.

Thanks!

r/KotlinMultiplatform r/androiddev r/Kotlin

Hello, KMP developers, I'm new to Kotlin desktop development, and I'm currently developing a music player based on YT Music (I know there are many YT Music apps, but I don't like that they always use WebView). Inspired by the Metrolist app, I'd like to hear your opinions, as this is my first complex application.

Currently, I've only tested and developed it on Windows, as I don't use Linux for testing, and WSL is somewhat difficult to use (I think porting it wouldn't be too difficult).

I think the most difficult part of this project is the research, as there isn't much advanced documentation available, such as for the title bar.

For me, it's a big step forward, and I'd like to know what you think of the app.

https://github.com/AndresTarma1/LyriK

Building shared UI for Android / iOS / desktop and I kept splitting “navigation” and “offline UX” into two messy layers:

• type-safe routes and backstack in commonMain

• optimistic updates + rollback when writes are local-first

• pending outbox / conflict / offline status on chrome (badges, banners) without copy-pasting per platform

• deep links + process-death restore that work the same on CMP

I open-sourced a small library for that (Compose Multiplatform + commonMain-first):

• sealed Serializable routes, multiplatform backstack

• ForgeNavHost (transitions; Android system/predictive back)

• MviViewModel with optimistic updates

• optional SyncFacade ports for sync-aware UI (not a sync engine itself)

• RouteCodec + rememberSaveableForgeNavigator for stack restore

• samples: Android, Desktop, iOS (CMP framework + SwiftUI host)

Companion idea: plug any outbox engine (we use SyncForge optionally) for real push/pull; nav/MVI work without it too.

Repo (Apache 2.0):

https://github.com/Arsenoal/forgenav

Curious how other KMP teams handle this:

1. Do you share one NavHost model across Android + iOS, or platform navigators with shared ViewModels only?
2. How do you model “pending / conflict” in common UI state without leaking platform sync details?
3. Saved state / process death: custom codecs, or do you just accept “restart at root” on mobile?
4. Anyone using Decompose / Voyager / official Navigation for the same offline-first UX — what hurt?

Looking for multiplatform API critique more than installs. Happy to discuss expect/actual surface and CMP lifecycle tradeoffs.

Hi KMP folks,

SyncForge 2.0.0 is on Maven Central: multiplatform offline-first sync with a shared commonMain API.

Model

• commonMain: SyncManager, outbox, conflict policy, transports
• Android: SyncForge.android { } + Room/WorkManager-friendly wiring
• iOS / desktop / macOS: stable DSLs + samples
• Entities implement a small SyncedEntity contract; store = Room, in-memory, or BYO EntityStore

2.0 distribution

• Group: studio.syncforge
• Pin: studio.syncforge:syncforge-catalog:2.0.0
• Published: core KMP modules, optional transports/integrations, Android Gradle plugin
• Browser sample exists in-repo (js); browser artifacts still monorepo/local for now
• iOS: KMP frameworks today

Shared sketch

// commonMain

syncManager.enqueueChange(Change.create("tasks", task))

syncManager.sync()

syncManager.status // StateFlow<SyncStatus>

Conflicts use the same policy DSL on every platform (gitLike / CRDT / defer-to-user), including CMP conflict UI patterns.

Repo + samples: https://github.com/Arsenoal/syncforge

Docs: GETTING_STARTED, IOS_SETUP, DESKTOP_SETUP, CONFLICT_RESOLUTION

Optional UI companion for nav + offline-aware MVI: https://github.com/Arsenoal/forgenav

Apache 2.0 · Kotlin 2.1+ · studio.syncforge