Base44 gives you the file. Getting approved is the other half.
Base44 can now hand you an APK, an AAB and an IPA. What it hands you is your web app inside a shell — which is exactly the kind of build App Store review rejects. Glideep adds the native capability that is missing, and tells you when the public store is the wrong route entirely.
Why the build Base44 gives you gets rejected
Being able to download a binary is not the same as being able to publish it. There are two separate rejections waiting, and which one you face depends on who your app is for.
Base44 now produces APK, AAB and IPA files, which is genuinely useful — you can install your app and hand it to someone. But what is inside that file is your Base44 web app running in a shell. There are no push notifications in it, no biometric lock, no native sign-in, no store billing, and no navigation a phone would recognise as native.
So a reviewer opens it and sees a data-driven dashboard rendered in a WebView — tables, forms, filters. That is guideline 4.2, Minimum Functionality: nothing here that Safari could not do. Holding the binary does not change the answer. It just gets you to the rejection faster.
- Push notifications
- Biometric lock
- Native Google / Apple sign-in
- StoreKit & Play Billing
- Native navigation
- Push notifications
- Biometric lock
- Native Google / Apple sign-in
- StoreKit & Play Billing
- Native navigation
Both are signed, installable binaries. A reviewer opens the one on the left and finds a browser.
Your app should include features, content, and UI that elevate it beyond a repackaged website.
That one is fixable, and the rest of this page is about how. But Base44 has a second problem the others do not, because of what people build with it.
A large share of Base44 apps are internal — a CRM for one company, an ops dashboard, a tracker for a team of nine. Apple reviews the public App Store for a public audience. An app only useful to your own staff can be rejected as having no value to general users, and no amount of push notifications changes that. It is a different finding with a different fix.
So decide first which app you have. If it is genuinely for the public, follow the walkthrough below. If it is internal, you want Apple Business Manager custom app distribution instead of the public store — same build, different channel, and no review against a public-usefulness bar. We can set either up.
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 Base44 app, submitted two ways
Nothing changes in Base44. What changes is the shell around it.
- Opens straight into a table of records, full screen
- Looks like an admin panel because it is one
- No notifications — a record changes and nobody knows
- Login is the same web form as the browser
- Payments through an external checkout — a second rejection
- Blank screen while the app boots, nothing offline
A signed file, and everything in it is available in a browser. That is the finding.
- A native home screen with your own cards and shortcuts
- Bottom tab bar and side drawer instead of a web nav
- Push when a record is assigned, approved or overdue
- Face ID / fingerprint lock — convincing for business data
- Native Google and Apple sign-in
- StoreKit and Play Billing if you charge for access
For a business app, biometric lock and push are usually the two that do the most work. A dashboard someone unlocks with Face ID reads very differently to a reviewer than a table in a browser.
Base44 to TestFlight, start to finish
Four steps. The third is the one that decides whether you are approved.
Copy your published URL — not the exported build
Publish your Base44 app and copy its live address — the *.base44.app URL, or your custom domain if you have connected one. You do not need Base44's exported APK or IPA here; Glideep builds its own around the same app.
Working from the URL rather than a file is also why your Base44 edits keep reaching users after you ship. An exported binary is frozen at the moment it was built; a URL is not.
Decide public or internal
This is the step specific to Base44, and doing it now saves a rejection later. Ask honestly: would someone outside your organisation download this and get value from it?
If yes, carry on to step 3 and submit to the public store. If no — it is a tool for your own team, your client's staff, or a closed group — you want Apple Business Manager custom distribution and Google Play's private channel instead. Same build from Glideep, different destination, and no public-usefulness review to clear. If you are unsure which you have, ask us before you submit rather than after.
Turn on what gets you past 4.2
Work through the editor tabs and switch on what genuinely suits a business app. You do not need all of these — you need enough that the honest answer to “could I do this in a browser?” is no.
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.
Charging for access to your Base44 app
Where the money is taken from decides whether you are approved.
If people pay to use the app itself — a seat, a subscription, a premium tier — Apple and Google require their own billing. Sending users to a Stripe or Paddle checkout for that is its own rejection, separate from 4.2, and it is a common way a second submission fails after the first one passed.
- Apple StoreKit and Google Play Billing are wired into the native shell, not called from a WebView.
- RevenueCat covers both stores from one set of products and entitlements.
- No code needed in Base44. Call the JS bridge if your app can run custom code, or link a button to a URL with the product id appended if it cannot.
- Money lands in your store accounts. Glideep never takes a cut of your revenue.
- Invoicing a company is different. If you bill an organisation outside the app for seats, that is not an in-app purchase and Apple does not want a cut of it.
Or let our team submit it for you.
Base44 gets you to a working app quickly, which means people often reach submission with no App Store experience at all — certificates, provisioning, store listings, content ratings, privacy answers, and a first rejection nobody warned them about.
For a one-off fee our team takes it from a working build to a live listing, on the public store or through Apple Business Manager if the app is internal. We QA on real devices, test the flows, prepare the assets and handle the back-and-forth with review.
- Public or internal — we tell you which route your app should take before you submit.
- QA on real devices — not just a simulator run.
- Flow testing — sign-in, permissions, purchases, notifications.
- Submission and review — including replying to the Resolution Center if it comes to that.
You keep building in Base44
Shipping an app does not mean freezing the tool.
Base44 to app store, answered
Base44 can export an APK and IPA now. Why would I use Glideep?
Because exporting and being approved are different problems. The file Base44 builds is your web app in a shell — no push notifications, no biometric lock, no native sign-in, no store billing. That is precisely the app guideline 4.2 was written to reject, so being able to download it mostly means reaching the rejection sooner. Glideep builds the same app with those capabilities present. If all you need is a file to hand a colleague, Base44's export is fine and you do not need us.
Will Apple reject my app because it was built with AI?
No. Apple does not ask how the code was written and there is no rule against AI-generated or no-code apps. What gets rejected is an app that offers nothing beyond its website, whoever or whatever wrote it. Hand-written React apps fail guideline 4.2 constantly.
My Base44 app is an internal tool. Can it go on the App Store at all?
It can, but the public store is the wrong route and it is a common reason for rejection — Apple reviews public listings for public usefulness. For an app meant for your own staff or one client, use Apple Business Manager custom app distribution and Google Play's private channel. Glideep produces the same build; only the distribution differs. Ask us before submitting if you are not sure which you have.
Does my Base44 login and database keep working?
Yes. It is the same app running in the WebView with its session intact, so authentication and data behave exactly as they do in the browser. Native Google and Apple sign-in are an addition on top if you want them, not a replacement.
Can I send a notification when a record changes?
Yes, and on a business app this is usually the most valuable native feature. Push runs through OneSignal, so you can trigger a notification from your own backend when something is assigned, approved or overdue.
Can I keep charging through Stripe?
For invoicing a company outside the app, yes — Apple does not want a share of that. For anything a user unlocks inside the app, Apple and Google require their own billing, and an external checkout is its own rejection.
How long does the whole thing take?
The build is one to two minutes. Setting up the native features honestly takes an afternoon. Apple's review is typically 24 to 48 hours and Google Play is often faster. The slowest part is usually the Apple Developer account, so start that first.
Get your Base44 app onto the stores.
Start free, build a real app, and see it on your own phone before you pay anything.