Bubble App Rejected Under Guideline 5.6: Find What the Reviewer Couldn't See and Resubmit

Bubble app rejected under Guideline 5.6: what Apple is telling you

A Bubble app rejected under Guideline 5.6 was flagged under Apple's Developer Code of Conduct: App Review believes the app didn't behave honestly during review. In Bubble apps, that almost always means the reviewer saw a smaller or different app than your users get. Find the part that was invisible, make it reachable, document it and reply. A new account or an unchanged resubmission won't solve it.

Developers who received 5.6 letters in 2026 report near-identical wording: Apple has identified "a pattern of unusual behavior" that is "commonly associated with fraudulent activity", and the app "contains features that appear to have been intentionally hidden during the review process". Which feature, the letter rarely says. Nor is this a niche problem: Apple rejected over 22,000 submissions for hidden or undocumented features in 2025 (Apple Newsroom, May 20, 2026).

The rule behind that wording is Guideline 2.3.1(a) of the App Store Review Guidelines, last updated June 8, 2026:

Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review.

Guideline 5.6 raises the stakes by tying such behavior to your membership in the Apple Developer Program. Neither guideline targets no-code. Bubble – the visual builder that Bubble Group has run from New York since 2012 – just makes reviewer-only behavior easy to build by accident. Our pillar article explains why AI-built and no-code apps get 5.6 flags; this one covers the Bubble mechanics.

How Bubble apps end up hiding features by accident

Conditions and privacy rules

Bubble decides what each user sees in two layers. Conditions on elements show or hide buttons, groups and whole sections. Privacy rules on each data type tell Bubble's server which records it may send to the browser at all. Both are good practice – and both can hand a brand-new review account an empty repeating group, a dashboard without numbers or a page whose main button never appears, because the account lacks a role, a paid flag or data of its own.

From the reviewer's chair, an app that only comes alive for the right role is indistinguishable from one that holds features back during review.

/version-test/ instead of live

Every Bubble app runs twice: the live version at appname.bubbleapps.io or your custom domain, and the development version at the same address plus /version-test/. Each has its own database. A wrapper or a review note that points at /version-test/ shows App Review your work in progress and your test data while users get the live app – a reviewer-only version by definition, even if nobody planned it.

Deploying to live while the build is in review

Bubble's manual calls deploying "instant for all practical purposes", and users who have the app open get a notification asking them to refresh. Deploy during review and the reviewer may hit that banner mid-test, or meet a different app on the next launch. Bubble's native builder behaves the same way for content: text, workflow and UI changes go live without a rebuild, and only native shell changes such as the icon, splash screen or plugins need a new build. Anything that reaches users like this was never reviewed.

Paywalls that behave differently in the app

The Bubble-made Stripe plugin puts a web checkout within a few clicks. If that checkout sells digital access and you hide it only while the app is in review – or switch it on afterwards – the inconsistency itself is what 5.6 describes. Bubble's native in-app purchases cover subscriptions only, which tempts some teams to keep one-time digital purchases out of sight. Pick one rule for every app user; our article on Guideline 3.1.1 for WebView apps explains when Apple requires In-App Purchase.

Screens that never finish loading

Pages that run many searches on page load can leave a reviewer staring at a spinner. In a Bubble forum thread from July 2025, a maker reported a rejection because the reviewer "couldn't get past loading screen"; a later resubmission went through. A feature behind an endless loading state is unreachable – and unreachable reads like hidden. Our article on Guideline 2.1 for WebView apps covers the completeness side.

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 →

Where to look in the Bubble editor: a reviewer-eyes audit

Before you change anything, open the app the way App Review does: a fresh install, the demo account from your review notes, no saved cookies, on an iPhone and an iPad. Note every screen that looks emptier than it does for a real customer. Then trace each gap back to its source in the editor:

For a screen-by-screen method that works for any wrapper, see how to fix a 5.6 rejection in a WebView app.

Five fixes that make a Bubble app reviewable again

1. One version for everyone. Point the app at the live version on your own domain and remove /version-test/ from every URL and note. Use device or app detection only to adapt layout – for example to hide the web footer – never to decide which features exist.
2. A review account that opens every door. Email and password, created in the live database, with the role, sample data and paid tier your customers have. Test it inside the app, not just in the browser. Apple's guidelines ask for "an active demo account or fully-featured demo mode" whenever an app has account-based features.
3. A deploy freeze for features. Keep deploying content and bug fixes, but hold new functionality back from live until a build whose review notes describe it has been approved. Give every deploy a short description, so your deployment history doubles as a change log.
4. One payment rule. Digital access sold in the app goes through In-App Purchase – StoreKit in a wrapper or Bubble's native subscriptions – or no app user sees a digital purchase at all. Physical goods and services can keep the Stripe plugin.
5. Faster first screens. Bubble's own workload guidance suggests loading only the data a page needs at first and deferring heavy lists until users ask for them. Add a native loading or offline state, so a slow connection never looks like an empty app.

Then document everything. Guideline 2.3.1(a) requires new features to be "described with specificity in the Notes for Review section of App Store Connect" – list each feature, where it lives and how to reach it with the demo account.

Wrapped web app or Bubble's native builder: make either one reviewable

If you wrap the Bubble web app

