Bolt App Rejected Under Guideline 5.6: What to Change

Key takeaways

A Bolt web project in an app shell changes whenever you click Update in the Publish menu – features that go live after approval are exactly what Guidelines 5.6 and 2.3.1 describe.
Common Bolt triggers: a Site URL still on localhost:3000, Google SSO blocked in WebViews or stuck in Google's Testing status, private site visibility, exhausted free hosting and Stripe checkout for digital features.
Expo apps built with Bolt are reviewed as real binaries, but features switched on later through Bolt Database or Supabase records can still look hidden.
Fix the cause, give App Review full access, describe every feature and add native value – WebViewGold, our team's website-to-app product, wraps the published bolt.new site in a real native app.

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.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 5.6 - Developer Code of Conduct

We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process.

Paraphrased example – the exact wording in your message may differ.

Bolt app rejected under Guideline 5.6 – the short version

A Bolt app rejected under Guideline 5.6 has been flagged for conduct: App Review believes the app concealed features or behaved differently during review. With bolt.new projects the culprits are usually mechanical – changes pushed live with the Update button, authentication redirects that fail inside the app, a site the reviewer couldn't open or a paywall that breaks the payment rules. Fix the mechanics, document every feature and reply with test steps.

The wording developers reported in 2026 says Apple found "a pattern of unusual behavior" and that the app "contains features that appear to have been intentionally hidden during the review process", often without naming a screen. Two facts put that into perspective:

Building with Bolt isn't the issue. When Apple blocked updates of vibe-coding tool apps such as Replit and Vibecode in March 2026, it cited Guideline 2.5.2 for apps that generate and run code inside their own iOS app (9to5Mac). An app you built with Bolt and submit under your own name goes through normal review.
Similarity gets noticed. Apple rejected more than 371,000 submissions in 2025 for copying other apps, spam or misleading users, and says machine learning helps it analyze app similarity.

The general mechanics are in our pillar article on AI-built apps and 5.6 and the WebView 5.6 guide. What follows is the Bolt-specific part.

Wrapped bolt.new site or Expo build: where the 5.6 risk sits

Bolt produces two kinds of apps, and they carry different risks:

	Web project in a native shell	Expo (React Native) project
Route to the App Store	A wrapper loads your published site on bolt.host, a custom domain or Netlify	You download the code and build with EAS, for example `eas build --platform ios --auto-submit`
Changes without review	Everything you publish with Update	Data and server logic in Bolt Database or Supabase
Typical 5.6 trigger	Features published after approval; flows that work in a browser but not in the app	Features enabled later through database flags or plan fields
Other guidelines in play	4.2, 4.8, 3.1.1	2.1, 4.3, 3.1.1

Bolt's Expo documentation says mobile updates mean rebuilding and resubmitting. If you add over-the-air updates later, keep them for fixes; new functionality goes to review with a new version.

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.

Free consultation call Book our service →

Six bolt.new mechanics behind hidden-feature flags

1. The Update button

After the first publish, Bolt applies changes to the live site only when you click Update in the Publish menu. That button is your release gate: every Update during review, or a new feature right after approval, changes the app App Review saw.

2. A site the reviewer can't open

Paid plans can publish a site as Private, visible only to your team and invited people – a wrapper pointing there shows App Review a wall. On the Free plan, sites stop serving content once the monthly bandwidth or request limit is reached and stay offline until it resets.

3. Redirects that end on localhost

Bolt projects start with localhost:3000 as the Site URL, which Bolt's docs say "does not work for live applications". Bolt usually updates it at publish time, but not always, especially with several domains. Supabase only redirects to URLs on the URI allow list, so confirmation and reset links can land on the wrong host – and sign-up silently fails for the reviewer.

4. Google SSO in the wrong place

Bolt's Google sign-in uses your own Google Cloud OAuth client with a Supabase /auth/v1/callback redirect. Bolt's docs warn that "Google's OAuth flow blocks iframes", and Google blocks embedded WebViews the same way. New OAuth apps also start in Testing status, which limits sign-in to listed test users. A reviewer who can't sign in sees none of your features.

5. Stripe for digital features

Bolt's Stripe integration handles one-time payments and subscriptions through Supabase edge functions. Selling digital features with it inside an iOS app conflicts with Guideline 3.1.1 – and hiding the checkout from reviewers turns a payments problem into a 5.6 problem. See 3.1.1 for WebView apps.

