Base44 to App Store: how to publish a real iOS app

Short answer: Base44 can generate the App Store file

Base44 now includes a Mobile app flow that scans a published app against store guidelines and generates an App Store-ready IPA on the Builder plan or higher. The resulting iOS app is a secure web-view wrapper that opens the live Base44 URL.

You still need your own Apple Developer account and App Store Connect listing. Base44 does not submit the app, monitor review, speak to Apple or guarantee approval. That remaining release path is the work this guide covers.

What Base44 handles and what remains yours

Choose between three release paths

Do not rebuild merely to look more technical. Start with the Base44-generated package unless a verified product requirement exceeds it.

Know the limits of the built-in Base44 wrapper

Base44 documents its mobile package as a web view that loads the published application. That makes content and design updates fast, but the current wrapper does not support every native capability.

• No native push notifications in the built-in Base44 mobile app
• No full offline mode
• No HealthKit support
• The mobile start URL is selected from the published app and cannot be independently configured
• Device permissions are inferred and are not editable in the Base44 interface
• Bundle ID and signing identity are generated by Base44 and cannot be changed inside the output package
• A previous native listing may not accept the Base44 build if its identifier or signing identity differs
• Deep platform integrations may require an exported/custom runtime

These are architecture constraints, not automatic reasons to reject the platform. Decide whether any one of them blocks the actual product.

Run the Base44 mobile scan and verify the result

1. Publish the current Base44 app to a stable URL.
2. Open Publish → Mobile app → Check Your App.
3. Run the App Store guideline scan.
4. Review passed, partial and failed checks.
5. Apply or adapt the suggested fixes.
6. Publish again and rerun the scan.
7. Manually test every critical journey on a real iPhone.

A high readiness score is useful triage. Base44 itself notes that 100 is not required and approval is not guaranteed.

Test the product as an installed mobile app

Browser preview does not prove the signed build. Test the exact IPA through TestFlight and treat mobile behavior as a product pass.

• Cold start, resume and session restoration
• Sign-up, login, logout, password reset and account switching
• Keyboard, focus, safe areas, scrolling and back navigation
• Camera, files, location and every requested permission
• Slow, offline and failed-request states
• External links, downloads and return to the app
• Checkout, cancellation, refunds and restored access
• Privacy policy, terms, support and account deletion before login where required
• Empty, loading, error and permission-denied states
• Small and large iPhones plus the supported iPad behavior

Audit Base44 data access before inviting reviewers

Base44 provides managed data, authentication and backend functions. Store packaging does not prove that the authorization model is safe.

• Map anonymous, authenticated, owner, staff and administrator roles
• Verify row-level rules for create, read, update and delete
• Verify field-level rules for sensitive fields
• Attempt cross-account reads and writes with two real test users
• Keep privileged work in backend functions, not browser code
• Store third-party credentials as secrets
• Review file access, public URLs and connected integrations
• Run Base44 security scan after meaningful schema or permission changes
• Document data retention, export and deletion behavior

The mobile client continues to use the same Base44 backend, so a permissions error becomes a mobile production incident too.

Understand what code export does not export

On Builder or higher, Base44 can sync code with GitHub or export a ZIP. The export includes client-side code, assets and backend functions; database collections can be exported separately as CSV.

Managed hosting, the authentication system and database infrastructure are not exported. An exported frontend can continue using the Base44 backend. Moving it to another backend is a separate migration project.

• Decide whether Base44 remains the production backend
• Record app ID and backend URL outside the builder
• Keep source in a repository owned by the business
• Confirm the app builds from a clean checkout
• Document how functions, entities, auth config and secrets deploy
• Export data before any backend migration
• Test identity and authorization again after changing the client runtime

Use GitHub sync deliberately

Base44 supports two-way GitHub sync on Builder and higher. It is useful for source ownership and local development, but the connection changes the project workflow.

• Only the app owner should perform the initial connection
• Use a repository owned by the company, not a contractor
• Protect the main branch and review changes
• Know that Base44 syncs changes automatically rather than through a manual push button
• Base44 currently expects the branch to be named main
• After linking, older Base44 Version History entries from before the connection cannot be restored through the new repository
• Keep build and release instructions in the repository

Fix authentication in the signed environment

Test authentication from TestFlight, not only the Base44 browser preview. The web-view runtime can expose callback, cookie and identity-provider assumptions.

• Email/password registration and reset complete inside the app
• Google, Apple and other social login return to the correct app state
• Cancelled and failed OAuth attempts recover cleanly
• Session persistence survives app termination and upgrade
• Protected screens do not flash private data before authorization completes
• Review credentials do not require an unavailable second factor
• Sign in with Apple is added when Apple policy requires equivalent login choice
• Account deletion is discoverable inside the app when account creation exists

Resolve payments before generating the final IPA

Base44 distinguishes physical goods and services from digital goods. Stripe can remain appropriate for physical commerce, but digital features, content or subscriptions sold inside an iOS app generally require Apple in-app purchase.

