1. Home
  2. Guides
  3. Deploy to App Store & Google Play

How to Publish a Base44 App to the Apple App Store

By the apprat.io AI Code Engineering Team 8 min read

In short: A Base44 app runs on the web, so publishing to the Apple App Store means wrapping it in a native iOS app, adding native functionality, and passing App Review. apprat.io's Base44-to-App module and AI Code Engineers handle packaging, device testing and submission.

Base44 lets you describe an application and get a working product with a built-in backend, data and authentication. That is a strong start, but the App Store is a different gatekeeper than the web. This guide focuses on what to check in a Base44 app before and during an iOS release.

Start with the backend, not the wrapper

Because Base44 bundles hosting, database and authentication, your mobile app will depend on that platform at runtime. Before packaging anything, answer these questions:

  • Who owns the production data, and can you export it? Check Base44's current documentation and terms.
  • Does the login flow work inside an embedded browser view, including password reset and email verification?
  • Which user roles and permissions does the app enforce, and have they been tested with real accounts?
  • What happens when the platform is slow or unreachable? The app needs a useful error state.

If you expect significant growth, read our notes on scaling a Base44 app as well.

Packaging the app for iOS

The web app is placed in a native iOS container. A well-built container handles safe areas around the notch, keyboard behavior, pull-to-refresh, external link handling and file uploads. Without that polish, the app feels like a browser tab, and reviewers notice.

Add at least one real native capability. Typical candidates are push notifications, biometric unlock, camera or photo access with a clear purpose, share extensions, or offline reading of key content.

What App Review looks for

Apple evaluates apps against the App Store Review Guidelines. For wrapped web apps, Guideline 4.2 (Minimum Functionality) is the one most often cited. Others that matter for Base44 apps:

  • Account deletion: if users can create an account, they must be able to delete it in the app.
  • Demo access: give the reviewer working credentials and notes explaining each feature.
  • Privacy: the privacy policy and nutrition labels must reflect real data flows, including anything the platform collects.
  • User-generated content: apps with it typically need reporting and blocking mechanisms.

Verify the current wording on Apple's site; guidelines evolve. For a deeper look, see our Guideline 4.2 article.

Designing for the reviewer

An App Review session is short. The reviewer opens the app, tries to log in, taps through the main features and checks the policies. Make that path easy. Provide a demo account with realistic sample data, so that screens are not empty. Write review notes in plain language: what the app is for, which features need an account, and which native capabilities are included. If a feature depends on a server that is only reachable at certain times, say so. Reviewers are far more forgiving when the notes explain than when they hit a dead end.

Also consider in-app purchases. If you sell digital content or subscriptions inside the app, Apple's payment rules apply, and a payment link that points to your website can cause a rejection. Our guide on in-app purchases for AI-built apps explains the options.

How apprat.io works on a Base44 project

Our Base44-to-App module converts your project into iOS and Android apps. Coding agents accelerate the repetitive work, and an AI Code Engineer plans the architecture, reviews every change, tests on physical iPhones and iPads, and submits the build. If something is rejected, the same engineer reads the reviewer message and fixes it, rather than leaving you with a generic error. Our processes follow ISO 9001 and ISO 27001, and EU hosting options support GDPR requirements. For a quick feasibility check, book a call for free.

Timeline you can plan around

  1. Week 0: Apple Developer account in place (organization accounts need extra verification time).
  2. Packaging and native features: depends on scope; a simple wrapper is quick, native features take longer.
  3. TestFlight beta: internal testers first, then external if needed.
  4. Submission and review: allow room for at least one round of feedback.

Need Android as well? Continue with publishing a Base44 app to Google Play.

Frequently asked questions

Can Base44 publish directly to the App Store?

Base44 produces a web app. Publishing to the App Store requires a native iOS package, signing and a submission through App Store Connect, which a service like apprat.io can provide.

Does my Base44 backend still work in the mobile app?

Generally yes, because the app talks to the same backend as the web version. You should test authentication, permissions and error handling on real devices.

What is the biggest rejection risk?

Guideline 4.2 on minimum functionality, plus missing demo credentials or account deletion. Native features and clear review notes lower the risk.

Do I need an organization Apple account?

If you publish under a company name, yes, and that involves verification such as a D-U-N-S number. Individuals can publish under their own name.