6. The badge and the generated look

Free-plan sites carry a Made in Bolt badge until you republish on a paid plan. Third-party branding blurs who stands behind the app (5.6.2), and default layouts, stock copy and invented testimonials make it resemble many others – the territory of Guideline 4.3.

Where to look in Bolt before you reply

Place	What to check	Red flag
Publish menu	Visibility, domain, time of the last Update	Private site; an Update after you submitted
Database → Authentication → Advanced	Site URL and URI allow list	localhost, a preview host, a missing custom domain
Database → User Management	The review account in the live database	Account missing, unconfirmed or created elsewhere
Google Cloud Console → Google Auth Platform → Audience	Publishing status of the OAuth app	Still in Testing
Database → Security, project security audit	Who can see and change which data	Rules that hide tables from regular users
Stripe settings	Live or test keys, which products are digital	Digital products sold inside the iOS app
Settings → Cloud	Hosting usage this month	Limits reached while the app was in review
`app.json` and build settings (Expo)	Which backend the store build talks to	A development database in the submitted binary

Then install the rejected build from TestFlight on an iPhone and an iPad and repeat the reviewer's path with a fresh account: sign-up, confirmation, sign-in, password reset, purchase. Whatever fails there is your most likely trigger – and if nothing does, appsubmitter.io can run the audit with you before you answer.

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.

Discover WebViewGold Let us submit your WebViewGold app

A fix plan for bolt.new projects

Freeze features. No Update with new functionality until the next version is approved; content and fixes can go out.
Publish the review target publicly on your production domain. A custom domain (Pro) beats the random bolt.host name Bolt assigns at first publish.
Repair redirects. Site URL on the production domain; every domain, reset route and the app's deep-link scheme on the URI allow list.
Prepare the review account: email and password, confirmed in advance, with sample data. Bolt's email templates can send a six-digit code instead of a link, which works better inside an app if your sign-up screen accepts it.
Fix sign-in. Publish the Google OAuth app and keep Google out of the embedded view: native code with ASWebAuthenticationSession or Google's Sign-In SDK, or Google on the website and email plus Sign in with Apple in the app. A Safari handoff satisfies Google, but Apple calls it a poor experience under Guideline 4. Bolt's settings offer email and Google; Apple needs Supabase's Apple provider or, in Expo, expo-apple-authentication.
One purchase path: In-App Purchase for digital features, Stripe for physical goods and services – identical for every account.
Add account deletion through a server function: deleting a Supabase auth user needs the service role key, which must never reach the browser.
Clean up trust signals: badge, invented testimonials, unprovable claims, and custom "rate us" pop-ups, which 5.6.1 disallows – in a WebViewGold app, your web code can trigger Apple's native rating dialog instead.
Verify and document: run Bolt's security audit, rebuild, test from TestFlight and describe every feature in the Notes for Review – our Bolt 2.3.1 article has a worked example.

Turning the Bolt site into an app App Review can trust

A shell that only loads your bolt.host site invites Guideline 4.2, and when its content keeps changing, 5.6 as well. WebViewGold, the website-to-app product developed by our team, turns the published Bolt site into a native Xcode project – its documentation names Bolt among the supported builders. Native navigation, push via OneSignal, Firebase or Pushwoosh, an offline fallback, Face ID re-login, scanners, universal links, StoreKit purchases and Apple's native rating dialog give the reviewer an app instead of a website in a frame. A custom user agent lets the Bolt site adapt its layout to the app – never its feature set. It's a one-time purchase you publish in your own account, and no tool can promise an approval.

If you went the Expo route, the native side already exists; spend the effort on a working review account (2.1), a design of your own (4.3) and In-App Purchase through RevenueCat, which Bolt's docs point to. Our guides to converting Bolt to iOS and converting Bolt to Android compare both routes in detail.

Answering App Review after a Bolt 5.6 rejection

Reply in App Store Connect after the new build is uploaded: what you found, what you changed in Bolt – Site URL, visibility, sign-in, payments – the review account and step-by-step paths to each feature, plus a screen recording. If the letter names nothing, ask which flow raised the concern or request a 30-minute App Review appointment. Appeal to the App Review Board only if the app really hid nothing.

