Glideep
Bubble
Shopify
Lovable
Base44
Glide → App Store & Google PlayYour Glide app, on the real app stores.
A Glide app already looks like an app — that is the point of Glide. What it is not is an App Store listing. Glideep turns it into signed iOS and Android builds you own, on any Glide plan.
Glide apps start closer to approval than most
Worth saying plainly, because most guides on this topic exaggerate the problem to sell the solution.
Glide builds mobile-first interfaces. Tab bars, list views, detail screens, forms — the UI is already shaped like an app rather than a website squeezed onto a phone. Compared with wrapping a Bubble app or a marketing site, you are starting from a much better place, and it is worth being straight about that.
But guideline 4.2, Minimum Functionality is not about whether an app looks app-like. It asks whether the app does anything a browser tab could not:
Your app should include features, content, and UI that elevate it beyond a repackaged website.
A Glide app run as a plain wrapper still has no push notifications, no biometric lock, no native sign-in and no offline behaviour. It looks the part and behaves like a web page, and reviewers do open apps and try things.
There is a second thing specific to Glide. Because the UI is generated from your data, a small table produces a thin app — three lists and a detail view. That is a fine internal tool and a weak public App Store listing. If your Glide app is genuinely a tool for one team, read the note on internal distribution below before you submit to the public store.
The practical upshot: you need fewer native features than a Bubble or Lovable app to clear 4.2, but you do not need zero.
Specifically, your app does not include native iOS functionality beyond what is available on your website.
We encourage you to review your app concept and incorporate different iOS features and technologies to provide a more robust user experience.
The same Glide app, submitted two ways
Nothing changes in Glide. What changes is the shell around it.
- Looks like an app, does nothing an app does
- No notifications — a row changes and nobody knows
- Login is Glide's web sign-in, same as the browser
- Three lists and a detail view — thin for a public listing
- Nothing available without a connection
Looking app-like is not the test. Doing something a browser cannot is.
- Push notifications when a row is added, assigned or updated
- Face ID / fingerprint lock on open
- Native Google and Apple sign-in
- A native home screen above your Glide views
- Branded splash, onboarding slides, offline handling
- StoreKit and Play Billing if you charge for access
Because the UI is already mobile-first, push and biometrics usually do enough on their own. You are topping up, not rebuilding.
Glide to TestFlight, start to finish
Four steps, and on Glide the third one is shorter than on most platforms.
Publish in Glide and copy the URL
Publish your app in Glide and copy its address — the *.glide.page URL, or your custom domain if you have connected one.
That is all Glideep needs. Nothing is exported, your data stays in Glide, and your app keeps working in the browser exactly as it does now.
Paste it into Glideep
Choose Create new app, give it a name and paste the URL. There is nothing to install on the Glide side and no plan upgrade required — this works the same on Glide's free tier as on any paid one.
Scan the QR code to open the real thing on your phone before you build anything.
Add what Glide cannot
Your navigation and layout already come from Glide, so leave those alone — a second bottom bar under Glide's own would look wrong. Concentrate on the capabilities a web app simply does not have.
Glide already draws a tab bar. Switching ours on gives the user two, one under the other — which looks worse than having none.
Build and submit
One to two minutes and you have both platforms. iOS is compiled and signed on our cloud macOS machines and lands in TestFlight by itself, so a Mac never enters the picture.
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. If your Glide app is an internal tool rather than a public product, ask us about Apple Business Manager distribution instead — the public store is the wrong route for it and a common reason for rejection.
Charging for access to your Glide app
Glide bills you for the app. This is about billing your own users.
If people pay to use your app — a membership, a seat, a premium tier — Apple and Google require their own billing for anything unlocked inside the app. An external checkout for that is its own rejection, separate from 4.2.
- 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.
- No code needed in Glide. Link a button to a URL with the product id appended and the app buys it instead of navigating — which matters, because Glide is not a place you can drop in arbitrary JavaScript.
- Money lands in your store accounts. Glideep never takes a cut of your revenue.
- Showing purchase state inside Glide needs a write back to your data source; the app triggers the purchase, your data decides what the user sees.
Or let our team submit it for you.
Glide gets people to a working app without ever touching a store console, which means submission is often the first genuinely unfamiliar part of the whole project.
For a one-off fee our team takes it from a working build to a live listing. We QA on real devices, test the flows, prepare the store assets and handle the back-and-forth with review — public store, or Apple Business Manager if the app is internal.
- A read on your app — whether it is thin enough that review will push back, and what to add if so.
- Real-device QA — your Glide views on actual iOS and Android hardware.
- Notification wiring — the webhook from your data source through to a phone, tested end to end.
- Both stores — assets, listings, submission, and the reply if review comes back.
You keep building in Glide
Shipping an app does not freeze your editor.
Glide to app store, answered
Do I need a paid Glide plan for this?
No. Glideep loads your published Glide URL, and a published app on the free tier works the same as one on a paid plan. Your Glide plan governs Glide things — rows, users, features — not whether we can wrap it.
My Glide app already looks like an app. Do I still need native features?
Fewer than most platforms, but not none. Guideline 4.2 asks whether the app does something a browser cannot, not whether it looks the part. Push notifications and biometric lock are usually enough to answer that on a Glide app.
Should I turn on Glideep's bottom navigation?
Usually not. Glide already provides tabs, so adding ours gives the user two navigation bars stacked on top of each other. The side drawer is sometimes useful for links that sit outside the Glide app; the bottom bar rarely is.
My Glide app is an internal tool for my team. Can it go on the App Store?
It can, but the public store is the wrong route and a common reason for rejection — Apple reviews public listings for public usefulness, and a data-driven tool for nine people does not clear that bar. Use Apple Business Manager custom distribution and Google Play's private channel instead. Same build, different destination.
Can I send a notification when a row changes?
Yes. Push runs through OneSignal, which has a REST API, so anything that can call a webhook when your data changes can trigger a notification.
Does Glide sign-in still work?
Yes. It is the same app running in the WebView with its session intact. Native Google and Apple sign-in are an addition on top if you want them — and worth adding, since a native sign-in sheet reads very differently to a reviewer than a web sign-in screen.
Get your Glide app onto the stores.
Start free, build a real app, and see it on your own phone before you pay anything.