Step-by-step on wiring a Bolt.new-generated Expo/React Native app to a real backend like Supabase, so your iOS prototype has authentication and a database.
A front-end-only prototype looks great in a demo but falls over the moment you need users, data persistence, or login. Most real iOS apps need a backend.
Bolt.new generates the app code, and it can scaffold integrations to services like Supabase — an open-source backend offering a Postgres database, authentication, and APIs.
This guide focuses on the Expo/React Native path, since that's how a Bolt.new project realistically reaches iOS.
Remember the boundary: Bolt.new writes the client code that talks to Supabase, but it does not compile your native iOS app. That still happens later via Expo/EAS and Xcode.
Before prompting, sketch your tables and relationships. Even a rough model — users, items, and a join table — saves you from messy regenerations later.
Decide what needs authentication. If users sign in, you'll want Supabase Auth and row-level security so people only see their own data.
Write this down in plain language. You'll feed it to both Bolt.new and Supabase, so clarity now pays off twice.
Keep the first version small. A focused schema is easier to wire, test on a device, and expand once it works.
Sign in to Supabase and create a new project. You'll get a project URL and API keys you'll use to connect your client.
Create your tables using the Supabase dashboard or SQL editor. Match the data model you sketched in Step 1.
If you need login, enable the auth providers you want. Email and password is the simplest starting point for a prototype.
Turn on row-level security and add policies for any table holding user data. Skipping this is one of the most common security mistakes in AI-generated apps.
Back in Bolt.new, ask it to wire your Expo/React Native app to Supabase. Be specific: 'Add the Supabase client to this Expo app and create a sign-in screen using Supabase Auth.'
Provide the shape of your data so generated queries match your tables. The closer your prompt is to reality, the less rework you'll do.
The AI will typically install the Supabase client library and create a configuration file plus some data-access code.
Review what it generates. Confirm it uses the official Supabase client and that auth and queries are structured the way you expect.
Your app needs the Supabase project URL and the public anon key to connect. These go into your client configuration.
Use environment variables rather than hardcoding secrets into source files. Expo supports environment configuration for exactly this reason.
Never put service-role keys or other privileged secrets in client code. The anon key plus proper row-level security is the correct client-side pattern.
Double-check that nothing sensitive is committed to a public repository. AI scaffolding sometimes drops example values directly into files.
Use Bolt.new's live preview to do a first smoke test of sign-in and basic data reads. This catches obvious wiring errors fast.
Try creating a record and reading it back. Confirm the data actually lands in your Supabase tables via the dashboard.
Watch for permission errors. If reads or writes fail, it's usually a row-level security policy that's too strict or missing.
Keep in mind the preview runs in a browser environment. It's a useful early check, but real iOS behavior must be verified on a device.
Export the project, install dependencies locally, and run it through Expo. Preview it on your iPhone using Expo Go or a development build.
Network behavior and auth flows can differ on device versus browser, so test sign-in, token persistence, and data loading on real iOS.
If you use OAuth providers, redirect handling often needs device-specific configuration. Test those flows carefully on iOS.
This device verification step is essential. A working browser preview does not guarantee a working iOS experience.
Once the integration works, the road to the App Store is the standard Expo route. Configure EAS Build to produce an iOS binary.
Move your Supabase keys into your build's environment configuration so production builds point at the right project.
Review Supabase's security advisors and your row-level security policies before going live. A prototype's loose rules are not production-safe.
Finally, submit through App Store Connect and TestFlight. As always, Bolt.new and Supabase got you the app and backend, but Apple's pipeline ships it.
If sign-in succeeds but data never appears, suspect row-level security first. A policy that's missing or scoped to the wrong user column will silently return empty results.
If the client can't reach Supabase at all, recheck the project URL and anon key. A typo or a stale value from an old project is a frequent culprit.
If the integration works in the Bolt.new preview but breaks on device, look at environment variables. Values that resolve in the browser sandbox may not be wired into the native build the same way.
When auth tokens don't persist between launches, confirm the Supabase client is configured with appropriate storage for React Native. The defaults tuned for the web don't always carry over to a mobile runtime.
Work through these one at a time and re-test after each change. Chasing several theories at once makes it hard to tell which fix actually mattered.
Security is the part of a backend that AI scaffolding handles least reliably, so treat it as your responsibility rather than the generator's.
The core mental model for Supabase is simple: the anon key is public, and row-level security is what actually protects your data. Without policies, an enabled anon key can expose more than you intend.
Start by enabling row-level security on every table that holds user data, then add explicit policies for reads and writes. A common pattern is to allow a user to access only rows where the user identifier matches their authenticated session.
Test your policies with a real authenticated session, not just from the dashboard. It's easy to write a policy that looks correct but is either too permissive or too strict in practice.
Finally, run Supabase's built-in security advisors before you ship. They flag tables left unprotected and other common gaps that are easy to miss in a fast-moving prototype.
Not everything belongs in the client. As your prototype matures, some operations need to run where users can't tamper with them.
Anything involving privileged keys, trusted business rules, or third-party secrets should run server-side rather than in your React Native app. The client should never hold a service-role key.
Supabase offers server-side options, including database functions and edge functions, for exactly these cases. Move sensitive logic there instead of trying to enforce it from the app.
Keep the client focused on presentation and on calls that are safe to expose. This separation keeps your app simpler and your data safer.
You don't need all of this on day one. But knowing where the line sits helps you avoid baking insecure shortcuts into the prototype that are painful to unwind later.
Bolt.new writes the client-side code that connects to a backend like Supabase. You still create and configure the Supabase project, tables, and security policies yourself.
The public anon key is meant for client use when row-level security is enabled. Never embed service-role or other privileged keys in client code.
Usually because row-level security is on but the policies are missing or too strict. Add policies that allow the intended access for authenticated users.
You can test logic in the Bolt.new preview and on a device via Expo Go. Final iOS builds and submission still involve Expo/EAS and Xcode/App Store Connect.
No. It remains an Expo/React Native app. Swift is not involved; you ship it through the React Native pipeline.