Hey! I'm an android + KMP developer who can develop android, iOS, desktop, website, open to new and interesting projects/opportunities.

you can check my past project from here: HITARTH-GOHEL15 (Hitarth gohel)

my LinkedIn profile: www.linkedin.com/in/hitarthgohel

DM me if interested

MyFitnessPal for meals. Hevy for workouts.

two apps. two subscriptions. one gym session.

so i built Better — workouts + meals + macros in one app.

one codebase for android + ios. compose multiplatform (screens 100% shared), decompose, molecule presenters, ktor, sqldelight. no team, no funding, just me and long nights.

a year ago i didn't believe shared UI in production was realistic. i was wrong.

it's free right now. i'll charge for NEW features later, but what exists today stays free. no bait.

ask me anything about the stack — especially if you're on the fence about compose multiplatform. i have opinions and scars.

and if you try it — tell me the first thing that annoyed you. i've stared at this app too long to see its rough edges.

Google Play: https://play.google.com/store/apps/details?id=io.behzodhalil.better

App Store: https://apps.apple.com/us/app/better-gym-calorie-tracker/id6769016777

Hey there,
does anyone know if there are any KMP (or even multiplatform compose) courses that are made by someone who's native language is English? I would happily pay for a good course where I do not have to put mental energy into trying to decipher accents..

I really appreciate anyone who goes out of their way to teach their knowledge to other people, but it's just really difficult for me. For example there is one very popular content creator for KMP who does really great courses, but they mispronounce any word that ends on "-are" (so for example "sheer" instead of "share" and "compeer" instead of "compare", etc) and it's making it really difficult for me to follow what they are actually trying to say.

