The week WWDC 2026 wrapped up, the most common question I received about Rork had nothing to do with new features. It was a quieter, more fundamental worry: "If I start building with Rork and later want to go fully native, am I painting myself into a corner?"
I have never been able to answer that question quickly. Saying "you'll be fine" glosses over real trade-offs, while "it depends" dismisses something that genuinely keeps people from starting. And since the Android side of this story shifted in the same week, it felt like the right moment to write down where things stand as of June 2026.
Where the Lock-In Fear Comes From
The wariness around no-code tools is earned, not imagined. With many traditional platforms, your app lives inside the platform. Cancel the subscription and the app simply stops existing — there is no codebase left in your hands. Anyone who has been through that once has every reason to ask hard questions about switching costs.
Rork is structurally different on this point. What it produces is an ordinary Expo (React Native) codebase, and you can export it to GitHub and keep it as your own asset. The app does not live inside Rork; it exists outside of it, as code that Rork happened to write.
That changes the shape of the question. It is no longer "can I escape?" but "where would I go, what carries over, and what would it cost?" That is what I want to examine here. As I see it, there are three exits.
Exit One: Don't Migrate — Growing on Expo Is the Strongest Default
The first exit sounds paradoxical, but it deserves the top spot: not migrating at all.
Expo today reaches much further than most people assume. EAS handles builds and distribution, and config plugins pull a long list of native capabilities into reach — push notifications, in-app purchases, location, camera. For the kind of apps an indie developer ships to the App Store and Google Play, the large majority of requirements fit comfortably inside Expo's range. That matches my own experience running production apps, not just the marketing copy.
The test I recommend is a single question: can you name, in one written line, a feature your app needs that genuinely cannot be built without native code? Until you can, migration is not a requirement — it is free-floating anxiety. And switching stacks out of anxiety tends to cost more than it returns: you give up shipping speed and low maintenance in exchange for a problem you never actually had.
There are boundary cases, of course. Home screen widgets or Watch integration step outside Expo's standard lane. But even then, config plugins and development builds usually offer a path before a rewrite does, and touching the boundary with one feature does not mean rebuilding the whole app. Migration is a means for specific feature requirements, never a goal in itself.
Exit Two: Android — a Kotlin Migration Agent Changes the Math
This is what prompted the essay. In the same week as the WWDC noise, news circulated that Android Studio is previewing a migration agent that analyzes React Native, iOS, and web codebases and rebuilds them as native Kotlin Android apps — the direction Google signaled at I/O 2026, now taking a form you can actually try.
Let me be sober about it: this is a preview. I would not ship the generated Kotlin to production unreviewed, and I do not expect UI details or third-party dependencies to carry over one-to-one. Verification and review work will remain.
Even so, I consider this a meaningful shift. Until now, leaving Expo on the Android side meant one option: an unscoped full rewrite. And an unscoped rewrite never even makes it onto the decision table. The real value of a migration agent is not "automatic migration" — it is that migration becomes estimable. The switching decision moves from gut feeling to arithmetic, and that improves the quality of the decision even while the tool itself is still maturing.
Exit Three: Apple — Treat It as a Rebuild, Not a Conversion
On the Apple side, no honest equivalent exists. There is no practical React Native to Swift converter, and I would rather say that plainly: the Apple exit is a rebuild.
What has changed is what a rebuild costs. With Rork Max generating Swift directly, a rebuild with a clear specification now fits a realistic budget instead of being a multi-month construction project. And the asset that carries over is not code. It is your screen structure, your data design, and the written record of what you built and why. The Expo version you shipped first turns out to have been a market test that hardened that specification.
As for when a rebuild is worth considering, I prefer store data over ambition, and I laid out those triggers in When Should a Rork App Move Up to Rork Max? Deciding With Store Data, Not Aspiration.
Apple is also steadily adding reasons to come over. At WWDC 2026, Apple opened its Foundation Models at no cost to small developers under two million first downloads — the native side keeps gaining tools, and I explored what that does to AI budgets in A Three-Layer AI Cost Design for Rork Apps After Apple Opened Foundation Models to Small Developers.
The First Choice Got Lighter — Use That
Lay the three exits side by side and a pattern emerges: the entry decision carries less weight than it used to.
The stay-on-Expo road is wide. Android now has a migration path you can put numbers on. Apple has a realistic rebuilding tool in Rork Max. The pressure to make the one correct technology choice up front has eased considerably as of June 2026. Your first shipped version is not a final commitment to a stack — it is a move that hardens your specification, and I think it is healthiest to treat it exactly that way.
In exchange, I keep one habit that I would recommend to anyone: write down the specification, not just the code. The purpose of each screen, the shape of your data, the features you cut and why. Whichever exit you eventually take — or never take — the document outlives the codebase.
If lock-in fear is what has been stopping you, start with one line: name the feature you cannot build without native code. If the line stays empty, you can set the fear down for today. If you can fill it in, that is your signal to start studying the exits. I will be doing the same — and shipping in the meantime.