What is a wrapper, and what does it actually do?

A wrapper is a thin native app whose entire job is to display your web app in a full-screen browser view, plus bridges that let the web code reach native features like the camera or push notifications. Tools like Capacitor package this for you — but the wrapper is only as good as the native bridges you build into it.

Do push notifications work in a wrapped Base44 app?

Only with real native work: you need push credentials from Apple/Google, a service to send the pushes, and native code in the wrapper to receive and display them. The web app alone can't do it — this is the feature that most often turns a 'quick wrapper' into a real project.

Mobile

How to Get a Base44 App Onto the App Store

Q: Can I publish my Base44 app to the App Store?

Not directly. Base44 produces a web app, and Apple and Google don't list websites as apps. You need to wrap the web app in a native shell (using a tool like Capacitor), submit that wrapper as your app, and pass store review.

Q: Will Apple approve a wrapped web app?

Sometimes — Apple explicitly rejects apps that are just a website in a frame with nothing native about them. To pass review, the app generally needs real native functionality, a mobile-appropriate experience, and to follow the guidelines on payments and content. A bare wrapper around a desktop web layout is the classic rejection.

Q: What's the cleanest path from Base44 to the App Store?

Migrate first, then go native. Move the app onto infrastructure you own — your own backend, database, and API — and the mobile app becomes a proper client talking to your API instead of a website in a trench coat. OffRamp performs that first step: your app rebuilt on Supabase, Vercel, and GitHub in your name.

OffRamp · September 25, 2026 · 6 min read

Not directly — Base44 builds web apps, and the App Store doesn’t list websites. The standard route is wrapping your web app in a thin native shell, but the wrapper is the beginning of the project, not the end: push notifications, in-app purchases, and Apple’s review guidelines all demand real native work.

A person holding up a phone with their app, facing a grand star-decorated app store archway joined by a small bridge

Start your free analysis How the wrapper route works

The gap

A website is not an app (says Apple)

Your Base44 app is a website: HTML, JavaScript, and API calls, running in a browser. The App Store and Google Play list native applications — binaries built for iOS and Android, with access to the phone’s real capabilities. Apple will not list your URL. Google will not list your URL. There is no form where you paste a link and get an app.

So every “Base44 to App Store” path is really a conversion path: turning the web app into something the stores recognize. There are two honest routes, and they differ enormously in cost.

Before any of that, one prerequisite: your app needs to actually work well on a phone. If the Base44 layouts were designed for desktop, the mobile experience needs attention first — the stores judge what users see, not what your code does.

Route one

The wrapper route: quick, but thinner than it looks

A wrapper — tools like Capacitor are the standard choice — packages your web app inside a thin native shell: essentially a full-screen browser with bridges to native features. You get an installable binary, a home-screen icon, and submission to both stores. For a simple content app, this can genuinely work.

But “wrap it” is where the easy part ends. Here’s what the wrapper doesn’t give you for free:

Push notifications

The feature everyone wants and nobody budgets for. Real push needs Apple/Google push credentials, a sending service, and native code in the wrapper to receive and display notifications. The web app alone cannot do this — it’s a project, not a setting.

In-app purchases

If you charge for anything in the app, Apple generally requires their in-app purchase system (with their 15–30% cut) — not Stripe in a webview. Wiring IAP through a wrapper means native store plugins and receipt validation on your backend.

Native login

Sign in with Apple is effectively mandatory if you offer third-party login on iOS, and biometric login (Face ID / fingerprint) needs native bridges. Your web auth flow will work in the wrapper, but it won’t feel — or pass review — like a native app’s.

Apple review

Apple explicitly rejects apps that are “just a website in a frame.” A bare wrapper around a desktop web layout is the classic rejection. You generally need genuine native functionality, a mobile-appropriate experience, and strict guideline compliance to get through.

None of this is a reason not to do it — plenty of successful apps are wrappers with real native bridges. It’s a reason to budget the project honestly instead of expecting a one-click publish.

Route two

The cleaner path: migrate first, then go native

Step back and notice what the wrapper is really doing: it’s a website wearing a native costume, still talking to Base44’s servers for everything. The auth, the database, the functions — all still rented, all still un-reachable, all still billed by the platform. You’ve added a store listing without fixing any of the ownership problems underneath.

The cleaner sequence is: migrate first, then build the mobile app against your own API. Once your app runs on infrastructure you own — your Supabase database, your backend, your auth — a mobile app becomes a proper native client talking to your API. Push notifications, IAP receipts, and native login all plug into systems you control. No costume, no review roulette, no platform in the middle.

That first step is what OffRamp does: your Base44 app rebuilt on Supabase, Vercel, and GitHub accounts in your name, with a real API your future mobile app can talk to. The App Store becomes a frontend project instead of a platform escape — which is what it should have been all along.

FAQ

Questions, answered honestly

Can I publish my Base44 app to the App Store?

Not directly. Base44 produces a web app, and neither Apple nor Google lists websites as apps. You need to wrap the web app in a native shell (Capacitor is the standard tool), submit that as your app, and pass store review.

Will Apple approve a wrapped web app?

Sometimes. Apple explicitly rejects apps that are just a website in a frame with nothing native about them. To pass review you generally need real native functionality, a mobile-appropriate experience, and compliance with the guidelines on payments and content.

Do push notifications work in a wrapped app?

Only with real native work: push credentials from Apple/Google, a service to send the pushes, and native code in the wrapper to receive them. The web app alone can’t do it — this is the feature that most often turns a “quick wrapper” into a real project.

Can I use Stripe for payments in my App Store app?

Generally not for digital goods — Apple requires in-app purchase (with their cut) for those. Physical goods and services are the exception. If your app sells digital features, budget for IAP integration, not a Stripe webview.

What’s the cleanest path from Base44 to the App Store?

Migrate first, then go native: move the app onto infrastructure you own, and build the mobile app as a proper client against your own API. OffRamp performs that first step — your app rebuilt on Supabase, Vercel, and GitHub in your name.

Build the foundation first. The app icon follows.

Connect your Base44 account from the OffRamp home page. The free analysis takes about a minute — what’s portable, every gap, and your fixed quote — and your Base44 app stays untouched throughout.

Start your free analysis