Compose Hot Reload: Real-Time UI Updates on Running Android Devices

If you have spent any meaningful time building Android apps with Jetpack Compose, you know the loop. You change a color value, save the file, and then wait. Gradle compiles. The app reinstalls. It restarts from the launcher screen. You navigate back through three, five, seven screens to reach the one you were working on. By the time you get there, you have already forgotten what the previous value looked like. The context you spent minutes setting up has been destroyed by a single build cycle.

The deeper issue is not just the wait. Every full rebuild resets your app state. Scroll positions, navigation stacks, form inputs, dialog states, in memory ViewModel data. All of it disappears. You are not comparing your change against the previous version. You are rebuilding the entire context from scratch, every single time. On a small project this costs 30 seconds. On a large multi module codebase, it can cost 5, 10, or even 30 minutes per iteration.

In this article, you will learn how Compose hot reload works on Android, what makes it different from existing solutions like Live Edit and Apply Changes, and how it changes day to day Compose UI development.

Save a .kt file, see the change on a real Android device in under a second. No app restart. No state loss. No navigation reset. The screen you are looking at updates in place with all your data, scroll position, and navigation stack intact.

This works on physical devices and emulators. You do not need a special build variant, a test harness, or a preview annotation. You run your app normally, edit your code, and see the result on the same screen you were already looking at.

The full pipeline from file save to UI update involves five steps. Each one is designed to minimize the amount of work, so only the code that actually changed gets recompiled and applied.

When you save a Kotlin file, HotSwan detects the change and identifies which Gradle module the file belongs to. It runs an incremental build on just that module, not the entire project. The HotSwan compiler plugin isolates each function body into its own compilation unit during this step, so changing one function does not affect its siblings.

After compilation, HotSwan extracts only the classes that actually changed by comparing the fresh DEX output against a baseline captured from the installed APK. These changed classes are sent to the device and swapped directly in the running app's memory using a native agent. No new objects are created. Existing instances automatically use the new method bodies on the next call.

Finally, HotSwan triggers a targeted Compose recomposition. The Compose runtime already tracks which scopes are affected by which classes, so it recomposes only the scopes that changed. Everything else stays untouched. The whole cycle, from save to visible UI update, takes about one to three seconds on the first reload and often under a second on subsequent reloads.

HotSwan is not limited to simple text and color changes inside composable functions. Because it operates at the runtime class level, it can swap any Kotlin function body. Here is the full range of what you can change without restarting your app:

Getting an animation right is trial and error. You adjust a spring constant, an easing curve, a duration. You need to see the result, compare it to the previous version, and decide whether to keep going or try something else.

With a full build cycle, each attempt requires rebuilding, restarting, navigating back to the screen, and re-triggering the animation conditions. If the animation plays on screen entry, you have to leave and re-enter. If it depends on specific state, you have to recreate that state. The feedback loop is so slow that most developers settle for "close enough" rather than getting the animation exactly right.

With HotSwan, you change dampingRatio = 0.6f to 0.5f to 0.4f, each one about a second apart. The trigger context stays alive. You see each variation on the same screen with the same data. You can make dozens of adjustments in the time a single full build would take.

Some screens are painful to reach. A payment receipt that only appears after a successful checkout. An error state that requires a specific API failure. A detail screen buried behind five taps of navigation with specific data loaded.

Every full build resets the app to its start screen. If you are iterating on one of these screens, you spend more time navigating than you spend looking at your changes. On a large project, a single UI tweak can cost you several minutes of navigation and data setup on top of the build time itself.

HotSwan preserves your navigation stack and your app state. If you are on a detail screen three levels deep with specific data loaded, you stay there after the reload. The screen updates in place. You never leave the context you are working in.

When you connect multiple devices, HotSwan broadcasts each change to all of them simultaneously. Edit a composable once and see the result appear on a phone, a tablet, and an emulator at the same time. This is useful for catching layout issues that only show up at specific screen sizes, and it removes the need to rebuild and install on each device separately. See the Multi-Device Hot Reloading docs for setup details.

Sometimes your edit is even simpler. You change a padding value from 16.dp to 24.dp, or a font size, or a color hex code. For changes that only touch constant literal values, HotSwan skips the entire compilation step and patches the value directly on the running device.

The result appears in under 50 milliseconds from the moment you save. No Gradle, no DEX generation, no class swap. The value is resolved against a representation of your composable tree that HotSwan maintains on the device, and the Compose runtime picks it up on the very next draw pass.

This makes it practical to fine tune colors, spacing, and typography by eye. You iterate as fast as you can type. String literals, integer and float values, color hex codes, and resource values in XML files all qualify for the fast path. For the full list of supported literal types, see the Literal Patching documentation.

Setting up HotSwan takes a few minutes. The workflow is straightforward:

For the full step by step walkthrough with screenshots and Gradle configuration examples, see the install guide. For technical details on the pipeline, supported changes, and limitations, visit the documentation.

Hot reload removes the build, wait, navigate loop from your workflow. Instead of rebuilding your app every time you change a composable, you see the result on a real device in about a second. Your state stays intact. Your navigation stack stays intact. You stay in the context you were already working in.

The practical effect goes beyond saving time. When the cost of trying something drops from minutes to seconds, you try more things. You iterate on animations until they feel right instead of settling for the first value that compiles. You experiment with layout variations on a real device with real data instead of guessing in Preview. You catch responsive layout issues by watching the change appear on multiple screen sizes simultaneously. The speed of feedback changes how you work, not just how fast you work.

Whether you are a solo developer tuning UI on a personal project or part of a team working on a large multi module codebase where builds take tens of minutes, hot reload makes Compose UI iteration feel the way it should: immediate, iterative, and grounded in what you see on screen.

As always, happy coding!

— Jaewoong (skydoves)