Skip to content

Insights · Testing · 2 min read

Preview in the browser. Confirm on a phone.

What each preview tells you, what still needs a real device, and why a working preview is one step towards a release rather than the last one.

Know which view you are using

The canvas is where you select, arrange and set properties. Preview runs the project so you can use its buttons, navigation and logic. The code workspace keeps a preview beside your files that rebuilds as you type.

All three run your real app in a browser through a web adapter. That is ideal for short feedback loops, but it is still a browser: it cannot reproduce every permission, device service or rendering detail of a phone.

Take the same project to a phone

Phone testing packages the current project for Expo Go and shows a QR code. Your computer serves the preview on the local network, so the phone must be able to reach it, and applied changes are sent to the phone as you keep working. Compile errors are reported rather than replacing the running version.

A successful bundle means the code compiled for both platforms. It does not mean every interaction has been tried. Phone testing works in the local editor and is coming soon on the hosted site.

  • Try navigation, Back and any sign-in flow.
  • Open the keyboard and check that inputs stay reachable.
  • Check portrait and landscape where your app supports them.
  • Exercise denied permissions and a lost network connection.
  • Confirm images, fonts and touch targets on the actual device.

Recognise the limits of Expo Go

Expo Go brings its own set of native capabilities. Adding a library in Appsanic cannot add a native module to it, so purchases, push notifications, error reporting and libraries with native code need a native build of your own app.

The preview also says nothing about your final app icon, launch screen, permission texts or store setup. Those come from a built app and the store consoles, and are separate checks.

Finish the checks a preview cannot do

App settings collect identity, icons, permissions and store listing inputs, and the release checks list what is still missing, including fields that only become required because of an answer you gave. Completing them prepares a release; it does not sign or submit one.

Before you distribute anything, verify the native build itself, the permissions your app relies on, the store declarations and your platform accounts. Keep one short, repeatable test journey so you can run it again every time the app changes.

All insights