Base44 has no native mobile app export. The platform generates a React web application and wraps it in its publishing flow; there is no ‘build for iOS' or ‘build for Android' button that produces a signed App Store binary. If you need to ship to mobile stores, you pick one of three paths: a Progressive Web App, a WebView wrapper (Capacitor or Median.co), or a full migration to React Native. Each has a different cost, a different performance ceiling, and a different rejection risk on Apple's review queue.
Base44 cannot export directly to iOS or Android. The three viable paths are: a Progressive Web App (no app stores, fastest to ship, no native APIs), a WebView wrapper using Capacitor or Median.co (App Store and Play Store distribution, real rejection risk on Apple's Guidelines 4.2.2 and 3.1.1, $0–200/month tooling cost), or a full migration to React Native (4–10 weeks of engineering, full native control, no platform ceiling). Pick PWA for B2B tools, a wrapper for most B2C apps that need store distribution, and React Native when the wrapper hits a performance or compliance ceiling.
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 most teams on the second submission.
Why base44 has no native mobile export
Base44 is a web-first AI-coding platform. The agent generates React code, the runtime serves a single-page app from base44's hosting, and the platform's mobile story is ‘ship as a website, optionally wrap it.' There is no Swift bridge, no Android Gradle build, no native iOS or Android scaffolding inside the platform.
The architectural reason is that StoreKit, App Store Connect provisioning, APNs certificates, Play Console signing, and target-SDK compliance are all native-toolchain concerns. They do not fit a browser-based AI agent that emits TypeScript and JSX. Adding them would mean base44 becomes a native mobile platform, which is a fundamentally different product.
The practical reason is that base44's customers are mostly building B2B SaaS, internal tools, and content sites where a web app is enough. Mobile-first audiences are a smaller share, and the platform has not invested there.
So when a feedback-board user asks ‘how do I get my base44 app on the App Store,' the honest answer is: not from inside base44. You leave the platform's runtime for the mobile build, and you bring the web app along.
The three real paths
Three 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 StoreKit, 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 require iOS 16.4+ and an explicit ‘add to home screen' install. Conversion is materially lower than native push.
- 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.
- Some browsers (notably iOS Safari) reset the service worker cache aggressively; offline behavior is less reliable than a wrapped app.
- No background sync, no geofencing, no Bluetooth on iOS, no camera access at native quality.
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 — WebView wrapper (Capacitor or Median.co)
A WebView wrapper is a thin native iOS or Android shell that loads your base44 web app inside a system WebView. Capacitor (open source, by the Ionic team) gives you a Node-based CLI, JavaScript bridges to native APIs, and a plugin ecosystem. Median.co (formerly GoNative) is a hosted service that builds the wrapper for you from your URL and a config file.
Implementation differs by tool:
Capacitor is DIY. You install the CLI, point it at your published base44 URL, run npx cap add ios and npx cap add android, configure plugins (push, file system, share, biometrics), 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 enter your base44 URL, configure features in their dashboard, and they produce the .ipa and .aab files for store submission. No Xcode required, no Gradle. The tradeoff is monthly subscription cost and less control over native plugins.
App Store rejection risk:
This is the trap. Apple's Guideline 4.2.2 explicitly targets apps that are essentially a web view wrapping a website. Reviewers reject these unless the app provides native value beyond a browser. Mitigations that work in practice:
- Add Sign in with Apple as an auth option.
- Add real push notifications via APNs (not web push).
- Add biometric unlock (Face ID, Touch ID) for app entry.
- Add a native share sheet or document picker.
- Add at least one offline-capable feature using the wrapper's filesystem.
Two or three of these usually clear 4.2.2. Going in with zero native features and a pure WebView is a near-certain rejection.
The other rejection trigger is Guideline 3.1.1 — StoreKit / In-App Purchase. If your app sells a digital subscription or unlocks paid content, you cannot route the payment through Stripe inside the iOS app. You must integrate StoreKit, verify receipts on a stable backend, and pay Apple's 15–30% fee. We documented the full pattern in the App Store rejection — no StoreKit fix; that page has the rejection email language and the workaround paths.
Real cost:
Median.co lists subscription tiers from roughly $33–$199/month depending on features (live reload, push, deep links, custom splash screens). Add the $99/year Apple developer fee and $25 one-time Google Play fee.
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-SDK bumps (Google requires updates within 12 months), and store policy changes. Loaded at $100–200/hour, that is $200–1,200/month in opportunity cost — usually higher than Median's mid-tier.
Plug your numbers into the cost calculator before deciding. For most small teams, Median's middle tier is cheaper than DIY by month four.
Path 3 — 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 Capacitor cannot reach, repeated 4.2.2 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 reject 4.2.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 treated the wrapper as ‘just publish and we're done.' It is not.
Apple's review process applies two guidelines that hit base44 wrappers hard:
- Guideline 4.2.2 — apps that are essentially a web view wrapping a website are routinely rejected. The reviewer notes: ‘Your app does not include features, functionality, or content sufficient to be approved as an app.'
- Guideline 3.1.1 — apps offering digital subscriptions, content, or features for purchase must use StoreKit. Routing through Stripe in the iOS WebView is rejected.
The trap is that a base44 wrapper passes Apple's automated pre-checks, builds cleanly, uploads to App Store Connect, and reaches review. The rejection arrives 24–72 hours later, often after you have announced the launch. The fix requires shipping a new build with native features (for 4.2.2) or StoreKit integration (for 3.1.1), then waiting for another review cycle.
We covered the rejection pattern in detail with the actual rejection email language and the three workaround paths in the App Store rejection — no StoreKit writeup. Read it before you submit.
Google Play is materially more permissive. The same wrapper typically clears Play Store review on the first submission with no native features beyond the wrapper's defaults. Play does still require accurate data-safety declarations, current target SDK, and Google Play Billing for digital purchases, so it is not a free pass — just a much shorter queue.
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. Save the cost and complexity.
- Audience is B2C, you need store presence, no paid content → Capacitor or Median wrapper. Add 2–3 native features for 4.2.2 mitigation.
- Audience is B2C, paid digital content → Wrapper plus StoreKit on iOS, plus Google Play Billing on Android. See the App Store rejection fix. Most teams hire help here.
- You need HealthKit, ARKit, Core Bluetooth, or other deep iOS APIs → React Native migration. Wrapper cannot reach them.
- You hit App Store rejections that the wrapper cannot mitigate → React Native migration.
- You are a startup with seed funding and 12-month runway, B2C consumer app → Skip the wrapper detour. Go to React Native from week one. The wrapper is a 6–12 month detour you will undo. Our solutions for startups page covers this case.
- You have a small B2B app, you charge via Stripe on the web, you want a ‘download our app' link → PWA plus optional Android wrapper. Skip iOS, or accept iOS as ‘free tier with web upsell.'
- Engineering team has zero React Native experience, deadline is 6 weeks → Median.co wrapper. 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: for most base44 apps, the right answer is PWA-first, then a Median.co wrapper if and when store distribution becomes a real revenue or growth need. We have seen too many teams sink three weeks into a Capacitor build for an app whose users would have happily added to home screen, and we have seen too many teams hit the 4.2.2 wall on iOS without a mitigation plan. Skip both pitfalls by validating that store distribution is actually load-bearing for your business before you build for it. If it is, buy Median for the first six months and use that runway to validate whether the wrapper ceiling is going to bite you. When it does, 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 — typical engagements are 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.