Test and ship with confidence

Shipping is calmer when you test in the right place at the right time and always have a way back to a good version. These tips cover both, plus a checklist for the day you publish, so you don't forget a step.

Test in the right place

Each way of testing answers a different question, from "does this screen look right?" to "does my app really work on a phone?".

Test with	When	What you get
Play (Instant Play)	While you design	An instant tap-through on the board. Close to the real app, not exact.
Run (Run your app)	Before you share or publish	Your real app in a phone frame, updated on every save.
A phone or emulator (Run on a device or emulator, desktop app)	Before you publish	The real app on the device. In a cloud project, Open on Mobile shows a QR code for your phone.
Share preview (Share your app)	When you want feedback	A link and QR code to an Instant Play preview. Cloud projects only.

If Play and Run disagree, Run is right. Play shows placeholders for maps and paywalls (the screens that ask people to pay) and simulates Firebase sign-in. Try ads and payments on a device or an emulator.

• Start a flow at its first screen. When you play a screen that has a route (an address in your app), Play starts your app's navigation at that screen, so moving to the next screens works.
• Share the whole app. A link from a played screen ends with ?screen= and opens on that screen. Delete that part and the preview starts the app from the beginning.
• Try the unhappy paths: a wrong password, a failed request, an empty list. Your users will hit them, so it's better that you do first.

Keep Problems clear

• The red number in the status bar counts errors. Click it to open Problems.
• From Nowa (Instant) checks as you edit. From Code Analysis (Accurate) checks your whole app thoroughly when you click Run Code Check. Run it before you publish: publishing to the web starts with that same check and stops on errors.
• Click Fix when a row has one. For the rest, click Navigate to jump to the cause, or ask Nowa AI: "Check my project for problems and fix them."
• If something fails only in the running app, read the Logs tab, where your app writes what it's doing.

See Find and fix problems.

Keep a way back

• Auto save is on by default, and every Nowa AI request ends with a save.
• Checkpoints undo Nowa AI requests. They aren't a backup, though: Git doesn't save them, so keep a Git commit or a downloaded copy of any version you want to return to.
• Git keeps your history. Commit (save a version you can return to) before big changes and before you publish. Git needs a plan that includes Git integration. See Use Git.
• Download your code as a zip from code mode in a cloud project. See Download your code.
• A local project lives only on your computer, and Nowa doesn't back it up. Use Git and GitHub. See Work with local projects.
• Supabase: Pull Backend Files, in the Supabase panel's ⋮ menu, copies your database setup (migrations, the recorded changes to your tables), your server functions (edge functions) and your list of storage buckets into your project, so Git can keep them. It needs recorded migrations, and the data in your tables isn't copied. See Manage your Supabase backend.
• Signing keys: download your Android signing key and your iOS certificate key, and keep them safe. Without the Android key you can't release updates.

Keep big boards fast

Big boards need no setup. Items in view build first, and only the item you hover, select or play animates. To help:

• Zoom in on your work. When more than 8 items are in or near view, the rest show as still pictures until you hover, select or play them. Select an item and press F to zoom to it.
• Use several boards. One board per flow, such as sign-up or checkout, keeps each one small.
• Remove what you don't need. Remove takes a screen off the board and keeps it in your project.
• If one item fails to draw, only it shows This screen failed to render. Fix the cause and click Reload screen. If a project freezes when it opens, choose Open in safe mode from its ⋮ menu on the dashboard. It skips the tabs from your last session.

See Work with boards.

Publish checklist

Cloud projects Paid plans

Publishing needs a cloud project on a paid plan. Work through this list first: fixing something after release can mean another store review.

Check	Where
App Name, Bundle Identifier (your app's unique ID in the stores: replace the com.example start), Build version, Build number and App Icon are set. Choose the identifier before your first store upload.	Settings → Project Details
Permissions are on for what you use, such as camera or location.	Settings → Permissions
Test settings are off. Stripe uses live keys instead of test keys, and its webhook (how Stripe reports payments to your backend) has its own destination in live mode. Google Pay is switched from Google's test environment to the real one (ask Nowa AI in Agent mode, for example "Switch Google Pay in my Stripe payments from test to production"). Do that after your last Deploy Configuration, because each deploy puts Google Pay's test setting back. AdMob Show Test Ads is off on every banner and ad call, with your real ad unit IDs and both App IDs. Maps has a key for each platform you ship.	Stripe, AdMob, Google Maps
No secret key sits in Constants or in a REST API's request settings, RLS is on for every table, and the project is Private.	Keep secrets out of your app
Problems is clear, and you've used the real app on a device.	Test in the right place
Read the store rules for each store you publish to: payments, sign-in, accounts and privacy.	Follow Apple's rules, Follow Google Play's rules
Android: Debug mode is off and the signing key is saved and downloaded. Then click Build and upload the .aab (the file Google Play asks for) in Google Play Console.	Publish to Google Play
iOS: your bundle ID is registered in your Apple Developer account, and your App Store Connect credentials and distribution certificate are saved.	Publish to the App Store
Web: click Deploy, then Deploy on the Web row. A custom domain needs a higher plan.	Publish to the web
After launch: raise Build number for every store update, and Redeploy the website.	Ship an update

Next steps

• Build a complete app, start to finish
• Troubleshooting