Key takeaways
- A wrapped bolt.new site changes whenever you click Update in the Publish menu – an Update after submission can leave App Review testing a different app than your notes describe.
- Bolt commits every working change to GitHub automatically, so the repository is a complete changelog between your last approved build and this one.
- A Site URL left on localhost:3000 breaks confirmation and reset links, and every feature behind the sign-in becomes unreachable for the reviewer.
- Stripe test keys, seed data and scaffolded admin pages are dormant features: finish and document them or remove them before you resubmit.
- WebViewGold, our team's website-to-app product, adds a version marker, fixed local screens and native modules you can list in the notes.
Our recommended solution
Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame
WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.
What the rejection typically looks like
Guideline 2.3.1 - Performance - Accurate Metadata
We were unable to access some of the features described in your app's metadata, and the app appears to include functionality that is not described in the Notes for Review.
Paraphrased example – the exact wording in your message may differ.
Bolt app rejected under Guideline 2.3.1: the short answer
A Bolt app rejected under Guideline 2.3.1 showed App Review something your notes didn't cover, or kept out of reach something your notes promised. With bolt.new projects that takes no bad intent: an Update after submission, a sign-up link that fails inside the app, a checkout still in test mode or an extra the agent generated is enough.
The sentence that matters most for Bolt projects comes from Guideline 2.3.1(a):
All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.
It sets two conditions – a specific description and real access – and a bolt.new project can miss either one. If your letter cites Guideline 5.6 as well, read our article on Bolt apps and the Developer Code of Conduct; our pillar on 2.3.1 for AI-built apps explains the feature-inventory method behind the steps below.
How does a Bolt update reach the iPhone?
As of October 2026, Bolt lets you publish with Bolt hosting, the Netlify integration or any other service. Bolt Cloud hosting – powered, according to Bolt, by platforms like Netlify and Supabase – gives the first publish a random .bolt.host address; custom domains need Pro. After that, Bolt's docs are explicit: changes you make to the project aren't applied to the published site until you click Update in the Publish menu.
For a wrapped app, that click is a release. The iOS app loads the live site, so the reviewer and every user get whatever the last Update shipped.
| What happened | Effect on App Review | What to record |
|---|---|---|
| Update clicked after you submitted | The reviewer may have tested a newer app than your notes describe | Time and content of every Update during the review |
| Update with a new feature right after approval | Users get functionality nobody reviewed | Hold new features for the next build |
| Site moved to another domain or host | A different start page or a redirect inside the app | Keep the start URL stable and mention any move in the notes |
| A host that deploys from your GitHub repository | Deploys you never triggered in Bolt | Check that host's deploy log as well |
Rejected or stuck? Talk to an App Specialist – for free.
Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.
Use the commits Bolt pushes to GitHub as your changelog
Bolt's GitHub integration is unusually thorough: every change that doesn't break the project becomes a commit, and Bolt checks GitHub every 30 seconds for changes made elsewhere. That gives you a full record of what the agent did. Use it.
- Tag what you submit. When you click Update for the build you're about to submit, tag the newest commit, for example
review/1.3-22. - Compare with the last approval. GitHub's compare view between
review/1.2-19andreview/1.3-22shows every file the agent touched. Group the changes into user-visible features and skip pure refactors. - Write the human summary. Automatic commits record what changed, not why. Your notes need one plain sentence per feature.
- Check the review window. A commit that reached the live site through an Update after you submitted means the reviewer may have tested a different app – list it in your reply.
Bolt's version history can also restore an earlier version of the project, which helps if you need to get back to the approved state while you prepare the next build.
When sign-in fails, every feature looks hidden
"Accessible for review" starts at the login. Bolt creates a Bolt Database automatically when a project needs one; Pro and Teams users can choose Supabase instead. Sign-in comes as email, with confirmation options, and Google SSO.
The classic trap is the Site URL. Bolt's docs say projects use localhost:3000 by default, which "does not work for live applications", and Supabase only redirects to allow-listed addresses. A confirmation or reset link that points to localhost dead-ends, the reviewer never gets past sign-up, and every feature behind the login is out of reach.
- Set the Site URL to the production domain and allow-list every domain plus your app's URL scheme.
- Give App Review a confirmed email-and-password account with sample data, plus separate logins for staff or admin roles, listed in the Notes field.
- Keep Google out of the web view. Bolt's own documentation points out that "Google's OAuth flow blocks iframes" – and Google treats an embedded WebView no differently. In the iOS app, run Google through
ASWebAuthenticationSessionor Google's Sign-In SDK, or drop it there and offer email and Sign in with Apple instead. A modified user agent is no workaround.
Offering Sign in with Apple next to Google also covers Guideline 4.8 – details in our 4.8 Login Services guide. For 2.3.1 the point is simpler: a reviewer who can't sign in can't verify a single feature in your notes.
Stripe test mode and other dormant leftovers
Bolt's Stripe integration pulls your products from the Stripe dashboard, processes one-time and recurring payments server-side in Supabase edge functions and handles the webhooks. Bolt tells you to build with test keys, which start with sk_test_. Sensible while you build – and a 2.3.1 problem if the submitted app still runs on them. The pricing page and upgrade buttons exist, no real purchase can complete, and once live keys go in after approval, a paid tier wakes up that App Review never saw working. That is a dormant feature in the literal sense.
Decide what the checkout is for on iOS. Digital features and subscriptions inside the app need In-App Purchase under Guideline 3.1.1; Stripe can stay for physical goods and services used outside the app. Whatever remains must run in live mode during review – or leave the app. The same logic applies to everything else the agent left behind:
| Leftover | Why it reads as hidden or dormant | What to do |
|---|---|---|
Checkout on sk_test_ keys | Paid features that can't complete now and activate later | Live mode for physical goods, In-App Purchase for digital access, or remove it |
| Seed data and demo users | Content and accounts that aren't part of the product | Delete them before the review build goes live |
| Admin or debug pages without links | Reachable functionality nobody described | Remove them, or protect and document them |
| "Coming soon" tabs and mock AI tools | Promised functionality that isn't there | Finish and describe them, or delete them |
| Unused edge functions and integrations | Server capabilities with no visible purpose | Remove or document them |
| "Made in Bolt" badge | Builder branding in an app you present as yours | Republish on a paid plan; it returns after a downgrade |
The fastest fix for most WebView rejections
WebViewGold: native features for your web app
Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:
- Push notificationsOneSignal or Firebase, for real, personal events
- Native offline screenNo browser error pages when the connection drops
- Native splash screenApp-like start instead of a loading web page
- Deep linksLinks open the right screen inside the app
- QR & barcode scannerDevice features the website alone can't offer
- In-app purchasesNative purchase flows where the store requires them
No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.
Expo build or wrapped site: where your Bolt features live
Write "mobile app" in your prompt and Bolt creates an Expo (React Native) project. To publish it, you download the code and use the EAS CLI locally – a command like eas build --platform ios --auto-submit builds the iOS app and sends it to TestFlight. That moves the 2.3.1 risk:
| Wrapped bolt.new site | Expo build from Bolt | |
|---|---|---|
| Where the screens live | On your server – every Update changes them | In the binary App Review tested |
| How a new feature reaches users | An Update in the Publish menu | A new build and a new submission |
| Typical 2.3.1 gap | Features published after submission, access failures | Screens switched on later by database values, undescribed backend features |
| What the notes must cover | The site's features plus the native modules | Every screen, plus what the backend can change |
This article doesn't cover over-the-air update services for Expo. Whatever you use, Guideline 2.5.2 rules out downloaded code "which introduces or changes features or functionality", so new features still go to App Review with notes.
Notes for Review for a bolt.new app: a worked example
Apple's guidance asks you to list the external services the app relies on, "for example, data providers, authentication services, payment processors, or AI services". For a Bolt app that usually means Supabase or Bolt Database, Stripe and any AI model the project calls. A block for a class-booking app:
Overview: [App name] lets members of our climbing gym book classes and manage class passes. The app shows our web app from book.example.com (built with Bolt, database on Supabase) inside a native iOS shell that adds push reminders, Face ID unlock and an offline screen.
Changes since version 1.2 (build 19): waitlists and class passes.
1. Waitlist – Classes, open any class marked Full, tap Join waitlist. The demo member is already on the waitlist for Thursday's class.
2. Class passes – Profile → Passes shows a 10-class pass with seven classes left. Passes are sold at the front desk and on our website for in-person classes only; nothing digital is sold in the app.
Sign-in: email and password, account confirmed. Staff role: [email protected] / [password]; Staff → Today lists all bookings.
External services: Supabase (database, authentication), Stripe in live mode for in-person class passes, OneSignal for push notifications.
Server content: class schedules change daily on our server. New functionality reaches the app only with new app versions.
Keep the Git tag of the reviewed build next to this text in your repository, so the next update starts from a known state. More examples are in our Notes for Review guide.
WebViewGold and appsubmitter.io for the resubmission
If your Bolt web app runs in Safari or Chrome, WebViewGold – the website-to-app product our own team develops – can turn it into a native app: a ready-made Xcode project in which Config.swift points to your production domain. Four of its features support a clean 2.3.1 record:
- Version marker. A custom user agent per device (
useragent_iphone,useragent_ipad) or the App Version Check API tells your Bolt front end which build is running, so a new feature can start with the build whose notes describe it. - Local HTML. Screens that should stay exactly as reviewed – the offline page, house rules, onboarding – can ship inside the bundle.
- Documented native features. Whatever you enable in the project – push through OneSignal, Firebase or Pushwoosh, Face ID, the QR and barcode scanner, StoreKit purchases with the Extended license – is fixed in the binary, so one line in the notes covers each.
- Apple's rating dialog replaces any web "rate us" pop-up the agent generated, which Guideline 5.6.1 disallows.
You buy it once, with no subscription. The project and the developer account stay yours, and no tool can promise an approval. For the full setup and the Expo route, see converting a Bolt app to iOS.
appsubmitter.io handles the submission side. After an AI-powered pre-submission check, an App Specialist goes through your repository's changes with you, writes precise Notes for Review and answers App Review on your behalf, from your own developer account. We also set up signing and CI/CD for a WebViewGold project or an Expo build. Any code changes get their own quote before work starts. Book our iOS submission service, or bring your Bolt project to a free consultation call first.
Template: how to reply to App Review
Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.
Hello App Review Team, Thank you for reviewing [App name], version [x.y] (build [number]), and for your note under Guideline 2.3.1. The app's web content is built with Bolt and published at [domain]. We compared every change since our last approved version (build [number]) using our repository history and found: 1. [Feature] went live through an update of our website after we submitted. It is now part of this version and described below. 2. Our sign-up confirmation link pointed to a development address, so parts of the app could not be reached. The redirect now points to [domain], and the review account below is confirmed. 3. A payment screen was still connected to Stripe test mode. [It now runs in live mode for in-person services only. / It has been removed; digital features use In-App Purchase.] 4. Unused pages from development ([e.g. /admin-preview]) have been removed. Features in this version and how to reach them: - [Feature 1]: [screen] – [steps] - [Feature 2]: [screen] – [steps] Accounts: - [Role 1]: [email] / [password] - [Role 2]: [email] / [password] We now publish new functionality only together with a new app version whose Notes for Review describe it. Best regards, [Your name] [Company]
Checklist before you resubmit
- The commit behind the submitted Update is tagged with the version and build number.
- No Update that adds functionality went live between submission and decision.
- The Site URL points to the production domain, and every domain plus the app's URL scheme is on the allow list.
- A confirmed email-and-password review account with sample data exists, plus one account per role in the Notes field.
- Google sign-in never runs inside the web view, and Sign in with Apple is offered wherever Google is.
- No checkout in the submitted app runs on sk_test_ keys; digital features use In-App Purchase.
- Seed data, demo users, unlinked admin pages and "coming soon" tabs are removed.
- The "Made in Bolt" badge is gone after a republish on a paid plan.
- For Expo builds, the notes list every screen and everything the backend can switch on.
- The Notes for Review describe every change since the last approved build with screen and test steps.
Frequently asked questions
Why was my Bolt app rejected under Guideline 2.3.1?
Do I need a new App Store version every time I click Update in Bolt?
How do I find out what changed since my last approved version?
Can a Stripe checkout in test mode cause a 2.3.1 rejection?
My Bolt app is an Expo project – can it still get a 2.3.1 rejection?
What does WebViewGold add to a wrapped Bolt app under review?
Recommended solution
From WebView rejection to approval: WebViewGold + appsubmitter.io
- 1 Build with WebViewGold Turn your website into native iOS and Android projects.
- 2 Add native value Push, offline screen, deep links or scanning in your main flow.
- 3 We submit it Our App Specialists submit and talk to the review team.
WebViewGold is made by our team (jocapps GmbH). It is a tool, not a guarantee – approval decisions are made by Apple and Google.
Sources and further reading
- Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
- Apple Developer – Provide information for a complete review
- Bolt Support – Publish your project to a live website
- Bolt Support – GitHub integration
- Bolt Support – Database: Authentication settings
- Bolt Support – Stripe for payments
- Bolt Support – Bolt Cloud hosting plans (Made in Bolt badge)
- Bolt Support – Expo for mobile apps
Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.