Base44 → App Store & Google Play
Turn your Base44 app into a native iOS & Android app
AppNative packages your Base44 app into a signed native iOS and Android binary — keeping your Base44 entities, authentication and backend functions exactly as they are — then adds native capabilities and ships to TestFlight, the App Store and Google Play.
How do you turn a Base44 app into a native mobile app?
Sync your Base44 app to GitHub, connect that repository to AppNative, and it generates a signed native iOS and Android shell around your live Base44 app. Your Base44 entities, auth sessions and backend functions keep working untouched, while native push notifications, in-app purchases, biometrics and widgets are added and the build is uploaded to TestFlight and Google Play.
- Base44 backend changes
- None — entities, auth and functions unchanged
- Rewrite required
- None — your React code ships as-is
- Time to first TestFlight build
- Usually under 1 hour
- Login persistence
- Base44 sessions survive app restarts natively
- Platforms produced
- iOS (.ipa) + Android (.aab / .apk)
- Store accounts
- Yours — Apple $99/yr, Google $25 one-time
How to turn a Base44 app into a native mobile app, step by step
Six steps, one codebase, no native development. Each step happens inside AppNative except the first.
- 1
Push your Base44 app to GitHub
Enable Base44's GitHub sync so your app's React source lives in a repository. That repo becomes the source of truth for every native build.
- 2
Connect the repo to AppNative
Authorize GitHub in AppNative and select the repository and branch. AppNative detects your routes, entities and theme colors and pre-fills the wizard.
- 3
Point the app at your Base44 URL
Enter your live Base44 app URL and choose the screen the app opens on. AppNative keeps your Base44 auth flow — including Google and Apple sign-in — working inside the native web view.
- 4
Brand it
Upload a 1024×1024 icon and a splash image, pick your status-bar style and safe-area colors, and AppNative generates every required asset size for both stores.
- 5
Enable native capabilities
Turn on push notifications, in-app purchases, Face ID, camera, offline mode, deep links, widgets, Live Activities and Wallet passes. AppNative writes the Swift and Kotlin code plus the App Store privacy strings.
- 6
Build, test and publish
Press Build. AppNative signs the binary with your certificates, ships it to TestFlight for your testers, and uploads the Android bundle to Google Play.
Native capabilities your Base44 app gains
These are real native implementations compiled into the binary — not browser fallbacks — and they're what moves an app past Apple's "minimum functionality" bar.
- Push notifications sent straight from a Base44 backend function via one REST call
- In-app purchases with StoreKit 2 + Google Play Billing, writing entitlements back to your Base44 entities
- Persistent Base44 auth — tokens and cookies survive app restarts and cold launches
- Face ID / Touch ID app lock
- Camera, photo library, microphone, location and contacts
- Offline mode that caches your app shell and Base44 data reads
- Deep links from push notifications into any Base44 route
- Home-screen widgets and Live Activities fed by your Base44 data
- Apple Wallet and Google Wallet passes issued from your Base44 records
- Adaptive safe-area theming that follows your app's light/dark mode
Base44 to mobile: the alternatives, compared
Why not rebuild the Base44 app in React Native?
A React Native rewrite forces you to re-implement every screen and re-wire the Base44 SDK by hand, then maintain that copy forever. AppNative keeps one codebase: your Base44 app. Deploy in Base44 and the mobile app reflects it immediately, because the native shell renders your live app.
Why not ship a PWA?
A PWA is not in the App Store or Google Play, cannot use StoreKit in-app purchases, and gives up reliable iOS push, Face ID, widgets, Live Activities and Wallet passes. Native store presence is also discovery — users search the stores for apps.
What about Base44 apps that need real device features?
Anything the browser can't reach is exposed to your Base44 JavaScript through the window.AppNative bridge: biometrics, native camera capture, haptics, share sheet, screen recording, badge counts and push tokens. You keep writing normal Base44 code and call native features like any other function.
Base44 to mobile app: every question, answered
The exact questions people ask before shipping a Base44 project to the App Store and Google Play.
How do I turn my Base44 app into a mobile app?
Enable Base44's GitHub sync, connect that repository to AppNative, point it at your live Base44 app URL, set the app name, bundle ID and icon, toggle the native capabilities you need, and press Build. AppNative signs and compiles native iOS and Android binaries and uploads them to TestFlight and Google Play.
Can Base44 build native mobile apps?
Base44 builds full-stack web apps — React frontends with Base44 entities, authentication and backend functions. It doesn't emit an iOS or Android binary, so store submission needs a native layer. AppNative provides it while leaving your Base44 backend completely untouched.
How do I publish my Base44 app to the App Store?
Compile it into a signed native iOS app and submit through App Store Connect. AppNative generates the Xcode project from your Base44 repo, registers the bundle ID, creates or uses your signing certificate and provisioning profile, uploads to TestFlight, and handles screenshots and store metadata.
Do my Base44 entities, RLS rules and functions still work in the mobile app?
Yes, identically. The native app renders your live Base44 app, so every entity query, row-level-security rule, backend function, agent and integration runs exactly as it does on the web. There's no second API layer and no data migration.
Will users stay logged in to my Base44 app on mobile?
Yes. The native shell persists Base44 access tokens and cookies across cold launches and app restarts, restores them before page scripts run, and clears them on sign-out — so users authenticate once instead of on every open.
Can I send push notifications from a Base44 backend function?
Yes. After enabling push, call AppNative's push endpoint from any Base44 function with your app ID and API key. Target one user by email, a list of users, specific devices or everyone, with badge counts, deep links, custom sounds and rich media.
Do I need a Mac or Xcode to build a Base44 app for iOS?
No. Builds run on hosted macOS CI runners, so you never install Xcode or own a Mac. The entire iOS pipeline — signing, archiving, exporting and uploading to App Store Connect — happens in the cloud.
Web app to mobile app: key terms defined
- Native app wrapper
- A native app wrapper is a compiled iOS or Android application that renders your existing web app inside a native web view (WKWebView on iOS, WebView on Android) while exposing real device capabilities — push notifications, biometrics, camera, in-app purchases — to that web code through a JavaScript bridge.
- Hybrid app
- A hybrid app ships web technologies (HTML, CSS, JavaScript) inside a native binary that can be distributed through the App Store and Google Play. It differs from a progressive web app, which is installed from the browser and cannot be listed in either store.
- App Store guideline 4.2 (minimum functionality)
- Apple's rule that an app must do more than repackage a website. Apps that add native capability — push notifications, biometric login, camera use, offline support, widgets, in-app purchases — satisfy it; a bare website in a shell does not.
- Bundle ID / package name
- The permanent reverse-domain identifier for your app (for example com.yourcompany.yourapp). It's registered once with Apple and Google and can never be changed for a published app, so it must be decided before your first submission.
- Code signing and provisioning profile
- Apple requires every binary to be signed with a distribution certificate and matched to a provisioning profile tied to your bundle ID and team. Android requires an upload keystore. Without them a build cannot be installed or submitted.
- TestFlight
- Apple's beta distribution service. Uploading a signed build to TestFlight lets up to 100 internal testers install the app immediately, before public App Store review — the fastest way to see your wrapped app on a real device.
- Over-the-air update
- Because a wrapper renders your live web app, deploying your web app updates the mobile experience instantly with no store review. A new native build is only required when something inside the binary changes: icon, splash screen, bundle ID or a native capability.
- StoreKit and Google Play Billing
- The in-app purchase systems Apple and Google require for selling digital goods inside an app. Stripe stays valid on the web, so most apps run both and grant the same entitlement from either payment source.
Base44 to mobile app: frequently asked questions
Can I publish a Base44 app to the App Store and Google Play?
Yes. Base44 produces a web app, which stores don't accept on its own. AppNative compiles it into signed native iOS and Android binaries with real native capabilities and uploads them to App Store Connect and Google Play under your own developer accounts.
Do my Base44 entities and functions still work?
Yes, unchanged. The native app loads your live Base44 app, so every entity read/write, RLS rule, backend function and integration behaves exactly as it does on the web. No backend migration and no duplicate API layer.
Does Base44 login stay logged in on mobile?
Yes. The native shell persists Base44 access tokens and cookies across app restarts and cold launches, backs them up natively, and clears them properly on sign-out — so users aren't forced to re-authenticate every time they open the app.
How do I send push notifications from a Base44 app?
Enable push, then call AppNative's push endpoint from any Base44 backend function with your app ID and API key. You can target a single user by email, a list of users, specific devices, or broadcast to everyone, with badges, deep links, custom sounds and rich media.
How do in-app purchases work alongside Stripe in Base44?
Keep Stripe for web checkout and use Apple/Google in-app purchase inside the app, as the store rules require. AppNative ships a native paywall and a purchase bridge, and both paths write the same entitlement field on your Base44 user or subscription entity — so one paywall covers both.
Will Apple approve a Base44 app?
Apps that only repackage a website get rejected under guideline 4.2. Enabling native capabilities — push, biometrics, camera, offline, widgets, in-app purchases — is what clears that bar, and AppNative implements them natively and generates the required privacy usage descriptions. It also flags the common rejection causes before you submit.
How do I update the app after launch?
Deploy in Base44 and users get the change immediately — no store review — because the shell renders your live app. A new native build is only needed for changes inside the binary: icon, splash, bundle ID, or a native capability toggle.
Can I use my own Apple and Google accounts?
Yes, and you should. Builds are signed with your certificates and published under your own developer name, so you own the listings, reviews, subscribers and payouts.
How long does it take?
Most Base44 apps reach a first TestFlight build the same day — typically under an hour of setup plus CI build time. Store review then takes as long as Apple and Google take, usually 24–48 hours for a first submission.
Other AI app builders we ship to the stores
Building somewhere else too? AppNative ships Lovable, Bolt.new and Replit apps to the stores the same way.
Ship your Base44 app to the App Store and Google Play
Connect your repo, toggle the native features you need, press Build. Your first TestFlight build can be in testers' hands today — and your Base44 workflow doesn't change at all.