Documentation
Why HotSwan
If you build Android apps with Jetpack Compose, you have probably accepted slow feedback loops as part of the job. Change a color, wait for Gradle to build, watch the app reinstall and restart, navigate back to the screen you were working on, and rebuild the UI state you just lost. Repeat. This comes with a real cost, and it is not cheap.
Live Edit has improved the workflow, but it can still feel slow in larger projects. Compose Previews are great for writing UI, but they come with constraints and do not always match what you see on a real device. Because of that, many developers still end up running the app to confirm the result.
And sometimes even a tiny change, like updating a string, means waiting for the whole project to build again. After doing this hundreds of times, it starts to feel normal. But it does not have to be. This page explains why.
The build tax
Picture this. You are working on a detail screen that sits seven screens deep in your app. You have spent a few minutes navigating there, loading the right data, scrolling to the section you care about. Everything is set up. All you want to do is make the title text a little bigger.
You change fontSize = 16.sp to 18.sp. Gradle starts building. On a small project, you wait 30 seconds. On a large multi module codebase, it can be 5, 10, or even 30 minutes. The build finishes. The app reinstalls. It restarts from the home screen. All your state is gone.
Now you navigate through those seven screens again. Load the data again. Scroll to the same spot again. And when you finally get there, you cannot remember what the old size looked like. You cannot compare. The context you spent minutes building up has been destroyed by a single build cycle.
Every change triggers a full build cycle. The app restarts, state is lost, and you navigate back from scratch.
No rebuild, no reinstall, no navigation. Your app stays alive with UI state preserved.
With HotSwan, the same change takes about one second. The app does not restart. You stay on the same screen with the same data, the same scroll position, and the same navigation state. You see 18.sp right next to where 16.sp was a moment ago. You can compare instantly and decide whether to keep it or try 17.sp.
This applies to everything you touch in your composables. Change a font size, adjust spacing, swap a color, tweak modifier parameters. Each change reflects on device in about a second.
Hard to reach screens
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. An empty list that only shows when all items are deleted. A detail screen buried behind five taps of navigation.
Every full build resets the app to its start screen. If you are iterating on one of these hard to reach 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.
Animation tuning
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 revert.
With a full build, each attempt requires rebuilding, restarting, navigating back to the screen, and re-triggering the animation conditions. If the animation plays on entry, you have to leave and re-enter the screen. 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.
State preservation is the key
A screen refresh without state preservation is not very useful. If the app restarts and you lose your navigation stack, remember{} values, ViewModel data, and scroll positions, you are back to square one. You cannot compare before and after because the "before" context is gone.
This is why state preservation is not just a feature of hot reload. It is the point. Without it, you are watching a screen rebuild from scratch every time, which tells you almost nothing about how your change affects the actual user experience.
HotSwan preserves your full app state across reloads. Navigation stacks, remember{} values, ViewModel instances, scroll positions, text field contents, dialog states. The reload updates only the composable scopes that changed. Everything else stays exactly where it was.
You can read more about how this works in the State Preservation documentation.
AI powered vibe coding
The traditional workflow with AI coding tools looks like this: you write a prompt, the AI generates code, you build the project (30 seconds to several minutes), look at the result, decide it is not what you wanted, and prompt again. Each iteration burns time and tokens. By the third or fourth attempt, you have spent more on the loop than the change is worth.
HotSwan changes this from a generation loop to a decision loop. You ask the AI to generate three or four variations. Each one appears on your device in about a second. You look at them in context, on the actual screen with real data, and pick the one that works. Then you refine from there.
Choosing from four options is faster and more satisfying than asking for one and hoping it is right. The combination of AI code generation and instant visual feedback turns UI iteration into a conversation rather than a guessing game.
For a full walkthrough of using AI tools with HotSwan, see the Hot Reload with AI guide.
Who benefits
- Solo developers: UI iteration that used to take minutes per change drops to seconds. You spend your time designing, not waiting.
- Design and development teams: Designers can sit with a developer and see changes on a real device in real time. No more waiting for builds to review visual changes, and no more awkward "just a second…" moments that somehow take several minutes.
- Enterprise teams: On large codebases where full builds take 15 to 30 minutes, HotSwan makes UI iteration practical again. Developers can make dozens of changes in the time a single build would take.
- Teams using AI coding tools: Instant feedback on AI generated code reduces both time and token costs. You see what the AI produced before committing to another generation cycle.