WebViewGold, the website-to-app solution made by our team, turns a web app that runs in Safari – Bubble apps included – into a native Xcode project. You enter your live custom domain in Config.swift, switch on the modules you need and publish in your own Apple Developer account. It is a one-time purchase.

Several modules answer 5.6 concerns directly. The native in-app rating dialog replaces web "rate us" pop-ups, which Guideline 5.6.1 rules out ("we will disallow custom review prompts"). Push via OneSignal, Firebase or Pushwoosh gives the reviewer a visible native feature – WebViewGold's push documentation even lists a dedicated bubble.io option. The native offline screen with a Reconnect button and the native loading indicator keep slow pages from looking broken, and StoreKit in-app purchases give digital goods a compliant path.

Sign-in needs one decision up front, because Google blocks OAuth in embedded WebViews. Either run Google's login natively – through ASWebAuthenticationSession or Google's Sign-In SDK, added to the WebViewGold Xcode project – or offer email and password plus Sign in with Apple in the app and keep the Google button on the website. WebViewGold detects Sign in with Apple pages and handles them automatically. No tool can promise an approval – conditions and privacy rules in your Bubble app are still yours to fix.

If you rebuilt it with Bubble's native mobile builder

Bubble's React Native builder, in public beta since June 9, 2025, produces real native screens, so the "repackaged website" question fades. The 5.6 logic doesn't: instant updates to text, workflows and UI reach users without review, exactly like a web deploy, so give them the same feature freeze. In-app purchases in the builder support subscriptions only, and a Bubble forum thread from April 2025 describes a native-beta app rejected twice for not having In-App Purchases.

The full setup for both routes is in our guide to converting a Bubble app to iOS; for Google Play, read Bubble to Android.

How to answer App Review – and what not to do

Reply in App Store Connect on the rejected submission. Replies hold up to 4,000 characters plus attachments – enough for a precise account and a short screen recording. Name what you checked in Bubble (conditions, privacy rules, the live database, the app URL, your deployment history), what you changed and how the reviewer reaches each feature with the demo account. If the letter doesn't say which feature looked hidden, ask politely for the screen concerned.

If you are sure App Review misread the app, you can appeal to the App Review Board – one appeal per rejected submission, with specific reasons – or book a 30-minute App Review appointment through Meet with Apple and talk it through.

• Don't resubmit the same build with a shorter description. The flag concerns behavior, and it doesn't fade on its own.
• Don't open a new developer account. Guideline 5.6.2 asks for accurate information about you and your business, and Apple terminated 193,000 developer accounts over fraud concerns in 2025.
• Don't switch conditions back after approval. A feature that reappears for users later is the bait-and-switch pattern behind nearly 59,000 app removals in 2025.
• Don't let an agency's account publish your app. If a freelancer or agency built your Bubble app, it still belongs in the content owner's account under Guideline 4.2.6.

This is where appsubmitter.io helps: an App Specialist checks your Bubble app with AI-powered pre-submission checks, writes precise review notes and handles the communication with App Review – always in your own developer account, with our team working as members of it. Code changes aren't included, but we quote them upfront if your app needs any. Start with a free consultation call or book the iOS service.

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 [build number]). We have reviewed the app against Guideline 5.6 and want every feature to be visible and documented.

The web part of the app is built with Bubble. Our review covered element conditions, data privacy rules, the database the app uses, the app's start URL and everything we deployed since our submission. In this build:

1. The app loads our live version at [https://yourdomain.com]. [It previously loaded our development version.]
2. The demo account below has the same role, data and subscription tier as a paying customer. [Previously, privacy rules showed it an empty dashboard.]
3. [We removed a condition that showed [feature] only to users with the [role] role.]
4. New features reach app users only together with a reviewed build.

Demo account: [email] / [password]

Features and where to find them:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]
- [Feature 3] – [screen] – [steps]

A screen recording of these flows is attached. If a specific screen raised the concern, we would be grateful for a pointer so we can address it directly.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The app and the review notes use the live version on your own domain – no /version-test/ URL anywhere.
• The demo account exists in the live database, signs in with email and password and has the role and paid tier of a real customer.
• Privacy rules return realistic sample data to the demo account, so no list or dashboard is empty.
• No element condition or workflow branches on device, user agent or URL parameters to change which features exist.
• Nothing with new functionality was deployed to live between submission and decision.
• Every deploy carries a description, so you can list what changed since the reviewed build.
• Digital purchases use In-App Purchase for all app users, or no app user sees a digital purchase; physical goods may use Stripe.
• Google sign-in never runs inside the WebView, and Sign in with Apple is offered wherever Google or Facebook login appears.
• Rating requests use Apple's native dialog; no web pop-up asks for stars.
• Core pages load quickly on a phone connection and show a native loading or offline state instead of a blank screen.
• The Notes for Review list each feature, where it lives and how to reach it.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.6 Developer Code of Conduct
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
• Bubble Manual – Custom domain and DNS (live and version-test URLs)
• Bubble Manual – Deploying a web app to live
• Bubble Manual – Protecting data with privacy rules
• Bubble Manual – Native mobile publishing FAQ (instant updates vs. new builds)
• Bubble Forum – App Store rejection: reviewer couldn't get past loading screen (July 2025)
• WebViewGold for iOS – push notifications documentation

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.