Building a Mobile App with AI: React Native and Expo with Codex, One Screen at a Time, Clerk Login with Supabase Progress, and a Mascot That Makes It a Product

A website opens from a link; a mobile app is installed. A site moves between pages; an app uses a bottom tab bar (home, settings, profile, account). If both use Supabase, accounts and data are shared, so web and mobile 'can sync and share with each other'. A website update is published at once; a mobile release goes through the App Store or Play Store and users have to update. Mobile is worth it when people use the product often: the app caches for speed, remembers preferences (Rajat's delivery-app examples - your saved address, your last restaurant) and can use device permissions. Screen sizes vary more on Android, and foldables add a new constraint. His aim is screens 'completely native to a mobile experience, rather than a web experience'; in the end-of-class Q&A, whether to go mobile or desktop first depends on where your users are.

Four ways to build: native (Swift and Xcode for Apple, Kotlin and Android Studio for Android - he would choose it for something like gaming, at the cost of two separate projects), React Native, Flutter, and web wrappers. Only React Native is taught: one codebase with the same business logic and screens produces both apps, though you still test on both. Fast Refresh shows UI changes live. In the web-to-mobile stack React Native replaces React, Expo is the development tooling ('the latest choice for building with React Native'), Expo Go previews on a real phone, and Supabase stays the backend so users and data carry over. Apple development needs a Mac for Xcode, but with Expo Go a Windows user can still test live on an iPhone, and the Android emulator runs on Mac or PC.

PromptQuest teaches better prompting: lessons of three questions, each with an answer and feedback, for people who already use AI. Five screens - Home, Lesson, Result, Login, Profile - are built one at a time, with accounts explained later. Home gets a bold Start Quest button and a journey path of completed and locked lessons; Lesson a question, three choices and an explanation; Result the number correct, experience points and a tip designed to 'bring them back to use our application tomorrow', plus a Home button. From Duolingo he borrows the prominent start button, the green highlight on correct answers, the explanation and the ticks on completed lessons; from his own AfterLit, the idea of a character. For beginners: collect inspiration from apps you use, then ask Claude Design or Codex to suggest a layout from it - after two or three tries 'you get the hang of how a mobile app looks'.

Rajat made the skill with Codex's skill-creator, shares it as a zip and keeps it current - for example by feeding it Apple's new 'liquid glass' guidelines so new apps follow them. It checks the operating system, Node, npm, whether a project exists, Xcode, Android Studio and its platforms, and a Java JDK (optional), and guides installation of anything missing. It is not tied to PromptQuest. In the demo the report came back with everything present except the actual Expo Go preview, which was pending.

Expo Go, from the Expo team, runs the app you are building on your own iPhone or Android phone as long as both devices share a Wi-Fi network. The agent's reply gives the terminal command; a QR code appears; scanning it opens the app. In the same terminal, i opens the iOS simulator and a the Android one, with Expo Go auto-installed there. Small UI changes appear immediately (sometimes after a reload). Simulators also let you try other devices - a Pro Max, an iPad, an older iOS - at the cost of heat.

The class poll picked the more specific Home prompt: 'Build me the home with the next lesson button. Keep it inactive until we add the lesson screen and help me to run a quick preview.' Then a placeholder Lesson screen with Start Quest linked to it and a back button ('you need to have a way for the user to go back'), then the real lesson from a pre-written course.json, then the Result screen. The Home button on Results is not just navigation: it tells the app the lesson is complete so the backend can mark it done and award XP. Result shown live: 2 of 3 correct, 20 XP, a tip and the next quest unlocked.

Rajat's generic fix prompt is specific: 'the start quest is not going to the next lesson screen, please have a look', never 'something went wrong, please fix it'. Adding Clerk broke the whole app - typical, he says: React Native absorbs UI changes, new text and new screens on its own, but a new service or package needs the server stopped and restarted. The next error was a React version mismatch because Clerk tried to use a web login; the agent fixed it, and then the missing API key had to be added.

Once the app is shared, everyone sees the same thing and the developer cannot tell who is using it. Poll: save lesson progress on this phone, or for the signed-in account? The class chose the account: saved locally, nobody else's progress is visible to you; saved to the account, the same user sees the same live progress on an iPhone and an Android phone. The jobs split: Clerk signs people in and creates accounts, Supabase saves the progress. Why Clerk: with Supabase's own auth, Google sign-in needs your Google client ID and secret and Apple its own client ID and key file; in development mode Clerk supplies those so nothing is configured until production. Firebase 'works fine' too. His rule (2:08): if you prefer to set everything up first, use Supabase login; if you want to validate the app before building out, use Clerk. Only two keys are needed - Clerk and Supabase. Clerk's free tier was given as the first 50,000 users, hedged 'I think so'.

Clerk is 'very AI-forward': it previews sign-in options and, per framework, gives a prompt to paste into your agent that reads Clerk's Expo guide, installs what it needs and builds sign-in and sign-up. On the phone the new account was created with an emailed OTP and appeared in the dashboard. The Profile prompt was read nearly verbatim: 'Build me the profile screen from my reference, enable the profile tab, show the Clerk's name and email ID, completed lessons, and give me a sign-out button.' Sign-out returns to login and stays there after the app is killed and reopened. In Supabase, Clerk (or Firebase) is added as a third-party auth provider with Clerk's domain, so Clerk's user ID is shared and Supabase stores progress per user.

Asked about cost, Rajat contrasts his past teams of four or five engineers building screens from a designer's UI with today's cost of the AI model - then adds the costs 'where nobody talks': $99 a year to Apple for the App Store and a one-time $25 to Google for Play. Review time: in 2015-2016 his fastest approval came the same day; with the flood of AI-built apps his AfterLit has been waiting more than a month, so he can only share a TestFlight link. A rejection example from his team: an app offering Google login must also offer Sign in with Apple. Test builds can be shared before approval as TestFlight (iPhone) and an APK file (Android), both on his resources page.

Rajat names his characters - AfterLit's has three states (sleepy, awake, always-on). Two routes to one: a paid platform with animated characters, or a free open-source character skill from GitHub. He made Pip in ChatGPT Images (Gemini would also work): an orange character to match the app, in three poses, saved as transparent PNGs so the agent can crop and place them. He keeps an agent.md file so that if he switches from Codex to Claude 'it shouldn't be like I need to re-explain everything', and asks Codex to read it and store the character rules there. The agent 'has its own interpretation' of the reference but gets close; after a second prompt a wrong answer shows an encouraging Pip. Small touches like this make it 'not look like some AI built the app'.

'What is one thing we can improve?' - tap targets, focus, and how screens look on smaller and larger devices, the mobile version of checking a website at different widths. The app went from text and buttons to a guided experience. Day two's plan: an onboarding screen with Pip, a generated splash screen, metrics with PostHog, feature flags, testing and release; TestFlight and APK test builds are on the resources page. Cody asked about sensors, GPS and the camera - not planned, but the app is a boilerplate and an agent can add a scanner or camera feature. Q&A: inspiration comes from daily-use apps (Swiggy's top tabs switching the bottom tab bar); Kotlin and Gradle problems can now be handed to the AI, with documentation as a fallback; choose UI by borrowing (Duolingo for the path, AfterLit for character) and following good app makers on LinkedIn; mobile or desktop depends on your users.