Bolt to App Store: from Expo project to a reviewed iOS release

Short answer: Bolt uses Expo for mobile apps

When you ask Bolt for a mobile app from the first prompt, it creates an Expo-compatible React Native project. You can test with Expo Go, export or sync the source, build an iOS binary with Expo Application Services and upload it to TestFlight.

You still need the Apple Developer account, production testing, privacy work, App Store Connect listing and App Review. Generated code is only the beginning of the release path.

First determine whether the project is mobile-first or web-first

Choose the smallest sensible architecture

Prototype the hardest requirement first: payments, background work, camera, offline sync or complex gestures. Use the result to decide whether a rewrite is justified.

Put the source in a repository the business owns

Bolt supports ZIP export and GitHub integration. Use GitHub before production work so the product is not trapped in chat history or a contractor account.

• Create the repository under the company or founder’s GitHub account
• Protect the production branch
• Use branches and pull requests for release changes
• Review generated dependency and configuration changes
• Tag the exact source used for each store build
• Record Bolt, Expo and backend owners
• Confirm a clean clone installs outside the Bolt editor
• Keep environment and release instructions in the repository

Bolt automatically commits working changes and checks GitHub for updates. That convenience still needs human review.

Make the Expo project reproducible outside Bolt

Download or clone the source, then establish a repeatable local and EAS build before touching App Store Connect.

npm install
npx expo-doctor
eas login
eas init
eas build:configure
npx expo start

• Lock dependencies and commit the lockfile
• Resolve expo-doctor incompatibilities
• Separate development, preview and production configuration
• Keep secrets out of app config and client bundles
• Verify a clean checkout launches
• Record the Expo project owner and project ID
• Use a development build when native modules exceed Expo Go

Configure identifiers before the first production build

• Choose the iOS bundle identifier, for example com.company.product
• Set display name, slug, scheme, version and build number
• Choose the Expo organization and project ownership deliberately
• Commit app.json or app.config.js and eas.json
• Configure icons, splash assets, orientation and supported devices
• Do not reuse an identifier owned by a prototype or contractor
• Confirm an existing App Store listing uses the same identifier

Bolt’s guide warns that the Expo slug should be chosen before the first build. Bundle identity and signing continuity determine whether future binaries update the same listing.

Use Expo Go only for fast iteration

Expo Go is a convenient preview client, not the binary Apple will review. It does not include every native module or production entitlement.

• Use Expo Go for early interface and JavaScript iteration
• Create a development build for custom native dependencies
• Test permissions and deep links in the development build
• Test purchases in Apple sandbox and TestFlight
• Test signing and entitlements in the release candidate
• Never submit based only on a QR-code preview

Audit the Bolt Database or Supabase boundary

New Bolt projects commonly use Bolt Database; older and explicitly selected projects may use Supabase. The mobile client inherits whichever authentication, policies and server functions the preview uses.

• Identify Bolt Database versus Supabase
• Confirm database and organization ownership
• Review row-level security for every user-facing table
• Attempt cross-account reads and writes with two users
• Keep service-role operations inside server functions
• Store third-party credentials as server secrets
• Validate webhook signatures when JWT verification is disabled
• Export important data and document restores
• Use Bolt’s security audit, then manually verify the fixes

A Bolt Database can be claimed in Supabase when advanced control is needed. That is an operational choice, not a prerequisite for every launch.

Fix authentication callbacks for the installed app

• Set the production Site URL instead of leaving localhost
• Add permitted web, reset and mobile callback URLs
• Configure a stable custom scheme and universal links
• Test email confirmation and reset from the device mail client
• Test Google and Apple login in development and TestFlight builds
• Handle cancellation, denied consent and expired links
• Restore the intended screen after authentication
• Provide a reviewer account without unavailable second-factor steps
• Add in-app account deletion when users can create accounts

Add native capabilities through Expo deliberately

Expo supports notifications, camera, media, location, biometrics, files, haptics and custom native modules. Each capability changes permissions, configuration and testing.

• Install packages with npx expo install
• Add required config plugins
• Write human-readable iOS permission descriptions
• Request permission only when the feature is invoked
• Handle denial and restricted states
• Test on physical hardware where necessary
• Rebuild after native configuration changes
• Remove unused permissions and packages

Implement push notifications as a complete system

