Docs / mobile-preview

Preview on your phone

The Mobile tab runs your app two ways: a phone frame in the browser for a quick look, and the real app on your own device through Expo Go. Both come from the same bundler, so what you see in the browser and what your phone runs are built from the same code.

Both need the mobile app to exist first. If the tab still reads No mobile app yet, add one before you carry on.

In the browser

  1. Open the Mobile tab in the center panel of your project.
  2. Click Start preview. The badge moves Not running → Starting → Live.
  3. Your app appears inside a phone frame.

The first start takes about a minute: dependencies are installed and the first bundle is built. Later starts are quicker.

Three device sizes sit at the right of the toolbar — compact, galaxy-s, and foldable — plus a Portrait / Landscape switch. They change the frame the app is drawn into, nothing else.

Reload re-runs the frame by hand. Stop shuts the preview down; you can start it again whenever you want.

The browser frame is a browser rendering of a React Native app — an approximation. Fonts, gestures, scrolling and native components can differ from a real device. Check anything that matters on a phone.

On your phone

  1. Install Expo Go from the Play Store or the App Store.
  2. With the preview Live, click Test on phone. The Open on your phone dialog shows a QR code and the link under it.
  3. Open Expo Go and scan the code.

Your app loads over a secure public address, so the phone only needs internet — it does not have to be on the same Wi-Fi as your computer.

Test on phone stays disabled until the badge reads Live; a phone has nothing to connect to before that.

Keep the workspace tab open while you test. The open tab is what tells us the preview is still in use — close it and the preview shuts down on its own after a while.

Live updates

Every time a run finishes, connected phones are asked for a full reload and the browser frame refreshes itself. Ask for a change in the chat, wait for the run to finish, and the app on your phone updates without rescanning.

The reload is a full one rather than a patch on purpose: when the AI adds or changes a dependency, a partial update leaves the app in a broken state.

When it crashes

If the badge turns Crashed, the panel shows The bundler stopped. with the error underneath, and a Resolve with AI button beside it. It appears only in this state — a running preview has nothing to resolve.

Resolve with AI hands that error to the AI as a new run. It opens a dialog showing exactly what will be sent — the crash reason and the recent bundler log, with secrets already stripped — so you can see what you are sharing first. Confirm with Send to AI and the fix is written against your mobile app rather than the web one. It costs one run against your monthly credits, and the dialog says so before you confirm.

If the preview sat idle long enough to be shut down, the dialog can still tell you why it crashed but no longer has the log to go with it. That is normal rather than an error — the fix simply goes out with less to work from.

You can also skip the button and describe the fix yourself in the chat. Either way, click Start preview again once the cause is fixed.

When your network blocks it

The preview is served from a different domain than the platform itself, and some networks — office Wi-Fi, campus networks, ISP filters — block domains registered recently. When that happens the badge still reads Ready and it is telling the truth: the bundler really is running. The request never left your network, so the platform never saw it fail.

The panel checks for this and covers the device frame with Your network is blocking this preview, naming the hostname it could not reach. Switch networks to confirm — a phone hotspot is enough — or hand that hostname to whoever runs the network.

One limit worth knowing: the check runs in this browser, so it can only speak for the network your computer is on. If the QR scan connects from a phone on a different, also-filtered network, nothing here can see that — it shows up only as a scan that never connects.

Environment variables

The preview forwards the project environment variables whose names begin with EXPO_PUBLIC_ — the same variables you edit in the Publish dialog. Nothing else reaches the phone: your database URL and API secrets stay on the server side.

That prefix is Expo's own rule, and it has a consequence worth stating plainly. Anything with it is written into the JavaScript bundle your phone downloads, so treat those values as public and never put a secret in one.

Change one of these values while a preview is running and you need to Stop and Start preview again to pick it up.

Limits & notes

  • The status badge stops updating by itself if the bundler is still starting after 3 minutes. That is not a failure — the app may still come up. Reload the page or send a prompt and the panel starts tracking again.
  • When a follow-up prompt says something is still broken — "still not working", "masih error", or a quoted error message — the recent dev server and bundler output is attached to that prompt automatically, so you no longer have to copy the log in yourself. It goes in as capped reference material, with secrets stripped.
  • A preview stops after 30 minutes without activity from you, and after 4 hours in every case. The 4-hour cap cannot be extended. Start it again whenever you need it.
  • Push notifications cannot be tested in Expo Go. They only work in an installed build — see store builds.
  • This is a development preview, not a store build. It is not something you can hand to a user.
  • While a preview runs it is reachable by anyone who has the link, so treat the QR and the address as private and stop the preview when you are done.
  • On iPhone the app runs in Expo Go the same way it does on Android. iOS store builds are not available yet.
  • Limits may change during alpha.

Related