Why HotSwan

For most of its life, hot reload in the Compose world has meant one thing: change a value, see the value. Swap a color, nudge a padding, fix a string. Useful, but bounded. The moment you added a composable or changed how a screen branches, you were back to a build and a fresh launch.

HotSwan 2 runs your new code in an interpreter inside the running app, so the boundary moved a long way out. In the clip below a detail screen is not being tuned. It gets a new background field, a new information hierarchy, and a color language that shares nothing with what was there. The app never restarts.

Look at what survived that. The app is the same process it was before the edit. The navigation stack still knows where you came from, your scroll position is where you left it, and every remember{} value the change did not touch is still holding what it held.

That combination, a screen replaced wholesale with different code while the state underneath it stays put, is the feedback loop developers have historically had to switch toolkits to get. This is it in native Jetpack Compose, in Kotlin, with the build and the libraries you already have.

If you write Compose Multiplatform, your bugs do not live inside a target. They live in the gap between targets, where the Android build looks right and the iOS one does not, and you find out two rebuilds later. Checking that gap has always meant running one target, then the other, then trying to remember what the first one looked like.

HotSwan reloads Android, the iOS simulator and Compose Desktop from the same save. Below, one edit lands on an Android device and an iOS simulator at the same moment, and both keep running.

Seeing the same edit land on two platforms in the same second turns a cross platform check from a build cycle into a glance. See Kotlin Multiplatform for setup.

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.

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.

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.

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.

It goes further than picking between finished attempts. Because the reload pipeline is exposed over the HotSwan MCP server, an agent can drive it directly. In the clip below an agent has the editor. It reorganizes a screen, adds behavior that did not exist, and takes the whole thing through a redesign. Watch the running apps rather than the code.

This is the part that changes what an agent is useful for. An agent that waits 40 seconds to see the effect of a change cannot iterate on a design. It can only guess, finish, and hand you the result to judge. An agent that sees its own output on a running app can try something, look at what actually happened, and correct itself before it ever asks for your review.

It changes your side of it more. You are no longer reviewing a finished direction, you are watching one form. When the agent takes the screen somewhere you did not want, you see it on the second file rather than after the tenth, and one sentence puts it back on course.

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.