How to build a mobile app with AI: from Expo to the stores

The fastest way to build a mobile app with AI is to have a coding agent set up a React Native project with Expo, try every change on your own phone with Expo Go, and use a hosted backend like Supabase or Firebase. The agent writes the screens, data layer and sign-in; you test on the device, feed errors back and handle the store steps. Publishing still needs Apple and Google developer accounts and their review processes.

This post walks the whole path from an empty folder to the stores: which stack I pick and why, the first prompt I give the agent, how I test on a phone, auth and notifications, publishing, and where agents trip up most.

Set expectations first

There’s a real difference between vibe coding a website and vibe coding a mobile app. On the web, if the code runs, you’re done. On mobile there’s a platform layer on top of the code: build tools, signing certificates, permissions, store rules. The agent handles most of the code comfortably; the platform side needs your eyes and hands.

The good news: pick the right tools and you won’t touch most of that platform layer in the first few weeks.

Which stack: Expo, Flutter or native

There are three main routes.

For a beginner my answer is clear: React Native + Expo. The reason is less about technical merit and more about feedback speed. The agent changes something and you see it on your phone seconds later. The shorter that loop, the better vibe coding works.

Flutter is a fine choice if you know Dart or your team already uses it. Native only makes sense when you have a specific reason, like camera processing, heavy graphics or deep platform integration.

Step 1: Setup

What you need:

• Node.js (an LTS release) and a package manager
• A coding agent: Claude Code, Codex, Gemini CLI or another coding agent
• Expo Go on your phone, from the App Store or Google Play
• Git, so every step the agent takes can be undone

Create the project yourself. Agents scaffolding from scratch sometimes reach for outdated templates:

npx create-expo-app@latest habits
cd habits
git init && git add -A && git commit -m "initial scaffold"
npx expo start

A QR code appears in the terminal. Scan it with the camera on iPhone or from inside Expo Go on Android, and the app opens on your phone. Your computer and phone need to be on the same Wi‑Fi. If the network gets in the way, try npx expo start --tunnel.

Step 2: The first prompt

The first prompt shapes every decision the agent makes afterwards. Leave gaps and it fills them with its own preferences. I write something like this:

This is an Expo (React Native, TypeScript) project. We're building a
simple habit tracker.

Screens:
1. Today: list of habits, each with a "done" button
2. Add: create a habit with a name and a daily goal
3. History: calendar view of the last 30 days

Rules:
- Use expo-router for navigation and follow the existing app/ folder.
- Keep data on the device for now (AsyncStorage). Backend comes later.
- Add packages with npx expo install, not npm install.
- Don't add native packages that don't run in Expo Go; ask first.
- Run npx tsc --noEmit after each step and fix the errors.
- When done, list the files you changed.

Two lines matter most. npx expo install picks the package version that matches your Expo SDK, and agents skip it all the time. The “no packages that don’t run in Expo Go” rule keeps you out of native builds until you actually need them.

Step 3: Test on the phone and iterate

While npx expo start is running, the app reloads on your phone as the agent edits files. The loop:

1. Try it on the phone and note what’s wrong.
2. Tell the agent precisely: “On the Add screen the keyboard covers the save button, on iPhone.”
3. If the red error screen shows up, copy the text verbatim into the agent. A screenshot works too; most agents can read images.
4. Commit every step that works.

Test on both iOS and Android. The same code behaves differently: safe-area insets, keyboard handling, the back button, shadows. With only one phone, use an Android emulator or (on a Mac) the iOS Simulator for the other platform.

Step 4: Backend with Supabase or Firebase

Once you want data shared across devices and user accounts, you need a backend. Don’t write your own server; pick a hosted one:

• Supabase: built on PostgreSQL. Database, auth, file storage and realtime updates. A good fit if you know SQL or want to learn it.
• Firebase: Google’s platform. Firestore document database, auth, messaging. Tightly integrated with the mobile ecosystem.

Have the agent build it layer by layer, not all at once:

We're moving to Supabase. For now, only do this:
1. Write a SQL file under supabase/migrations that creates habits and
   completions tables. Every row has a user_id.
2. Enable Row Level Security on both tables so a user can only read
   and write their own rows.
3. Don't change the app code yet. Show me the SQL; I'll apply it.

Don’t skip the RLS part. The Supabase key shipped inside a mobile app is public by design; what protects your data is the rules in the database, not the secrecy of that key. In Firebase, security rules play the same role.

Step 5: Auth

Email sign-in is the simplest; Supabase and Firebase both provide it. Sign in with Google and Sign in with Apple take more setup: redirect URIs, an app scheme and registration in each platform’s console.

One thing to know: under the App Store guidelines, if your app offers a third-party social login, Apple may expect Sign in with Apple or an equivalent privacy-focused option as well, with some exceptions. Check the current rules before you submit.

This is how I ask for auth:

Add email + password sign-in with Supabase Auth.
- If there's no session, redirect to the sign-in screen.
- Store the session with expo-secure-store.
- Put a sign-out button on the Settings screen.
- Error messages should be clear and in plain English.
Don't add Google or Apple sign-in yet.

