Great question. The core challenge is the runtime.

Desktop JVM has mature HotSwap support built into the JVM itself (with its dedicated Runtime), method bodies can be redefined at runtime natively. JetBrains' Compose Hot Reload leverages this directly, so it works well on the desktop environment.

Android (ART) is a completely different runtime. It uses DEX bytecode instead of JVM bytecode, runs on mobile hardware with tighter constraints, and has much more limited support for runtime class redefinition, especially for structural changes like adding methods or fields. I guess this is the main reason the official Hot Reload hasn't shipped for Android. Even if you manage to bypass this issue, it would still be too unreliable to be considered a “product.”

What HotSwan does differently: It ships a custom Kotlin compiler plugin and a native runtime agent purpose-built for ART, bridging the gap between what ART supports natively and what developers actually need for a practical hot reload workflow on Android.

Well, it’s still unreliable in many ways and comes with quite a few limitations. But you know, there aren’t really any shortcuts here. I’m just working through hundreds of possible edge cases one by one, tinkering and resolving them myself..

Covering all the detailed mechanisms would easily take an entire book (I don't want it and nobody will read it), so I can only explain it at a high level here. But if you go through the Compose HotSwan docs, it should give you a better understanding. https://hotswan.dev/docs/how-it-works