You already have a working Expo or React Native app. You don't want to rebuild it. You just want it in FluxNative, so you can preview, build and publish it there.

Your own coding agent can move it for you over MCP, with one careful prompt. This guide explains how the move works, gives you the prompt, and shows how to check the result.

Key takeaways

Move the app, don't rewrite it. Keep its screens, navigation and assets.
The quickest path is the ZIP import on your dashboard. Use MCP when you want your coding agent to do the move.
Over MCP, one prompt copies the code and assets, makes small fixes and checks the build.
Never copy secrets, signing keys, node_modules or build output.

Two ways to bring your app

Upload a ZIP. On paid plans, choose Import an existing Expo app on your dashboard and upload the project: one Expo Router app per ZIP, up to 100 MB, without node_modules, android/ or ios/. FluxNative checks it and starts a preview before it creates the app, and it keeps your own folder structure.
Let your coding agent move it. On the Creator plan and above, connect Claude Code, Codex or Cursor over MCP and send the prompt below. Pick this when you're already working in your editor, when your app uses React Navigation rather than Expo Router, or when you want to guide each step.

The rest of this guide covers the MCP path.

How the move works

Your coding agent sees two places at once:

Your local folder: the app you already have.
The FluxNative app: where it's going, reached over MCP.

The agent reads both before it changes anything. Then it copies files with guarded writes: each write names the version it read, so it can't overwrite a newer change by accident. Images, fonts and sounds go straight from your disk to FluxNative, so the files never pass through the chat.

One rule to know: over MCP, an agent can't create new top-level folders or files. Code that lived outside the folders a FluxNative app already has, like components/, screens/ or a root App.tsx, goes under src/.

What to copy, and what to leave behind

Copy everything the app needs to run. Leave out everything that's generated, private or tied to one machine.

Leaving these out doesn't make the move less complete. It makes the app safer and easier to build anywhere.

FluxNative apps use Expo Router for their routes. If your app already uses React Navigation, keep it. A small route that hosts your existing app is usually all you need.

Don't rewrite every screen just to match a folder layout. That adds risk and gives your users nothing new. Make the smallest change that lets the app build, and let real build errors guide the next fix.

The prompt to copy

Connect your coding agent to FluxNative. See Connect an editor.
Open your local app folder as the agent's workspace.
Send this prompt, with your app's name filled in.

Move the existing Expo / React Native app in this workspace into the FluxNative app named "<your app name>". Find it with list_apps if you need its id, and change no other app.

Treat this as a careful migration, not a rewrite. First read the local project: package.json, app config, entry point, navigation, assets and tests. Then read the FluxNative app before you change anything. Keep the app's behavior, look and feature code. Don't replace it with a starter app or add new features.

Copy every source file and runtime asset the app needs. Write text files with the guarded write tools. For images, fonts and other binary files, use the upload tool so each file goes straight from disk to FluxNative; never paste file contents into chat. MCP can't create new top-level folders or files, so put code that lived outside them (such as components/, screens/ or App.tsx) under src/ and update its imports. Don't copy node_modules, build output, generated ios or android folders, signing files, credentials, or private values from .env.

Make only the smallest compatibility changes FluxNative needs. If the app uses React Navigation, keep it and add a thin Expo Router route that hosts it. Update the app config, and write .fluxnative/app-spec.json so it describes the app's real screens and main flows. Don't bulk-delete template files unless one clearly conflicts with the entry point or the build.

Then run build_preview. If it fails, fix the actual error with the smallest change. Check the first screen with preview_view and the console with preview_logs. Don't claim iOS or Android was tested from a web preview. Finish with a short report: what you copied, every compatibility change, the build result, and anything that still needs a test on a real device.

Check the result

The files match. Compare the local and FluxNative files, including images and fonts.
The build passes. The project compiles without errors.
The first screen shows. It renders in the preview, and the console is clean.
Then test on a phone. A web preview can't prove haptics, audio, permissions or store builds. Make a native build and try it on a real device.

Frequently asked questions

Will the agent upload my secrets?

No. The prompt tells it to skip private .env values, signing files and generated native folders. Keys belong in Connections, not in the source.

No. The prompt asks it to keep your navigation and to add a thin Expo Router route only where the build needs one.

Which coding agents can I use?

Any MCP client FluxNative supports, including Claude Code, Codex, Cursor and VS Code. Remote MCP comes with the Creator plan and above.

Keep exploring

Connect an editor — Set up Claude Code, Codex, Cursor or VS Code.
Build a mobile app with Claude Code or Cursor — How your agent and FluxNative split the work.
Native builds overview — Test the moved app on a real phone.

Bring an Existing React Native Project to FluxNative Through MCP