Base44 now exports mobile apps itself. Since 3 February 2026 the editor's Mobile app tab generates an App Store (.ipa) file and a Google Play (.aab) file from your published app, and the Base44 product changelog describes the result as a wrapper that puts "your published Base44 app in a secure web view". So the question is no longer how to get a Base44 app into the stores. It is whether Base44's built-in build covers what your app needs, or whether you need a Progressive Web App, a self-built Capacitor or Median shell, or a full React Native rebuild instead. Each has a different cost, a different ceiling, and a different rejection risk on Apple's review queue.
Base44 mobile app export is built in: since 3 February 2026 Base44 generates App Store (.ipa) and Google Play (.aab) files from the editor's Mobile app tab, and downloading them requires the Builder plan or higher. The build is a web-view wrapper around your published app, with push notifications configured when the files are generated. It does not support in-app purchases, full offline mode or HealthKit yet. Use it by default; move to a self-built Capacitor or Median shell, or React Native, only for one of those gaps.
This is the working guide we use on client engagements, written by the lead engineer at Base44Devs. It covers what each path actually buys you, what it breaks, and the App Store rejection trap that catches wrapped apps in review. For the submission itself, gate by gate, read how to get your Base44 app into the App Store.
What Base44's built-in mobile export is (and is not)
Base44's store-submission docs describe the build as "a lightweight native wrapper around your web app that opens only your app's URL." The flow lives inside the editor: Publish, the Mobile app tab, an app scan against the App Store and Google Play guidelines with AI-suggested fixes, then Build Stores Files. The iOS file needs your App Store Connect Issuer ID, Key ID, Team ID and .p8 API key; the Android file needs your logo and, optionally, a Firebase project for push. You can run the scan on the Free plan, but downloading the files requires Builder or higher, and you submit from your own Apple and Google developer accounts.
What the built-in export gives you:
| Capability | Base44 built-in store build |
|---|---|
| App Store .ipa and Google Play .aab | Yes, generated in the editor |
| Push notifications | Yes, switched on at file generation (APNs key for iOS, your own Firebase project for Android) |
| Content and design updates | Most go live without a new store submission, because the wrapper loads your live app |
| Device permissions | Set by Base44's scan, with purpose strings generated in the 24 languages Base44 supports; not editable |
| In-app purchases (StoreKit / Play Billing) | "Not yet"; digital purchases have to happen on the web |
| Full offline mode, HealthKit | "not supported yet" |
| Bundle ID and signing key | Set by Base44 and fixed inside the generated files |
| Start page | Chosen automatically from your published app |
Two rows in that table decide more projects than the rest. The in-app purchase row means any app selling subscriptions, credits or premium features has to move that purchase to the web; Base44's docs add that "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 bundle ID row catches teams who already shipped a native app under the same brand: if the IDs or signing key do not match the existing listing, the stores block the update, and Base44's documented fix is to create a new app entry.
The architectural reason for the gaps is that StoreKit, offline storage and health data are native-layer concerns, and Base44's wrapper exposes only your web app. Base44 says it is working on a built-in StoreKit and Google Play Billing integration and "continues to expand native feature coverage over time"; until those land, the gaps are real.
The four real paths
Four paths cover essentially every base44 mobile shipping case. They differ in cost, control, and ceiling.
Path 1 — Progressive Web App (PWA)
A PWA is your existing base44 web app with a service worker, a manifest, an install prompt, and offline behavior. Users add it to their home screen from the browser; it then launches like an app, runs full-screen, and on supported platforms can show push notifications and run offline.
When to choose it:
- Your users reach the product via email, links, sales, or a marketing site, not store search.
- Your audience is B2B, internal-tools, or technical (they do not balk at "add to home screen").
- You do not need a store listing, in-app purchase, HealthKit, or other deep OS integrations.
- You want to ship in days, not weeks.
Real-world tradeoffs:
- No App Store or Play Store discovery. Users will not find you by searching the store.
- Push notifications on iOS arrived with iOS 16.4 and only for web apps added to the Home Screen, per WebKit's announcement. Reach depends on each user taking that step.
- No in-app billing. Web payments via Stripe work fine for B2B, but B2C users expect the "subscribe" button to behave like every other app.
For a B2B audit tool, a project-management dashboard, or a content workflow app, a PWA is often enough and finishes in two or three days of focused work. For a B2C consumer app that needs store presence, it is not.
We covered the SEO and discoverability side of this in the Base44 SEO best practices writeup, which matters because if PWA is your distribution path, your web app must rank on its own.
Path 2 — Base44's built-in store files
This is now the default route to the stores. You stay inside Base44, generate the .ipa and .aab, and Base44 maintains the wrapper. Because the wrapper loads your live app, the release process for most changes is the same Publish button you already use; you only regenerate files and resubmit when the shell changes (app name, icon, bundle identifiers, push, or a feature that needs new device permissions).
When to choose it:
- You need a store listing and your app works online.
- Nothing is sold inside the app as a digital good, or you can move that purchase to the web.
- Push is the only native feature you need.
What it costs: the Builder plan or higher, plus the Apple Developer Program, which "is 99 USD per membership year", and Google Play's "US$25 one-time registration fee" (Play Console Help). Every store route pays those two account fees.
What it does not remove: Apple's review. Base44's docs state that it "cannot guarantee that an app is approved, even with a high readiness score," and that its support does not manage store review feedback for you. The five-gate submission sequence in our App Store submission guide is written for this path.
Path 3 — Self-built wrapper (Capacitor or Median.co)
A self-built wrapper is a native iOS or Android shell that you, not Base44, build and maintain. Capacitor (open source, by the Ionic team) gives you a CLI, JavaScript bridges to native APIs, and a plugin ecosystem. Median.co is a hosted builder that produces the shell for you from your site and a configuration.
The reason to take this path in 2026 is native code Base44's wrapper does not expose: StoreKit for in-app purchases, an offline cache, biometric login, Sign in with Apple, or control over the bundle ID and permissions. If you need none of those, Path 2 does the same job with less maintenance. Note what Capacitor's own configuration docs say about loading an external URL in the web view: "This is not intended for use in production." A Capacitor shell that only points at your live Base44 URL is a worse copy of Path 2; a useful one bundles the web assets and carries native code.
Implementation differs by tool:
Capacitor is DIY. You install the CLI, run npx cap add ios and npx cap add android, configure plugins (push, file system, share, biometrics, purchases), and build the binaries in Xcode and Android Studio. Initial setup is 1–3 days for someone who has shipped a Capacitor app before, longer for first-time builders.
Median.co is hosted. You configure features in its dashboard and it produces the .ipa and .aab files for store submission, without Xcode or Gradle on your side. The tradeoff is the licence fee and less control over native plugins.
Real cost:
Median's pricing page lists one-time licence activation fees of $229 (Starter), $590 (Essential) and $990 (Plus), followed by annual fees of $179, $399 and $669 starting in month 12; Business starts at $7,200 a year.
DIY Capacitor is free at the framework level. The cost is engineering time: 1–3 days initial setup, plus 2–6 hours/month maintenance for SDK updates, target API bumps and store policy changes. 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). Loaded at $100–200/hour, that upkeep is $200–1,200/month in opportunity cost; set it against Median's one-time licence before deciding. Plug your numbers into the cost calculator.
Path 4 — Full migration to React Native
When the wrapper ceiling is hit (INP over 300ms on a mid-tier Android, dropped frames in long lists, native APIs no wrapper can reach, repeated minimum-functionality rejections), the answer is to leave base44 for the mobile build.
React Native is the canonical choice. Expo gives you a managed workflow with EAS Build for binaries, OTA updates via EAS Update, and most native APIs as JavaScript modules. Flutter is a viable alternative if your team prefers Dart.
When the wrapper ceiling is hit:
- The web app's React tree re-renders too often for 60fps inside a WebView.
- You need HealthKit, ARKit, Core Bluetooth, or another iOS-only native framework.
- App Store reviewers keep rejecting the app under 4.2 even with native add-ons.
- Your investors or enterprise customers require "native app" on the security questionnaire.
- The base44 SDK's coupling makes the wrapper brittle when the platform updates.
What the migration costs:
A moderate base44 app (5–15 screens, 2–4 entities, one or two third-party integrations) takes 4–10 weeks in React Native + Expo with a Supabase or Firebase backend. The bulk of the time is not UI rebuilds; it is decoupling from base44's SDK and porting the data model. We document the canonical Next.js + Supabase migration in base44 to Next.js + Supabase; the React Native variant uses the same backend pattern with React Native screens instead of Next.js routes.
This is not a fix sprint. It is a migration project, sized and quoted accordingly. Our migration intake walks the scoping process.
The App Store rejection trap
The rejection trap catches teams who treat any wrapper, Base44's or their own, as "just publish and we're done." It is not.
Apple's App Review Guidelines apply two rules that hit base44 apps hard:
- Guideline 4.2 (Minimum Functionality) asks for features, content and UI that go beyond "a repackaged website", and states: "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Its sub-rule 4.2.2 adds that "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." A wrapper that opens only your app's URL is judged entirely on what that app does.
- Guideline 3.1.1 (In-App Purchase) requires in-app purchase for subscriptions, in-game currencies, access to premium content and similar digital goods. Stripe inside the app for those is rejected, and Base44's own build cannot offer in-app purchase yet.
The trap is that the build is clean. Base44's scan gives you a readiness score, the file generates, it uploads to App Store Connect, and it reaches review. Apple says App Review is "typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (App Review, read 17 October 2026), so a rejection can land a day or two after you announced the launch. The fix means a change to the app (for 4.2) or moving the purchase to the web (for 3.1.1), then another review cycle.
We covered the purchase rejection in detail, with the three workaround paths, in the App Store rejection — no StoreKit writeup. Read it before you submit anything that charges money.
Google Play's review makes fewer judgment calls about whether a wrapper is "app-like" enough. Play does still require accurate data-safety declarations, a current target API level, and Google Play Billing for digital purchases, so it is not a free pass.
Decision tree: which path for which use case
Walk this from the top:
- Audience is internal, B2B, or reaches you via link/email → PWA. Skip the App Store entirely unless customers ask for a listing; then use Base44's built-in files.
- Audience is B2C, you need store presence, no digital purchases, online use → Base44's built-in store files on the Builder plan or higher. Turn on push.
- Audience is B2C, paid digital content → Base44's build with the purchase moved to the web (Base44's documented route), or a self-built shell with StoreKit on iOS and Google Play Billing on Android. See the App Store rejection fix. This is the branch where outside help earns its cost.
- You need offline mode, biometric login or other native features beyond push → self-built Capacitor or Median shell.
- You need HealthKit, ARKit, Core Bluetooth, or other deep iOS APIs → React Native migration.
- You already have a native app listed under the same brand → check the bundle ID and signing key first; Base44's files cannot be changed to match, so it is a new listing or your own shell.
- You hit App Store rejections that no wrapper can mitigate → React Native migration.
- You are a startup with seed funding and 12-month runway, B2C consumer app → Consider React Native from week one if the phone is the product. Our solutions for startups page covers this case.
- Engineering team has zero native experience, deadline is 6 weeks → Base44's built-in files if they cover your feature list; a Median shell if they do not. Buy the tool, do not build it.
This decision tree assumes you have done the production readiness work on the underlying web app. A wrapper does not fix data-isolation bugs, observability gaps, or credit-burn issues; those follow you into the mobile shell.
What we recommend (and what we ship)
Honest engineer view: the default answer is now Base44's own store build, with any digital purchase on the web, and a PWA when store distribution is not actually load-bearing. We have seen teams sink weeks into a Capacitor build for an app whose users would have happily added to home screen, and we have seen teams hit Apple's minimum-functionality wall without a plan. Validate that store distribution matters to your business before you build for it, whether in-house or as a done-for-you Base44 mobile build. If it does, start with the built-in files, name the specific native requirement that would justify your own shell, and only then pay for one. When the wrapper ceiling bites, migrate to React Native with eyes open and a real budget; do not stage the migration as a side project.
This sequencing also keeps your deployment checklist sane. Each path adds release-engineering complexity; doing them in the wrong order means you maintain three deployment pipelines for one product.
When to call us
If you are stuck on which path is right for your specific app, or you have already hit an App Store rejection and need to ship a compliant build this week, we run a $497 audit that produces a written path recommendation, a sized engagement, and a rejection-mitigation plan if you are already in App Review. For full migrations to React Native or Next.js + Supabase, we scope as a migration project; a moderate app is sized at 4–10 weeks. Either way, the first step is a free 15-minute call from our contact page where we look at your app and tell you what we see.