Glideep
Glide
Shopify
Lovable
Base44
Bubble → App Store & Google PlayYour Bubble app, shipped to both stores.
Bubble builds serious web applications. It does not publish to the App Store, and a Bubble app has two things working against it in review that a lighter site does not: weight, and a responsive engine that has to be configured rather than assumed.
What goes wrong with Bubble apps in review
Two things, and the first one is not the guideline everybody talks about.
Start with the one nobody warns you about. Bubble's responsive engine is something you configure, not something you get. Plenty of Bubble apps — especially anything built before the new engine, or built on a desktop and never opened on a phone — have fixed-width groups and elements that simply do not reflow.
In a browser that is a shrug; the user zooms out. Inside a full-screen app on a 390px phone it is a broken product, and a reviewer will treat it as one. Fix your responsive layout in Bubble before you wrap it. Open your live URL on an actual phone first. If it looks wrong there, it will look wrong in the app, because it is the same app.
The same Bubble app. Glideep loads your live URL faithfully, so whatever the left phone shows in a browser is what ships in the app.
Then the familiar one. Wrap the app as-is with nothing else and a reviewer sees a responsive web page in a WebView, which is guideline 4.2, Minimum Functionality:
Your app should include features, content, and UI that elevate it beyond a repackaged website.
Bubble apps also carry real weight — the engine, your plugins, your workflows. A slow first paint inside an app reads worse than the same wait in a browser, because a browser shows its own chrome while a blank app shows nothing. A branded splash screen and offline handling matter more here than on a lighter platform.
Specifically, your app is a web page bundled in an iOS app and does not include native iOS functionality or content.
We encourage you to review your app concept and incorporate different iOS features and technologies to provide a more robust user experience.
The same Bubble app, submitted two ways
Nothing changes in your Bubble editor. What changes is the shell around it, and the responsive pass you do first.
- Desktop-width groups that never reflow on a phone
- Blank screen for several seconds while the app boots
- Opens straight into the web page, full screen
- No notifications — nothing brings the user back
- Login is the same web form as the browser
- External checkout for in-app content — a second rejection
The first two are a poor-experience finding, the rest are 4.2. You can collect both in one submission.
- Responsive layout fixed in Bubble first, verified on a real phone
- Branded splash screen covering the boot, offline handling after
- A native home screen instead of opening into the web view
- Bottom tab bar and side drawer for navigation
- Push notifications through OneSignal
- Face ID / fingerprint lock and native Google and Apple sign-in
- Subscriptions through StoreKit and Google Play Billing
On Bubble the splash screen is doing more work than it looks. It turns a blank few seconds into a deliberate load, which is the difference between “slow app” and “broken app”.
Bubble to TestFlight, start to finish
Five steps. The first one is not optional, and it happens in Bubble rather than in Glideep.
Fix your responsive layout in Bubble
Open your live app on a real phone, not the editor preview. Walk the flows you expect people to use. Anything with a fixed width, anything you have to scroll sideways to read, anything overlapping — fix it in Bubble now.
This is genuinely the step that decides whether the app feels finished, and it is the one people skip because the app “works fine on my laptop”. Glideep wraps your live URL faithfully; it cannot reflow a layout that does not reflow.
Copy your live URL
Use the live address of your app, not the /version-test development URL. Wrapping the test version is an easy mistake and it ships your users a development build.
A custom domain works exactly the same way, and is worth having for deep links.
Paste it into Glideep
Choose Create new app, give it a name and paste the URL. No plugin to install in Bubble, no SDK, no workflow changes.
Your app appears with an editor beside a live preview, and you can scan a QR code to open the real thing on your phone before building anything.
Turn on what gets you past 4.2
Work through the editor tabs. On a Bubble app the splash screen and offline handling are doing more than usual, because of the boot time.
Build and submit
Building takes one to two minutes. No Mac and no Xcode — iOS builds run on cloud macOS machines and the signed IPA goes to TestFlight through the App Store Connect API.
The store accounts are yours: Apple Developer at $99 a year, Google Play at $25 once. Those go to Apple and Google, not to us — and the Apple account is usually the slowest part, so start it first.
Subscriptions inside a Bubble app
If you already charge through Stripe in Bubble, read this part carefully.
Most Bubble apps that charge do it with the Stripe plugin, and in a browser that is fine. Inside an iOS app it is not: anything a user unlocks inside the app has to go through Apple's billing. Keeping your Stripe flow untouched is one of the most common ways a Bubble app fails its second submission after passing the first.
- Apple StoreKit and Google Play Billing are wired into the native shell, not called from the WebView.
- RevenueCat covers both stores from one set of products and entitlements.
- Your Bubble workflows still run. Trigger the purchase from the app, then let RevenueCat's webhook tell your Bubble backend to flip the user's plan — the same field your Stripe flow was setting.
- Keep Stripe for the web. Browser users can carry on paying through Stripe; only the app has to use store billing.
- Money lands in your store accounts. Glideep never takes a cut of your revenue.
Or let our team submit it for you.
A Bubble app is usually somebody's business rather than a weekend project, and the cost of a rejected submission is a fortnight, not an afternoon.
For a one-off fee our team takes it from a working build to a live listing. We go through the responsive pass with you, QA on real devices, test the flows including purchases and notifications, prepare the store assets and handle the back-and-forth with review.
- Responsive review — we tell you what will break on a phone before you submit.
- QA on real devices — not just a simulator run.
- Flow testing — sign-in, purchases, notifications, deep links.
- Submission and review — including replying to the Resolution Center if it comes to that.
You keep building in Bubble
Shipping an app does not freeze your editor.
Bubble to app store, answered
Do I need Bubble's new responsive engine?
Not strictly, but you do need a layout that actually reflows to a phone. Apps still on the legacy engine with fixed-width groups are the ones that come back from review looking broken. Open your live URL on a real phone before you do anything else — that is the honest test.
Should I use my live URL or the version-test one?
Always live. The /version-test URL is your development branch, and wrapping it ships an unfinished build to your users. If you want a test app, build a second Glideep app pointing at the test URL and keep it off the stores.
My Bubble app is slow to load. Is that a rejection?
It can be, worded as a poor user experience rather than 4.2. A branded splash screen covering the boot and offline handling for key screens go a long way, but they are cosmetic — if your app takes ten seconds to become usable, fix that in Bubble too.
Can I trigger push notifications from a Bubble workflow?
Yes. Push runs through OneSignal, which has a REST API, so a Bubble API workflow can send a notification when whatever matters in your app happens.
Can I keep my Stripe plugin?
For browser users, yes. For anything a user unlocks inside the app, Apple and Google require their own billing and an external checkout is its own rejection. Most people keep Stripe on the web and add store billing for the app, with RevenueCat's webhook updating the same Bubble field either way.
What about Bubble's own native app options?
Some partners compile Bubble apps natively. That is a different trade-off: more native, and more to maintain and rebuild every time you change something. Glideep loads your live app, so your Bubble deploys reach users without another build. Which is better depends on whether you value native depth or shipping speed more.
Get your Bubble app onto the stores.
Start free, build a real app, and see it on your own phone before you pay anything.