You finally have a working Base44 app, customers are asking for the download link, and you hit a wall: there is no "Submit to App Store" button, and the first wrapper you tried came back with a rejection email full of guideline numbers. That moment — when distribution turns out to be a different problem than building — is where most founders get stuck, and it is almost always a strategy problem rather than a code problem.
To publish a Base44 app to the App Store, you cannot submit it as-is, because Base44 produces a web app and Apple only accepts compiled binaries. The working path is to wrap the app with Capacitor or Median, add genuine native features so Apple does not reject it as a bare web view, and route any paid content through StoreKit. Plan for one to three review cycles on iOS; Google Play usually clears on the first try.
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 exporting your code — it is about getting past review and staying approved. If you only need to understand the export and distribution options at a high level, our Base44 mobile app export guide covers the three packaging routes; this piece picks up where that one ends, at the review queue itself.
PWA vs Native Wrapper: Which You Actually 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, and they are not interchangeable. 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, and Apple does not accept PWAs into its store at all. 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.
A native wrapper is the bridge. Tools like Capacitor (open source, you run the build) and Median.co (hosted, subscription) take your Base44 web app and produce real signed binaries: an .ipa for Apple and an .aab for Google. Those binaries are what the stores accept. The wrapper renders your existing web UI inside a native shell and exposes native APIs — push, camera, biometrics, file storage — that a plain web app cannot reach.
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 | Native wrapper (Capacitor/Median) |
|---|---|---|
| App Store / Play Store listing | Not possible | Yes |
| Store search discoverability | No | Yes |
| Install via link / QR | Yes | Via store only |
| Push notifications (iOS) | Home-screen only, 16.4+ | Full APNs support |
| In-app purchases / subscriptions | Web checkout only | StoreKit / Play Billing |
| Setup effort | Low | Moderate |
| Apple rejection risk | N/A (no store) | Real — must mitigate |
| Tooling cost | $0 | $0 (DIY) to ~$200/mo (Median) |
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 your buyers expect to find you in the store, or your category trains them to "download the app," you need the wrapper — and the rest of this guide is about surviving Apple's review with it.
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 — produce a real binary. Base44 publishes a web app; Apple wants a compiled .ipa. You wrap the published app with Capacitor or Median, point it at your live Base44 URL or bundle the assets, and generate signed builds. This is also where Android diverges: a single Base44 iOS Android submission means one wrapper but two separate uploads, so you produce a distinct .aab for Play alongside the iOS .ipa.
Gate two — register the developer accounts. Apple charges 99 dollars per year for an Apple Developer Program membership; Google charges a one-time 25 dollars for a Play Console account. Without these you cannot even upload, and the Apple account can take a day or two to verify, so start it early.
Gate three — add native value. This is the gate that catches Base44 apps specifically. A wrapper that is nothing but your website in a frame trips Apple's Guideline 4.2.2. Before you submit, wire in at least two genuine native features — push via APNs, Sign in with Apple, biometric unlock, native share, or offline caching. We treat this as non-negotiable for iOS.
Gate four — handle money correctly. If your app sells anything digital — a subscription, premium features, credits — Apple requires it to go through StoreKit (In-App Purchase), and routing payment around it through your own Stripe web flow trips Guideline 3.1.1. This is the gate most Base44 founders underestimate, because their Base44 app already has Stripe wired up and they assume it carries over. It does not, for iOS digital goods.
Gate five — complete the metadata and privacy declarations. App Privacy nutrition labels, a working demo login for the reviewer, accurate screenshots, and a privacy policy URL. Reviewers reject builds they cannot actually test, so a broken or missing test account is a surprisingly common bounce.
Clear all five and you submit. Apple's human review then takes roughly 24 to 48 hours per cycle. Google Play, by contrast, is mostly automated and typically approves a wrapped Base44 app on the first submission, which is why we tell clients to launch Android first to build momentum while the iOS cycles play out.
Top Rejection Reasons (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. Across the Base44 app submissions we have shepherded, four causes account for nearly every rejection. Knowing them in advance changes a multi-week ordeal into a one-cycle approval.
| Rejection cause | Apple guideline | Why Base44 apps hit it | The fix |
|---|---|---|---|
| Thin web wrapper, no native value | 4.2.2 | Wrapper renders the web app with zero native features | Add 2+ real native capabilities (push, Sign in with Apple, biometrics, offline) |
| Paid content outside StoreKit | 3.1.1 | App reuses Base44's existing Stripe web checkout | Integrate StoreKit IAP; validate receipts server-side |
| Incomplete privacy declarations | 5.1.1 | App Privacy labels left blank or wrong | Declare every data type the app collects, accurately |
| 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 4.2.2 problem is the signature Base44 rejection, 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. The pattern is consistent: a founder wraps the app, submits, gets a 4.2.2 bounce, adds one tiny native 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. Add the native features and the StoreKit integration before the first submission, not in response to each rejection. Apple's reviewers are not adversaries, but they will only tell you about the violation they see 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 almost every store conversation, because they are both what users expect from "a real app" and what a plain Base44 web app cannot fully deliver: push notifications and offline mode.
On push, the story splits by platform. A Base44 PWA can do web push on Android and, since iOS 16.4, on iOS too — but only for apps the user has explicitly added to the home screen, which is a fragile assumption for a consumer product. The moment you wrap with Capacitor or Median, you get true native push: APNs on iOS and FCM on Android, with the reliability and the lock-screen behavior users expect. This is why we often add push during the wrapping step even when the client did not ask for it — it doubles as one of the native features that satisfies Apple's 4.2.2 rule. Adding genuine push value is both a feature and a rejection insurance policy.
Offline mode follows the same logic. The Base44 web app depends on a live connection to its backend, so a dropped network usually means a blank or broken screen. A wrapper gives you native filesystem and cache APIs, so you can store the last-known state, queue user actions, and sync when connectivity returns. Full offline-first behavior is real engineering — not a checkbox — but even a modest "show cached data, queue writes" layer dramatically improves the perceived quality of the app and gives the reviewer something tangibly native to evaluate. That 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 caveat: both of these sit outside Base44's runtime. They live in the wrapper and its plugins, which means they are maintained separately from your Base44 app and need attention when the native SDKs or store policies change. That ongoing maintenance is a real cost, and it 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. The tooling is public, the guidelines are documented, and a technical founder can wrap a Base44 app over a weekend. The question is whether the rejection cycles are worth your time, because the expensive part is rarely the wrapping — it is the StoreKit receipt validation, the native feature 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 (Capacitor) | $0 tooling + your time | 2–6 weeks (learning + cycles) | You are technical and have time to absorb rejections |
| DIY (Median hosted) | ~$33–$199/mo | 1–4 weeks | You want a managed wrapper but will handle StoreKit and review yourself |
| Specialist-handled | Complex fixes from $3,000 | 1–2 review cycles | Repeated rejections, paid content, or a hard launch date |
The decision usually comes down to two factors: whether your app charges for anything (StoreKit is where DIY founders lose the most days, and our guide to adding subscription billing to Base44 covers the payment side that has to coexist with it), and whether you have a deadline. A B2B internal tool with no in-app purchases and no launch date is a fine DIY project. 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. Each rejection only surfaces one issue, so a third independent attempt often just reveals a fourth problem you could have batched. At that point, a specialist who has cleared the queue before will resolve all four causes in a single pass.
Have Us Handle Your App Store Submission
If your Base44 app is bouncing off Apple's review queue — StoreKit rejections, the 4.2.2 web-wrapper trap, or a launch date closing in — this is exactly the kind of work we take on as a fixed-scope engagement. We handle the wrapper, add the native capabilities Apple wants to see, integrate StoreKit with server-side receipt validation, complete the privacy and metadata gates, and submit on your behalf. Our complex fixes start from $3,000, they are fixed-price so you know the cost before we start, and they carry our money-back guarantee. If you would rather talk through scope first — including whether a wrapper or a fuller native build 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 not a coding milestone, 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, front-load the native features and StoreKit before the first submission instead of reacting to each rejection, launch Android first while iOS cycles run, and treat the wrapper as a maintained surface rather than a one-time export. Do those four things and the App Store stops being a wall and becomes a checklist.
Related reading
- Base44 mobile app export guide — the three packaging routes (PWA, wrapper, React Native) and how to pick before you submit.
- App Store rejection: no StoreKit — the exact rejection pattern and the StoreKit integration that clears it.
- Base44 for startups — where mobile distribution fits into a consumer launch on Base44.
- Base44 build service — for full mobile builds when a wrapper hits its ceiling.
- Add subscription billing to Base44 — the payment plumbing that has to play nicely with StoreKit before you submit.
- 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.