You finally have a working Base44 app, customers are asking for the download link, and the editor now has a Mobile app tab that builds the store files for you. Then the first submission comes back with a rejection email full of guideline numbers. That moment, when distribution turns out to be a different problem than building, is where founders get stuck, and what stops them is compliance, not code.
Since 3 February 2026 Base44 generates App Store (.ipa) and Google Play (.aab) files itself from the editor's Mobile app tab; downloading them requires the Builder plan or higher, and you upload them from your own App Store Connect and Play Console accounts. The build is a web-view wrapper that opens only your app's URL, with push notifications but no in-app purchases yet. Approval turns on four gates: minimum functionality, digital purchases moved to the web, privacy declarations and a login the reviewer can test.
This is the submission playbook we use when a client needs their Base44 app in the stores, written by the lead engineer at Base44Devs from the App Store and Play Store launches we have shipped. It is not about choosing a packaging route. Our Base44 mobile app export guide compares Base44's built-in store files with a self-built Capacitor or Median shell and a React Native rebuild; this piece picks up where that one ends, at the review queue itself.
PWA, Base44's Store Build or Your Own Shell: Which You Need
The first decision people get wrong is treating a Progressive Web App and an App Store listing as interchangeable. The base44 pwa vs native app question is the one that quietly determines your whole distribution path. A PWA installs from the browser to the home screen and behaves like an app, but it never appears in the App Store or Google Play. So if your actual goal is store presence (a search result, a download button, the credibility of being "in the App Store"), a PWA cannot deliver it no matter how polished it is.
Since 3 February 2026 the bridge is built into Base44. The Base44 changelog entry "Submit apps to the app stores" added App Store (IPA) and Google Play (AAB) generation to the editor's Mobile app tab, and Base44's store-submission docs describe the result as "a lightweight native wrapper around your web app that opens only your app's URL." Because the wrapper loads your live app, most content and design changes you publish reach installed apps without a new store submission.
A self-built shell, made with Capacitor (open source, you run the build) or Median.co (a hosted builder), is the older route. It still earns its place when you need native code Base44's wrapper does not expose. One caution from Capacitor's own configuration docs: the option that loads an external URL in the web view is marked "not intended for use in production", so a Capacitor shell that only points at your Base44 URL is a worse version of what Base44 now builds for you.
Here is how we frame the choice with clients. The question is not "which is better" but "what does your distribution channel demand?"
| Distribution need | PWA | Base44 store build | Self-built shell (Capacitor/Median) |
|---|---|---|---|
| App Store / Play Store listing | Not possible | Yes (.ipa and .aab) | Yes |
| What you need to produce it | Nothing extra | Builder plan or higher to download the files | Xcode and Android Studio (Capacitor) or a Median licence |
| Push notifications (iOS) | Home Screen web apps only, iOS 16.4+ | Yes, switched on at file generation | Yes, through plugins you configure |
| In-app purchases / subscriptions | Web checkout only | Not yet; the purchase moves to the web | StoreKit / Play Billing in native code you own |
| Offline mode, HealthKit | Offline via service worker; no HealthKit | Not supported yet | Possible with native work |
| Content updates | Instant | Most go live without resubmission | Depends on how you build it |
| Who maintains the shell | Nobody | Base44 | You |
| Apple rejection risk | N/A (no store) | Real, must mitigate | Real, must mitigate |
If your buyers come from email, sales calls, or a marketing site, the PWA route saves you the entire App Store gauntlet and is often the right answer. If they expect to find you in the store, start with Base44's own build: no Xcode, no Gradle, and Base44 maintains the shell. Move to a self-built shell only for a named reason, such as in-app purchases. The rest of this guide is about getting either one through Apple's review.
How to Publish a Base44 App to the App Store: The Real Path
There is a repeatable sequence here, and skipping a step is what produces the rejection emails. We call it the five gates of a Base44 store submission, because each one is a checkpoint that can bounce the build if it is not handled before you upload.
Gate one: register the developer accounts. Base44 does not create them for you. The Apple Developer Program "is 99 USD per membership year"; Google Play Console charges "a US$25 one-time registration fee" (both read 17 Oct 2026). Start with Apple, because Base44's docs note the activation email "can take up to 2 business days" and you cannot generate the iOS file without App Store Connect API credentials.
Gate two: generate the store files in Base44. Since February this is a Base44 feature rather than a wrapper project. In the editor, click Publish, open the Mobile app tab, then Check Your App and Run App Scan against the App Store and Google Play guidelines; the AI chat can apply the suggested fixes, and you rerun the scan until no critical issues remain. Then choose Build Stores Files and Create App Store files, enter your Issuer ID, Key ID and Team ID, upload the .p8 API key from App Store Connect, and download the .ipa. Create Google Play files produces the .aab. Downloading either file requires the Builder plan or higher, and a base44 iOS Android submission is still two separate uploads from your own App Store Connect and Google Play Console accounts.
Gate three: clear minimum functionality. This is the gate that catches Base44 apps specifically. Apple's Guideline 4.2 asks for features, content and UI that go beyond "a repackaged website", and adds: "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Base44's build is a wrapper that opens only your app's URL, and push notifications are the one native feature its docs list, so the wrapper cannot carry the case for you. What the reviewer judges is your app: make sure it does something useful on a phone, turn on push when you generate the files, and resolve every critical issue the app scan flags. Native features beyond push, such as biometric login or an offline cache, mean a self-built shell.
Gate four: handle money correctly. If your app sells anything digital (a subscription, premium features, credits), Apple's Guideline 3.1.1 says you must use in-app purchase, and Base44's answer to "Can I charge for digital content in my mobile app?" is "Not yet." Its docs are specific: a Stripe checkout for digital content gets the app rejected, and "RevenueCat's native SDK and Capacitor in-app purchase plugins need access to the native layer that Base44 apps do not expose, so they do not work." The documented route is to move the purchase to the web version of your app and have the mobile app check who has paid. Physical goods, real-world bookings and services delivered outside the app can keep Stripe. This is the gate that is easy to underestimate, because an app that already has Stripe wired up looks finished, and it is natural to assume Stripe carries over. Base44 says it is working on a built-in StoreKit and Google Play Billing integration; until that ships, StoreKit means native code in a shell you build yourself.
Gate five: complete privacy, metadata and a testable login. App Privacy nutrition labels, accurate screenshots, and a privacy policy and terms of use that people can reach before they sign up. Base44 picks your app's entry URL automatically, so put those links on that page. Base44 also sets the device permissions from its scan and they are not editable, so your privacy policy has to explain what the app accesses. If people can create an account, Guideline 5.1.1(v) says "you must also offer account deletion within the app." Guideline 2.1 asks you to "include demo account info" if your app includes a login, and Apple's App Review page says "over 40% of unresolved issues are related to guideline 2.1: App Completeness" (read 17 Oct 2026).
Clear all five and you submit. Apple's App Review page says App Review is "typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (read 17 Oct 2026). Google Play adds its own gate: developers with personal accounts created after November 13, 2023 "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before they can apply for production access (Play Console Help, read 17 Oct 2026). That is why we tell clients to start the Android side early and run it in parallel while the iOS cycles play out.
Rejection Reasons to Plan For (And How to Avoid Them)
If you have searched "base44 app store rejection why" after a bounce email full of guideline numbers, this is the section that answers it. Four causes are the ones to clear before you submit. They apply whether the file came from Base44's Mobile app tab or from a shell you built.
| Rejection cause | Apple guideline | Why Base44 apps hit it | The fix |
|---|---|---|---|
| App reads as a repackaged website | 4.2 (minimum functionality) | The build is a web view that opens only your app's URL | Make the app useful on a phone, turn on push, clear the scan's critical issues; further native features need a self-built shell |
| Digital purchase outside in-app purchase | 3.1.1 | App reuses Base44's Stripe web checkout; Base44 builds have no in-app purchase yet | Move the purchase to the web version of the app; StoreKit only in a self-built shell |
| Incomplete privacy declarations | 5.1.1 | Labels left blank, legal pages unreachable before sign-up, no in-app account deletion | Declare every data type, link privacy and terms from the entry page, add account deletion |
| Reviewer cannot test the app | 2.1 | No demo login, broken auth, or crash on launch | Provide a working test account and stable build |
The minimum-functionality rule is the one a Base44 web-view build is most exposed to, and the App Store rejection over missing StoreKit writeup documents how it cascades into the 3.1.1 problem when teams also charge for content. A worked example of how it cascades: a founder submits, gets a minimum-functionality bounce, adds one small feature, resubmits, then gets a fresh 3.1.1 bounce because the subscription still flows through Stripe. Two cycles burned on what should have been one.
Avoiding it is a matter of sequencing. Move digital purchases to the web and clear the scan's critical issues before the first submission, not in response to each rejection. Apple's reviewers are not adversaries, but a rejection can tell you only about the violation they saw first, so reactive fixing means you discover the next problem only after the next rejection. Front-loading the work is the single biggest lever on your approval timeline. For founders building on Base44 for a consumer audience, the Base44 for startups overview covers where store distribution fits into a broader launch plan.
Push Notifications and Offline: What's Possible
Two capabilities come up in store conversations, because they are what users expect from "a real app": push notifications and offline mode. Base44's store build answers them differently.
Push is built in. When you generate the store files, turn on Add push notifications: iOS needs an APNs auth key from your Apple Developer account, and Android needs your own Firebase project (Base44's docs say the free Spark plan is enough). You then send notifications from your app's backend with the SendPushNotification integration, each with a title, a message and an optional link to a page in your app. Two details catch teams out. Apple lets you download the APNs key's .p8 file only once, and it is a different key from the App Store Connect API key you upload in the same window. And people who installed an earlier version receive push only after you submit an updated build with push turned on. A PWA, by comparison, gets web push on Android and, since iOS 16.4, on iOS only for web apps added to the Home Screen (WebKit, read 17 Oct 2026).
Offline mode is the gap. Base44's docs state: "Full offline mode and HealthKit are not supported yet." The wrapper loads your live app, so a dropped connection usually means a blank or broken screen. If your users work on planes, in basements or on job sites, that is a real reason for a self-built shell with a native cache that stores the last-known state and queues writes until connectivity returns. Full offline-first behavior is real engineering, not a checkbox. Perceived quality matters beyond review too; our notes on how to make a Base44 app look professional cover the polish reviewers and users register on first launch.
The honest trade-off: Base44 maintains its wrapper, and your published changes flow into the installed app. A self-built shell buys native reach at the price of maintaining it yourself as native SDKs and store policies change. Google Play, for example, requires that from 31 August 2026 "New apps and app updates must target Android 16 (API level 36) or higher" (Android Developers, read 17 Oct 2026). That ongoing maintenance is one of the reasons store-distributed Base44 apps benefit from a standing relationship rather than a one-and-done build.
DIY Submission vs Hiring a Specialist
You can do this yourself. With Base44's Mobile app tab, a founder with active developer accounts can generate both files without leaving the editor. The question is whether the rejection cycles are worth your time, because the expensive part is rarely the file. It is moving digital purchases to the web without breaking the paywall, the privacy and account-deletion work, and the back-and-forth with Apple's reviewers when the email is vague about what actually failed.
| Path | Up-front cost | Time to first approval | Best when |
|---|---|---|---|
| DIY (Base44 Mobile app tab) | Builder plan or higher, plus $99/yr Apple and $25 one-time Google | Files in the editor, then review cycles | No digital purchases, no offline requirement, time to absorb a rejection |
| DIY (Capacitor shell) | $0 framework + your time | Your build and learning time, then review cycles | You need native features or StoreKit and have mobile engineering skills |
| DIY (Median shell) | From a $229 one-time licence, then an annual fee | Median's builder, then review cycles | You want a managed shell builder but will handle StoreKit and review yourself |
| Specialist-handled | Complex fixes from $3,000 | Gates cleared before the first submission, then review | Repeated rejections, paid content, or a hard launch date |
Median's figures are from median.co/pricing, as listed on 9 Oct 2026: its Starter licence lists a $229 one-time activation fee and $179/yr starting in month 12. The decision usually comes down to two factors: whether your app charges for anything digital (that is the gate that forces rework, because the purchase has to move to the web, and our guide to adding subscription billing to Base44 covers the web-side billing your mobile app has to check), and whether you have a deadline. A B2B internal tool with no digital purchases and no launch date is a fine DIY project on Base44's own build. A consumer app with subscriptions and a press date is exactly where a botched first submission costs you the launch window.
Our practical rule: if you have been rejected twice, stop iterating blind. A rejection can surface one issue at a time, so a third blind attempt can just reveal another problem you could have batched. At that point, check all four causes in a single pass, or have a specialist do it.
Have Us Handle Your App Store Submission
If your Base44 app is bouncing off Apple's review queue (a 3.1.1 purchase rejection, the minimum-functionality trap, or a launch date closing in), this is exactly the kind of work we take on as a fixed-scope engagement. We clear the scan's critical issues, move digital purchases to the web without breaking the paywall, set up push, complete the privacy, account-deletion and metadata gates, and submit on your behalf from your own store accounts. When the app genuinely needs StoreKit or offline mode, we build the native shell around it. Our complex fixes start from $3,000, they are fixed-price so you know the cost before we start, and they carry our rescue guarantee: any agreed defect we cannot resolve is refunded pro rata. Every fix carries the 90-day fix hold. If you would rather talk through scope first, including whether Base44's own build or a fuller native app is the right call for your audience, the fastest route is to tell us about your app and timeline, and if a build makes more sense than a fix, our build service covers the larger mobile engagements end to end.
The synthesis we leave clients with is this: getting a Base44 app into the App Store is no longer a build problem, it is a compliance sequence. Decide first whether you genuinely need store presence or whether a PWA covers your distribution. If you need the store, start with Base44's own build, move digital purchases to the web and clear the review gates before the first submission instead of reacting to each rejection, and run the Android submission in parallel while iOS cycles run. Reach for a self-built shell only when you need StoreKit, offline mode or another native feature Base44's wrapper does not have. Do those things and the App Store stops being a wall and becomes a checklist.
Related reading
- Base44 mobile app export guide — Base44's built-in store files vs a self-built Capacitor or Median shell vs React Native, and how to pick before you submit.
- App Store rejection: no StoreKit — why digital purchases get rejected and the three ways to keep charging for them.
- Base44 for startups — where mobile distribution fits into a consumer launch on Base44.
- Base44 build service — for full mobile builds when Base44's wrapper hits its ceiling.
- Add subscription billing to Base44 — the web-side billing your mobile app checks before it shows paid content.
- Make my Base44 app look professional — the visual polish reviewers and users judge on first launch.
- Talk to us about your submission — scope your store launch with the team that has cleared the review queue.