Step 6: Push notifications

Push notifications eat more time than anything else on mobile. In Expo you start with expo-notifications:

npx expo install expo-notifications expo-device

What to know:

• Local notifications (“remind me every evening at 9 pm”) need no server and are by far the easiest. For a habit tracker they’re often all you need.
• Remote push means getting a push token, storing it on your server and sending from there. On iOS this needs an Apple Developer account and the push capability.
• Test notification behaviour on a real device. Simulator and Expo Go support for notifications can be limited and changes over time.

Ask the agent for local notifications first, see them work, then move to remote push.

Step 7: Builds and the stores

Expo Go is for development; the stores get a real app binary. Expo’s cloud service, EAS, builds it for you:

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android
eas build --platform ios

The big win of cloud builds is not having to set up Xcode and the Android SDK yourself. You can even produce the iOS build without a Mac.

Apple:

• A paid, yearly Apple Developer Program membership.
• An app record in App Store Connect with screenshots, a description, a privacy policy URL and the App Privacy data disclosure.
• Distribute through TestFlight to yourself and a few testers first, then submit for review.
• Rejections are normal. Common reasons: crashes, missing privacy text, thin “website wrapper” apps, and apps that let you create an account but not delete it.

Google:

• A one-time paid registration for the Google Play Console, plus identity verification.
• A store listing, the content rating questionnaire and the Data safety form.
• New personal developer accounts may have to run a closed test with a set number of testers for a set period before going to production; check the current rule in the console.

eas submit makes sending builds to both stores easier, but you still fill in the store forms yourself. Read them rather than delegating them to the agent; declaring what data your app collects is your responsibility.

Where agents struggle

This is the list of places where I’ve lost the most time vibe coding mobile apps.

Native build errors

Gradle, CocoaPods, Xcode versions, Android SDK levels. These errors are long, noisy and specific to the environment. The agent can’t see the Xcode on your machine; it guesses. What helps:

• Paste the full error output, not the first lines. The real cause is often near the bottom or buried in the middle.
• Use EAS Build where you can; the environment stays fixed.
• Don’t let the agent hand-edit the ios/ and android/ folders. In Expo those are usually generated from config, so lasting changes belong in app.json or a config plugin.

Signing and certificates

Certificates, provisioning profiles and bundle identifiers on iOS; a keystore on Android. Agents can give confident but wrong instructions here. Letting EAS manage credentials is the smoothest path. If you lose your Android upload key, shipping updates to the same app becomes a real headache, so back it up.

Version mismatches

The agent uses a package API from whenever it was trained; your project may have a different version. npx expo install --check lists mismatched packages. Telling the agent “check the version in package.json first, then write against that version’s docs” helps.

Testing on one platform only

The agent writes a layout that works on iOS and overflows on Android. See every feature on both.

Asking for everything at once

“Add auth, notifications and payments” leaves all three half done. One feature at a time, commit in between.

Security matters even more on mobile

Everything you put in a mobile app ends up on the user’s device, where it can be unpacked and read. So:

• Never put secrets in the app bundle. In Expo, environment variables starting with EXPO_PUBLIC_ are embedded in the bundle, which makes them public. Supabase’s service_role key, a payment provider’s secret key or an AI API key must never ship in the app; they belong on the server side, for example in an edge function.
• Keep secrets in a .env file and check that .env is in .gitignore.
• Don’t paste API keys into the chat. Tell the agent which environment variable to read, not the key itself.
• Test your database rules. Sign in with a second account and see whether you can read the first account’s data.
• Read the commands the agent runs, especially eas, git push, deletes and database commands, before you approve them.

Doing it with AgentVera

You can do all of the above in a plain terminal. On mobile projects I like running several agents side by side, and I do that in AgentVera:

• Separate agents in separate worktrees. For example, Claude Code works on the Supabase schema and edge functions in one git worktree while Codex builds screens in another. The Git panel shows each branch’s changes.
• A terminal in the grid. npx expo start stays open in one pane so you see Metro’s output next to the agents; that’s what the editor and terminal panel is for.
• Review before merging. Automatic code review has a second model check each agent turn; you should still read the diff yourself.
• The database. Add Supabase’s Postgres connection to the database manager to check the tables and rows the agent created.
• Token tracking. Long build logs inflate the context fast; token use is visible per pane.

AgentVera doesn’t build for your phone or submit to the stores; that part stays with Expo and the store consoles.

Quick checklist

• Expo project created by you, first commit in git
• First prompt lists screens, rules and the npx expo install requirement
• Every feature tested on a phone, on both platforms
• RLS in Supabase or security rules in Firebase enabled and tested
• No secret keys in the app bundle
• Android keystore backed up
• Privacy policy and store data disclosures ready

Wrapping up

Building a mobile app with AI is a realistic goal now, but it doesn’t end at “write me an app”. Start with Expo, watch every change on your phone with Expo Go, use a hosted backend, add features one at a time, and own the platform steps yourself: signing, store forms, review. For checking what the agent wrote, see AI code review; for running agents in parallel, see git worktrees for parallel agents.