• Configure the Expo project ID and notifications plugin
• Create and protect Apple push credentials
• Request consent at a meaningful moment
• Store tokens against the correct user and installation
• Remove expired tokens
• Send from a protected server function
• Handle foreground, background and terminated states
• Route taps to a valid authenticated destination
• Track send, acceptance, open and destination success
• Test through a development build or TestFlight

Use App Store billing for digital goods

Stripe checkout can fit physical goods and real-world services. Digital features, content and subscriptions sold inside iOS generally need Apple in-app purchase.

• Classify every paid item
• Create stable App Store product identifiers
• Use StoreKit or an Expo-compatible service such as RevenueCat
• Keep entitlement state on a trusted server or purchase service
• Implement purchase, pending, cancellation and restore
• Handle renewal, refund, expiry and revocation
• Test with Apple sandbox and TestFlight
• Submit products and give reviewers a complete path

Bolt’s Expo guide points to RevenueCat for subscriptions. The generated paywall still needs correct products and entitlement operations.

Prepare privacy and deletion from production behavior

• Inventory data collected by Bolt/Expo code, database, analytics and SDKs
• Map each data type to purpose, sharing, retention and deletion
• Publish a privacy policy and accessible support page
• Align App Store privacy labels with the installed build
• Explain camera, photos, location, contacts and notifications
• Provide in-app account deletion
• Delete or anonymize connected database, storage and provider records
• Remove development telemetry and test credentials

Build and upload the production IPA with EAS

Use an explicit production profile instead of treating the first successful cloud build as the release candidate.

eas build --platform ios --profile production
eas submit --platform ios

• Confirm the intended Expo and Apple teams
• Review certificate and provisioning-profile ownership
• Set production environment variables
• Increment the build number
• Verify plugins and entitlements in build logs
• Keep the EAS build URL and source commit
• Use --auto-submit only after understanding the profile

EAS Submit uploads the IPA to App Store Connect; it does not complete metadata or submit the product for App Review.

Use TestFlight as the real release gate

• Install the processed App Store Connect build
• Test cold start, resume, upgrade and session restoration
• Test all authentication and deep-link paths
• Test permissions on a clean device
• Test purchases, restore and account switching
• Test slow network, offline behavior and backend failures
• Verify analytics and crash reporting identify the build
• Check supported iPhones and iPads
• Give an external tester the app without Bolt context
• Run the reviewer journey with a clean account

Complete the App Store Connect listing

• App name, subtitle, description and keyword field
• Categories and age rating
• Pricing, countries and availability
• Support, privacy and marketing URLs
• App privacy disclosures
• Export compliance and content rights
• Phone and tablet screenshots
• Review contact and demo credentials
• Notes for permissions, purchases and non-obvious features
• Manual, automatic or phased release choice

Store metadata should describe the tested product, not repeat the original Bolt prompt.

Submit with operational reviewer notes

• Explain the core outcome in one paragraph
• Provide exact steps through the main journey
• Give a stable reviewer account and role
• Explain physical versus digital payments
• Point to account deletion
• Describe each sensitive permission
• Explain background, notifications or user-generated content
• Provide a responsive technical contact

Plan how updates leave Bolt and reach users

1. Create or review the change in a branch.
2. Merge approved source to the release branch.
3. Run automated checks and expo-doctor.
4. Build the EAS profile from a known commit.
5. Test the processed TestFlight build.
6. Submit or phase the release.
7. Monitor stability and critical journeys.

Over-the-air updates can be useful when compatible with the installed native runtime, but they are not a way to bypass App Review or materially replace the reviewed product.

Common Bolt-to-App-Store failure modes

What App Release Ops can own

Send these materials for a useful scope

• Bolt project and whether it began as mobile or web
• Business-owned GitHub repository
• Expo account, project and SDK version
• App and EAS configuration files
• Latest EAS build or error logs
• Bolt Database or Supabase ownership
• User roles and reviewer account
• Payment model and digital entitlements
• Native features, permissions and integrations
• Apple Developer status and any rejection

Official implementation references

• Bolt: Expo for mobile apps
• Bolt: GitHub for version control
• Bolt: Supabase and database ownership
• Bolt: database security audit
• Expo: submit to the App Store with EAS
• Expo: deep links and schemes
• Expo: push notifications
• Apple App Review Guidelines

Related release paths

• Apple App Store publishing service
• Mobile app creation service
• Best mobile app builder comparison
• Production readiness audit
• React vs React Native architecture guide
• Push notifications guide
• Store monetization setup