Don't resubmit the same build, toggle the site to Private while review runs, show reviewers a different flow based on the user agent or move the app to a new developer account – the last one adds an identity question under 5.6.2 to the original problem.

appsubmitter.io handles this for teams who would rather keep building: AI-powered pre-submission checks plus an App Specialist's review, precise Notes for Review, submission from your own developer account and the full correspondence with App Review. Code changes aren't included and are quoted upfront. Book the iOS service or start with a free consultation call.

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 your feedback on [App name], version [x.y] (build [number]). The app's web content is built with Bolt (bolt.new) and published at [domain]. We have gone through every flow with Guidelines 5.6 and 2.3.1 in mind.

Changes in this submission:
1. [Our authentication redirect still pointed to a development address, so email confirmation failed inside the app. Site URL and redirect list now point to [domain].]
2. [Google sign-in could not be completed inside the app. The app now offers email and password plus Sign in with Apple; the review account below uses email and password.]
3. [A subscription screen used a web checkout. Digital features are now sold through In-App Purchase only.]
4. New features are published only together with a new app version that describes them in the Notes for Review.

Review account: [email] / [password] (confirmed, with sample data)

Where to find each feature:
- [Feature 1]: [screen] – [steps]
- [Feature 2]: [screen] – [steps]

A screen recording of these flows is attached. If a specific screen raised the concern, please let us know and we will address it right away.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

No Update with new functionality went live between submission and approval.
The review target is published publicly on your production domain, with hosting headroom left for the month.
Site URL and URI allow list point to the production domain and include reset routes and the app's deep-link scheme.
The review account exists in the live database, is confirmed and signs in with email and password inside the app.
The Google OAuth app is published, and Google sign-in never runs inside the embedded web view.
Sign in with Apple is offered wherever Google login appears.
Digital features use In-App Purchase; Stripe only covers physical goods and services, identically for every account.
Account deletion works in the app through a server function.
The Made in Bolt badge, invented testimonials and custom rating pop-ups are gone.
The Notes for Review describe every feature with its location and test steps.

Frequently asked questions

Why was my Bolt app rejected under Guideline 5.6?

App Review saw a pattern it links to hidden features, usually caused by how the bolt.new project is published rather than by intent: features released with Update after review, sign-up links that redirect to localhost, Google sign-in that fails inside the app, a private or over-quota site, or a web paywall for digital features. Find the cause with the checks above, fix it and reply with test steps.

Can I keep clicking Update in Bolt after my app is approved?

Yes, for content, data and bug fixes – that is normal for an app built on web content. New functionality should reach users together with a new app version whose Notes for Review describe it, so the reviewed app and the live app stay the same. Treat the Update button as a release decision rather than a save button.

Should I remove the Made in Bolt badge before submitting?

Yes. The badge appears on Free-plan previews and published sites and disappears on a paid plan after you republish. Inside an app it shows third-party branding the reviewer may not connect to you, and Guideline 5.6.2 asks for an accurate picture of who stands behind the app. Replace generated testimonials and stock claims at the same time.

Google sign-in works on my bolt.host site but not in the app. Why?

Google blocks OAuth inside embedded WebViews, just as Bolt's docs note it blocks iframes in the preview. Your published site runs in a full browser; the app's web view doesn't. Use native code with ASWebAuthenticationSession or the Google Sign-In SDK, or offer email and password plus Sign in with Apple in the app – and make sure your Google OAuth app is no longer in Testing status.

Is an Expo app from Bolt safe from 5.6 rejections?

Safer, not safe. The binary App Review tests is the binary users get, and Bolt's docs say mobile updates mean rebuilding and resubmitting. But features unlocked later through Supabase or Bolt Database flags, paid tiers that bypass In-App Purchase or a review account without full access still look hidden. Apply the same release discipline as for a wrapped web project.

What does WebViewGold change for a wrapped Bolt app?

It turns the published bolt.new site into a native Xcode or Android Studio project with push, an offline screen, Face ID, scanners, universal links, StoreKit purchases and Apple's native rating dialog – the native value a thin shell lacks. WebViewGold is built by our team; it can't promise an approval, and release discipline in Bolt stays with you.

Sources and further reading

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.

Bolt App Rejected Under Guideline 5.6: Clearing a Hidden-Feature Flag on a bolt.new Project