• Classify every paid item as physical, service, reader access or digital entitlement
• Remove in-app Stripe checkout for digital access unless a current policy exception clearly applies
• Create App Store products and stable identifiers
• Implement purchase, pending, cancellation, restore, refund and revocation behavior
• Keep entitlement state consistent with the Base44 user
• Provide reviewer credentials and explain the paid path

Base44 currently says it is working on built-in StoreKit and Google Play Billing support. If digital monetization is required now, verify the current product capability before choosing the built-in wrapper; an exported/custom native layer may be necessary.

Prepare privacy, terms and account deletion

Apple evaluates the app’s real data behavior, not the builder used to create it.

• List user data collected by the app, Base44, analytics, payments and integrations
• Map each data type to use, sharing, retention and deletion
• Keep privacy policy and terms reachable before sign-up
• Add a support URL that works without authentication
• Disclose camera, microphone, photos, location and other device access accurately
• Provide in-app account deletion when users can create accounts
• Verify that deletion covers Base44 entities, files and connected systems
• Align App Store privacy labels with the actual production configuration

Check Apple minimum functionality

A web-view implementation is allowed, but the installed product still needs durable user value and a complete mobile experience.

• The primary task works well on a phone
• The app contains useful product functionality
• Navigation and controls fit touch devices
• Loading and network failure do not leave a blank shell
• Core functionality works without forcing users into Safari
• The listing accurately describes the product delivered in review
• Reviewer notes explain why an installed app is useful

Generate the IPA without mishandling Apple credentials

1. Enroll in the Apple Developer Program and create the App Store Connect app record.
2. Create an App Store Connect API key with the role required by Base44.
3. Record the Issuer ID, Key ID and Apple Team ID.
4. Upload the .p8 key only to the trusted Base44 build flow.
5. Generate and download the IPA from Publish → Mobile app.
6. Store the build and release evidence in a controlled project folder.
7. Revoke and replace the API key if exposure is suspected.

Apple allows the private key file to be downloaded only once. Treat it as a production secret, not as an email attachment.

Create the App Store Connect record and listing

• App name, primary language and bundle identifier
• SKU and team ownership
• Subtitle, description and keyword field
• Category, age rating and content rights
• Pricing and availability
• Privacy policy, support and marketing URLs
• App privacy disclosures
• Export compliance and encryption answers
• Phone and tablet screenshots for supported devices
• Review contact, demo account and detailed review notes
• Release mode: manual, automatic or phased after approval

Do not let AI-generated metadata claim features the signed build does not provide.

Use TestFlight as the release candidate gate

Upload the generated IPA and test the processed build before submission.

• The build installs under the intended developer team
• App name, icon, orientation and version are correct
• Authentication and all critical journeys work
• Production backend and integrations are selected
• Legal and support links open without login
• Payment behavior matches App Store policy
• Analytics and crash reporting identify the version
• External testers can understand the product without builder context
• No secrets, preview labels or internal controls appear
• A clean account can complete the reviewer path

Submit with evidence that removes reviewer ambiguity

Review notes should be operational, not promotional.

• Explain the app’s main purpose in one paragraph
• Provide a working demo account and any required role
• Give exact steps to reach non-obvious features
• Explain physical versus digital payments
• Describe account deletion location
• Explain permissions and the moment each is requested
• Call out content that changes from the Base44 backend
• Provide contact details for a person who can answer quickly

Base44 stops at file generation. Monitor App Store Connect, answer Apple and make the requested product or metadata change.

Plan updates before the first release

Most published Base44 content and design changes appear in the web-view app without a new store version. A new IPA is still required when the shell, identity or permissions change.

• Keep the published Base44 URL stable
• Do not surprise users with materially different functionality after review
• Regenerate and submit when the name, icon, package identity or device permissions change
• Retest authentication and payments after backend or integration changes
• Track which Base44 version and settings correspond to each store release
• Maintain a rollback and incident path for breaking web deployments
• Re-run security and store scans after meaningful changes

Common Base44-to-App-Store failure modes

What App Release Ops can own

Because Base44 already generates the IPA, a straightforward project should not automatically be priced like a custom mobile conversion. The audit decides whether the $450 publishing path is enough.

Send these materials for a useful scope

• Published Base44 URL and app owner access
• Current Mobile app scan results
• Target App Store country and release date
• Apple Developer and App Store Connect status
• Whether an App Store listing or bundle identity already exists
• User roles and a reviewer-ready test account
• Payment model and every paid item
• Integrations, permissions and sensitive data
• Required native features such as push, offline, HealthKit or background work
• Any generated IPA error or Apple rejection message

Official implementation references

• Base44: submitting your app to app stores
• Base44: mobile experience and export limits
• Base44: GitHub integration
• Base44 backend features
• Base44 row- and field-level security
• Apple App Review Guidelines
• Apple: upload builds to App Store Connect
• Apple Developer roles

Related release paths

• Apple App Store publishing service
• Mobile app creation service
• Best mobile app builder comparison
• Production readiness audit
• Store monetization setup
• Mobile app launching checklist
• App Store rejection diagnostic