Base44 to the App Store: how mobile builds work and where they stop

How Base44’s mobile builds work

Base44’s app store guide describes the model plainly: your mobile app runs your published Base44 app inside a secure web view, a lightweight native wrapper that opens only your app’s address.

From the editor you can:

• Scan your app against Apple and Google guidelines and get a readiness score (available on the Free plan).
• Improve flagged problems with the AI chat and scan again.
• Generate the store files for the App Store and Google Play, which requires the Builder plan or higher.
• Add push notifications when you generate the files, using an Apple push key and a Firebase project, and send them from your backend with Base44’s push notification integration (about one integration credit per notification).

Because the wrapper loads your live app, most content and design changes appear on phones as soon as you publish, without a store review. You only submit a new build when the app shell changes: its name, icon, identifiers, push notifications or new device permissions.

Even without the stores, Base44 apps work in any mobile browser, and people can add them to their home screen, where they open like an app (Creating and using your app on mobile).

What the wrapper can’t do yet

Base44 is open about the current limits:

• No in-app purchases. Apple and Google insist that digital goods sold inside an app, such as subscriptions, premium features or credits, go through their own payment systems. Base44 doesn’t support StoreKit or Google Play Billing yet, and warns that an app selling digital content through Stripe will be rejected. The suggested workaround is to sell on the web and have the app check who has paid, without any payment flow inside the app. Base44 also notes that third-party plugins such as RevenueCat or Capacitor purchase plugins need native access its apps don’t expose, so they don’t work.
• No HealthKit, and no full offline mode.
• A fixed start page. The app opens at the entry point Base44 chooses from your published app; you can’t pick a different start page for mobile.
• Fixed identifiers. Base44 sets the bundle ID and signing key in the generated files, and they can’t be changed. If you’ve published a native app for the same brand before, the stores may block the update, and Base44’s advice is to create a new store listing.
• Google sign-in needs an extra step. You add Google Play’s app-signing fingerprint to Base44 so Google login works in the installed app.

For many apps, like internal tools, community apps or companion apps to a web service, none of this matters. For consumer apps that charge for features on the phone, the in-app purchase gap is decisive.

Store basics, whatever you build with

These apply to every app, however it’s made:

• Apple Developer Program: $99 a year, in your name or your company’s.
• Google Play Console: a one-time $25 registration fee.
• New personal Google Play accounts need 12 or more testers opted in to a closed test for 14 days in a row before they can apply for production access (Google’s testing requirements). Plan for those two weeks.
• Apple’s minimum functionality rule (guideline 4.2): an app that is only a website in a frame can be rejected. Show that the app is useful as an app: push notifications, a proper sign-in, and screens designed for a phone help.
• Account deletion: if people can create an account in your app, Apple requires that they can also delete it from within the app.
• Review access: give reviewers a working demo account, and make sure your privacy policy and terms are reachable before sign-in.

What owning the code changes

When your app’s code and backend are yours, the wrapper stops being a fixed product and becomes a choice. A common setup is Capacitor, which packages a React app as a native iOS and Android project you control:

• In-app purchases through StoreKit and Google Play Billing, directly or via a service such as RevenueCat, with your own backend verifying each purchase.
• Native features: push notifications, deep links, biometrics, camera and file access, background tasks, and HealthKit if you need it.
• Your own identifiers and signing, so you can keep an existing store listing.
• Offline behaviour that you design, such as caching the screens and data that matter.
• Your own release rhythm, from your repository.

The cost is the pipeline: building an iOS app needs Xcode on a Mac or a cloud build service, and store submissions become your job. A developer, or a coding agent working on your repository, can set it up once.

Unbase44 and mobile

A migrated app is the same web app, now served from your own domain and hosting. Anything that loaded your Base44 app in a browser, including a home-screen shortcut, works the same way pointed at the new address.

Every migrated repository also carries a native shell for iPhone and Android (built with Capacitor) around your live app, with your app’s name, icon and its own address in the system, so Google sign-in opens in the phone’s secure browser sheet and comes back into the app. The repository’s MOBILE.md explains how a developer builds it today.

Coming soon to your Unbase44 page: one click to build the Android app, and iPhone builds uploaded to TestFlight from a cloud Mac, with no Mac of your own.

Because the apps load your live app, every change you deploy reaches them without a new store release. In-app purchases for digital goods still need StoreKit or Google Play Billing, which your developer (or coding agent) adds in your own repository.