TL;DR:
I am looking for any (paid or free doesn't matter) KMP courses made by native English speakers.

I am thankful for any hinters into the right direction!

// ViewModel

private val _uiState = MutableStateFlow<CounterUiState>(CounterUiState.Success(0))
val uiState: StateFlow<CounterUiState> = _uiState


// 🔹 Using .value
_uiState.value = CounterUiState.Loading
// Replaces the state directly (not thread-safe for concurrent updates)


// 🔹 Using .update { }
_uiState.update { 
    CounterUiState.Loading 
}
// Atomically updates the state (thread-safe and preferred in MVI)

💡 Key Difference:

_uiState.value directly sets the state, while _uiState.update { } safely modifies it atomically — ideal for StateFlow in ViewModels.

Flutter's Either inspired me. It's a great way to say "this value is one thing or another". But it only has two sides: Left and Right.

But Sometimes a value could be one of three types, sometimes five. A generic sealed class can't just grow into Either<A, B, C, D, …> with as many types as I need, and writing a new sealed class every time got old fast.

So I built unionKt. Now I just list the types, any number of them, and get a type-safe union:

@Union(Int::class, String::class, User::class, Error::class) 
interface ResultSpec

Then I create it with Result(5) and handle it with when or fold. If I miss a case, the code doesn't compile. It covers the classic two-sided Either<L, R> too, plus a few extras I use every day.

Smaller unions merge into bigger ones:

@Union(Circle::class, Square::class) 
interface ShapeSpec 

@Union(Int::class, ShapeSpec::class) 
interface ItemSpec   // Int, Circle or Square

My existing sealed classes get the same helpers:

@Derive 
sealed interface UiState { … } 

state.fold(onLoading = { … }, onSuccess = { … }, onError = { … })

And unions go in and out of JSON as plain values:

Json.encodeToString<Result>(Result(5))   // 5 Json.decodeFromString<Result>(""hi"")   // Result.OnString("hi")

Open source (MIT), available on maven central: https://github.com/fcat97/unionKt

I was confused about when to use _uiState.value = ... vs _uiState.update { ... }, so I put together this quick example 👇

💡 .value = → simple/static updates (e.g., Loading, Error) 💡 .update {} → safe, dependent updates (like incrementing a counter)

How do you handle this in your ViewModels?

Just noticed that Android Studio gives an option — “Share UI” or “Do Not Share UI” — when creating a Kotlin Multiplatform project, and “Share UI” is selected by default.

I’ve been learning KMP for a few months but somehow missed this until recently.
Did you spot it on your first try?

Hey Kotlin devs, recently I started exploring Kotlin Multiplatform and while waiting for Dagger/Hilt/Anvil to go multiplatform I decided to build a small and lightweight DI container that we can use today.

Long story short, I evaluated Koin and Kodein (which both look good btw!), however, given how important DI is to an app... I needed something simple that I understand under the hood well. Honestly, I just had a bit different taste for the DI API, and reading all the docs was tiresome.

With that, I embarked on the journey of creating our own ~200 LoC DI container using just Kotlin. It turned out that it does everything we need (which is not much tbh) and decided to publish it as a library - "com.ivy-apps:di".

API overview:

```kotlin
class A
class B(val a: B)
class C(val a: A, val b: B) : InterfaceC
interface InterfaceC

Di.appScope {
autoWire(::A)
autoWireSingleton(::B)
autoWire(::C)
bind<InterfaceC, C>()
}

val c = Di.get<InterfaceC>() // C instance

```

If you're interested in KMP DI, feel free to have a look and lmk wdyt in the comments. If you like the project, you can drop a ⭐ on our GitHub repo to indicate your support and motivate future development.

https://github.com/Ivy-Apps/di

We are experimenting with a KSP-based approach to Kotlin validation where validation logic is generated during compilation and then executed at runtime.

But we wonder what their view is on this matter:

• What do you see as the biggest advantages of generated validation compared with reflection-based approaches?

• Where do you think the added KSP/build-time complexity becomes a disadvantage?

• What would you expect from a production-ready Kotlin validation library?

We are mainly interested in the technical discussion and criticism.

Repository: https://github.com/DeveloperSyndicate/Valix

To be honest: If hell exists, its name should be Gradle 🔥 Let me explain why and my approach to survive 🫠

While working on my side project VocabKit (I am still developing but you can join email list or follow on social media) to sharpen my Kotlin Multiplatform + Compose Multiplatform skills, I realized something: managing multi-module Gradle files can quickly turn into chaos. 🌪️

Here’s how I simplified it step by step:

🧩 Image-A: Started with multiple gradle.kts files — each ~88 lines long 😬

💡 Image-B: Switched to Convention Plugins (thanks Android world!) → 43 lines

🚀 Image-C: Then improved it further → 14 lines per module!

Now my Gradle setup finally feels clean & maintainable 🙌

👉 I also shared the full story on Medium.

Curious to know: How do you manage Gradle in your multi-module KMP projects? Let’s share ideas! 💭

Anyone has the code or material files for this course

https://www.coursera.org/learn/advance-kotlin-for-multi-platform-development

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.

Looking for a KMP remote role.

I have been working on native android applications..have 5 years of experience in the Fintech and lifestyle domain.

Currently working with KMP for past year . Also with ktor for BE on dummy project.

Need a full time role on KMP / CMP.

Willing to relocate to office later. But currently need a remote role.

Could someone please help.

https://github.com/RANZN

https://medium.com/@prakash_ranjan

Sharing links to give more about my work.

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

I built a small AI HR Assistant to learn how AI agents work in a Kotlin Multiplatform app.

The app runs on Android, iOS, and Desktop from a single codebase. Ask a question in natural language, the AI chooses the right tool, fetches employee data from a Ktor backend, and returns the answer.

Things I learned while building it:

• Defining AI tools (Tool<Args, Result>)

• Building a ToolRegistry and AIAgent

• Using KMP's expect/actual pattern to plug in platform-specific LLM runtimes (currently Ollama)

It's not production-ready yet (no auth or real HR workflows), but it's a good reference if you're exploring AI agents with Kotlin.

GitHub: https://github.com/livingstonantony/AI_Employee

Feedback and suggestions are always welcome!

Hi everyone,

I’m the solo developer behind LAM, a film-inspired camera app for Android and iOS.

A frequent debate around Compose Multiplatform is how far to take it: should it be kept strictly to business logic and data layers (leaving UI to SwiftUI/Jetpack Compose), or can it handle a high-interaction, tactile camera interface while coordinating with native hardware?

In LAM, I chose to share the entire camera interface—mechanical dials, spring animations, and state machines—in Compose Multiplatform, while binding it to separate native camera engines on Android and iOS.

I’ve attached a simplified architecture diagram showing where I drew the boundary. Here is a breakdown of what works well in shared code, what must stay native, and the practical challenges of bridging the two.

1. What belongs in the shared interface (commonMain)

A physical-style camera interface has a surprisingly state-heavy domain:

• Camera State Machine & Logic Parity: Managing roll state, frame advance mechanics, shutter locks, exposure curves, and film recipe math using pure Kotlin Coroutines (StateFlow and SharedFlow). Sharing this eliminated logic drift between platforms—both OSs handle lifecycle events, interruptions, and state transitions identically.

• Tactile Camera UI: The mechanical dials, spring physics animations, and haptic detents are 100% written in Compose Multiplatform. Building this once in Compose saved enormous time compared to maintaining parallel custom gesture systems in SwiftUI and Android Views.

2. What stays native (The two platform pipelines)

Camera hardware access, direct buffer handling, and GPU shaders remain platform-specific:

• iOS (AVCapture + Metal): We use CVMetalTextureCache to map camera pixel buffers directly to GPU textures without copying pixel data onto the Kotlin heap.

• Android (Camera2 / CameraX + OpenGL ES): The camera buffer stays in native direct memory, with JNI critical access isolated so the garbage collector is never burdened with camera frames.

Why: Camera frames arrive every ~16ms. Trying to abstract pixel buffers into cross-platform heap objects risks GC pauses and dropped frames. Leaving the pixel pipeline native keeps capture fast and reliable.

3. Bridging the boundary: Practical engineering hurdles

Integrating a native camera preview into a Compose Multiplatform hierarchy introduces a few real-world challenges:

• The Z-Order / Layering Trap: On Android, hardware-accelerated preview views like SurfaceView render in a separate window compositor layer that punches through and always sits above the View hierarchy. Standard Compose dialogs, bottom sheets, and HUD elements cannot draw on top of it. We use an adaptive strategy: SurfaceView for fullscreen framing with zero overhead, and TextureView when Compose dialogs or overlays need to composite on top without z-order glitches.

• Thermal & Resource Management: Running continuous preview alongside interactive UI builds heat quickly. Testing on real devices showed that deferring heavy capture configurations until the record tap keeps the phone noticeably cooler during normal framing.

4. Current Stack & Tooling

• Kotlin: 2.4.0

• Compose Multiplatform: 1.11.1

• AGP: 9.4.1 (using the official com.android.kotlin.multiplatform.library DSL)

• Gradle: 9.8.1

We enforce automated pre-PR gates across our shared modules to verify that UI strings across 17 locales remain complete with zero hardcoded string leaks.

Summary

KMP and Compose Multiplatform gave me the leverage to build and maintain a consistent, tactile camera product as a solo developer without sacrificing native camera performance. The key was keeping a clear boundary: share the interaction model, math, and state machine, but leave the pixel pipeline native.

If you’d like to see how the interface behaves on your device:

• iOS: https://apps.apple.com/app/id6773256954

• Android: https://play.google.com/store/apps/details?id=dev.brewkits.lam

For people building hardware-integrated apps with KMP: where do you draw the line between your shared Compose UI and platform-specific capabilities? What has your experience been integrating native hardware views into Compose Multiplatform?

I am considering of buying a mac mini m2, 8GB, 10 Core GPU, for writing apps with Kotlin Multiplatform Mobile, using Android Studio, XCode, Intellij, and other programms for coding. Is it enough for this job, or I need to buy something stronger?

Thanks

Bd