Base44 · App Store · Google Play · TestFlight

Publish your Base44 app to the App Store and Google Play

Apple and Google accept signed native binaries, not URLs. AppNative turns your Base44 app into a signed .ipa and .aab, creates the bundle ID and App Store Connect record, generates certificates and provisioning, uploads to TestFlight and Play, and writes the listing, screenshots and privacy answers with you.

See pricing
iOS + TestFlight Android + Google Play

How do you publish a Base44 app to the App Store?

Connect your Base44 app's repo to AppNative, set the bundle ID, icon and splash, enable native capabilities, and press Build. AppNative registers the Bundle ID and App Store Connect record, generates the distribution certificate and provisioning profiles, compiles a signed .ipa on hosted macOS CI, uploads it to TestFlight, and produces the Google Play .aab from the same project — no Xcode, no Android Studio.

What Apple accepts
A signed .ipa uploaded to App Store Connect
What Google accepts
A signed Android App Bundle (.aab)
Accounts required
Apple Developer ($99/yr) and Google Play ($25 once), in your name
Signing handled
Certificates, profiles and Android keystore generated and stored
Time to TestFlight
Usually under an hour
Main rejection risk
Guideline 4.2 — answered with real native features

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. 1

    Connect your Base44 app

    Point AppNative at the GitHub repo behind your Base44 app and pick the branch. Your live web app stays the source of truth for content.

  2. 2

    Create the app on Apple's side

    Add your App Store Connect API keys once. AppNative creates the Bundle ID with the right capabilities and the app record with your name, category, and primary locale.

  3. 3

    Generate signing assets

    AppNative issues the distribution certificate, the app provisioning profile and any extension profiles (widgets, notification service), plus an Android keystore it keeps for future updates.

  4. 4

    Enable native capabilities

    Turn on push notifications, widgets, Live Activities, Face ID, in-app purchases, offline mode or Wallet passes — the functionality that makes this an app rather than a website in a frame.

  5. 5

    Build, test, submit

    The .ipa uploads to TestFlight automatically and the .aab to your chosen Play track. Generate metadata, keywords and screenshots in AppNative, then submit for review.

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.

  • Signed .ipa and .aab built from your Base44 app with no local tooling
  • Bundle ID, capability and App Store Connect record automation
  • Certificate, provisioning profile and keystore generation and reuse
  • TestFlight upload, internal testers, beta review and compliance answers
  • Google Play upload to internal, closed or production tracks
  • AI-written titles, keyword fields, descriptions and release notes
  • Device-correct screenshots and icons with alpha stripped for Apple
  • Native capabilities that answer guideline 4.2 minimum functionality

Base44 to mobile: the alternatives, compared

Why Base44 apps get rejected under 4.2 — and the fix

Reviewers reject apps that only reproduce a website. The dependable fix is device functionality: push notifications, widgets, Live Activities, biometric unlock, camera, offline caching. AppNative compiles those into your binary so the reviewer sees native behaviour immediately on launch.

AppNative vs Median.co and Despia for Base44 apps

Those tools hand you a wrapped web view and leave Apple's paperwork to you. AppNative automates bundle IDs, certificates, profiles, App Store Connect records, TestFlight, in-app purchase products and store metadata — and ships native extensions they don't build.

Publishing vs rewriting the app

A React Native or Flutter rewrite duplicates everything you already built in Base44. Wrapping ships the app you have now, and every web deploy after launch reaches users instantly without a new review.

Base44 to mobile app: every question, answered

The exact questions people ask before shipping a Base44 project to the App Store and Google Play.

Can I submit a Base44 app URL to the App Store?

No. Apple requires a signed native binary. AppNative builds and signs that binary from your Base44 app and uploads it to App Store Connect.

Do I need a Mac?

No. Every iOS build runs on hosted macOS CI, including signing and TestFlight upload.

Does my Base44 app keep updating after launch?

Yes. Content and UI changes deploy on the web as normal. Rebuild only for native feature, icon or version changes.

Can I use my own Apple developer account?

Yes, and you should — the app, keys and revenue stay in your account. AppNative automates the work inside it.

What about App Privacy and permission strings?

AppNative generates the usage descriptions for the capabilities you enable and tells you which privacy answers match them.

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

How long until my Base44 app is on the App Store?

TestFlight the same day in most cases; public release depends on Apple review, typically 24–48 hours after you submit.

Can I publish to Google Play too?

Yes — the same project produces a signed .aab, uploaded to the track you choose, signed with a keystore AppNative stores for future updates.

Can AppNative write my store listing?

Yes: title, subtitle, keywords, description, promotional text and release notes, plus correctly sized screenshots for every required device.

Can I migrate a Base44 app already published elsewhere?

Yes. Reuse your existing bundle ID and upload your Android keystore so updates land on the same listings.

What if I need in-app purchases?

Apple requires digital goods to sell through StoreKit. AppNative creates the products, ships a native paywall and reports entitlements back to your Base44 code.

Native features only AppNative adds to a wrapped web app

Live Activities, WidgetKit widgets and rich push are compiled into your binary as real native extensions — designed through AI chat, driven by your data.

Ship from your AI app builder

Submission is easiest when the app ships real native features. See what AppNative can add, or read the full Base44 → native app guide.

Deep dives by builder and feature

Step-by-step guides for the specific thing you're trying to ship — push, in-app purchases, widgets, store submission — for Lovable and Base44 apps, plus how AppNative compares to Median.co and Despia.

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.

Read the docs