Base44 App Store Rejection — No StoreKit / In-App Purchase

What's happening

Apple rejects Base44 iOS apps that sell digital goods under App Store Review Guideline 3.1.1, which requires in-app purchase for subscriptions, in-game currencies and premium content. Base44 has generated App Store files itself since 3 February 2026, but its docs list in-app purchases as "Not yet" supported and say RevenueCat and Capacitor purchase plugins do not work on its builds, so a Stripe checkout for digital content inside the app is rejected. Three paths work: move the purchase to the web version of your app, build a native iOS shell that owns StoreKit, or migrate to a stack with native in-app purchase.

You built a SaaS or content app on base44, generated the App Store file from the editor's Mobile app tab (or wrapped the app yourself), paid your $99-a-year Apple developer fee, and submitted, following what looks like the full path to shipping on the App Store. Then the rejection arrived. It cites Guideline 3.1.1: your app sells digital subscriptions or content without in-app purchase. You go back to the Mobile app tab and there is no StoreKit option to enable.

Base44's own documentation confirms the gap. Asked "Can I charge for digital content in my mobile app?", the store-submission docs answer: "Not yet. Apple and Google both require their own billing systems for anything digital, and Base44 does not support them yet, so the purchase has to happen on the web for now." A second rejection risk sits under Apple's Guideline 4.2 (Minimum Functionality): "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."

The combined effect is that a base44 app cannot sell digital goods inside its iOS build today, and a thin app faces the minimum-functionality rule even when it is free. Teams discover this after building, after paying for the developer account, and after burning credits on iOS-specific tweaks that the agent suggested but Apple does not care about.

Why this happens

Apple's App Store Review Guideline 3.1.1 is unambiguous: if you gate features or functionality in your app, such as subscriptions, in-game currencies, game levels or access to premium content, "you must use in-app purchase." Guideline 3.1.3(e) sets the other side of the line: physical goods and services "consumed outside of the app" must use purchase methods other than in-app purchase. Stripe belongs on that side, not on the digital one.

StoreKit itself is a native iOS framework. Implementing it requires Swift code, certificate provisioning, App Store Connect product configuration, server-side receipt verification, and handling of edge cases like family sharing, refunds, and subscription state changes. None of this fits an AI-generated web app architecture.

Base44's App Store build is, in its docs' words, "a lightweight native wrapper around your web app that opens only your app's URL." The web app runs inside the web view, and the native layer underneath is not exposed to it. That is why the same docs say "RevenueCat's native SDK and Capacitor in-app purchase plugins need access to the native layer that Base44 apps do not expose, so they do not work, they can break your build, and they still get your app rejected." Even with a bridge, the server-side receipt verification and subscription state machine would still need to live on a stable backend, which the base44 SDK is poorly suited to host.

The platform-level fix is on Base44's roadmap, not in the product. Its docs state: "We are working on a built-in integration for StoreKit and Google Play Billing to handle digital purchases and keep your app compliant." No date is given, so plan around the build that exists today.

The minimum-functionality rule (Guideline 4.2) compounds the issue. Even a fully free app is judged on whether it offers more than "a repackaged website", and push notifications are the only native feature Base44's build documents.

Sources: Apple App Review Guidelines (3.1.1, 3.1.3, 4.2), read 23 Sep 2026; Base44 docs, Submitting your app to app stores, read 23 Sep 2026; Base44 product changelog, entry of 3 February 2026 ("Submit apps to the app stores").

How to test if you are affected

Skip reproduction; submitting to the App Store costs you a real review slot. Instead, audit your app:

1. Does your iOS app sell digital subscriptions, premium content, virtual currency, credits, or extra AI generations? Base44's docs count all of those as digital, and add: "If you are not sure which yours is, treat it as digital. Apple in particular rejects borderline cases." If yes, you will be rejected under 3.1.1 unless the purchase moves out of the app or into StoreKit.
2. Does anything in the app open a payment flow, including a Stripe checkout inside the web view? Base44's docs say any link you keep must open a browser rather than a payment flow inside the app.
3. Does the app offer anything beyond the website? If not, the Guideline 4.2 risk applies too.
4. Run Publish → Mobile app → Check Your App → Run App Scan against the App Store guidelines. Treat it as a pre-check, not a verdict: Base44 "cannot guarantee that an app is approved, even with a high readiness score."

If those checks return concerning answers, treat App Store launch as blocked until you choose one of the workaround paths below.

Step-by-step fix

Base44's own build cannot run StoreKit today. The fixes are workarounds and architectural changes.

Path A: Paid on the web, the app checks who has paid (lowest effort)

This is Base44's documented route. Sell the subscription on the web version of your app with Stripe; the iOS app reads the user's account state from your backend and shows or hides paid features accordingly.

Steps (Base44's recovery procedure, with our notes):

1. Move the purchase to the web version of your app, so people pay there rather than inside the mobile app.
2. Remove any button in the app that opens a Stripe checkout. If you keep a link, it must open a browser, not a payment flow inside the app.
3. Add a server-side check (for example user.subscriptionActive) and gate paid features on the server response.
4. Publish the change in Base44 and generate your app files again from the Mobile app tab.
5. Reply to the reviewer through Apple's Resolution Center (or Google Play's appeals process), explaining that the purchase now happens on the web.
6. Resubmit. If the reviewer also raises Guideline 4.2, make sure push notifications are switched on and the app does something useful on a phone; native features beyond push need Path B.

Read Apple's 3.1.3 before relying on this path, because it is narrower than Base44's summary. Base44's docs allow a paywall that points people to your website. Apple says apps under 3.1.3 "cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a)." Two sub-rules then decide whether web-only purchase is enough: 3.1.3(b) lets a multiplatform app give access to content bought on your website "provided those items are also available as in-app purchases within the app", while 3.1.3(f) covers free apps acting as "a stand-alone companion to a paid web based tool", provided "there is no purchasing inside the app, or calls to action for purchase outside of the app." If your app fits neither and you sell outside the United States storefront, Path B is the safer route.

Expect 1–2 weeks of work plus 1–2 review rejection cycles before approval.

Path B: Native iOS shell with StoreKit (medium effort)

Build a thin native iOS app in Swift that handles StoreKit, account state, and a small set of native screens. The base44 app is embedded as one tab via WebView, used for the non-payment portions of your product. This shell is yours, not Base44's, so you control the native layer that Base44's build does not expose.

Steps:

1. Create a new Xcode project (SwiftUI recommended).
2. Configure subscription products in App Store Connect.
3. Implement StoreKit 2 purchase, restore, and entitlement-check flows.
4. Implement server-side receipt verification on a stable backend (not base44).
5. Embed the base44 app via WKWebView for the rest of your UX.
6. Sync user state between the native shell and base44's backend via the SDK or a REST bridge.

Decide this before your first submission if you can. Base44's docs warn that when a build's Bundle ID or signing key does not match the version already listed, the stores block the update, and the values inside Base44's generated files cannot be changed. Switching between a Base44-generated build and your own shell on the same listing can hit that wall.

Expect 3–6 weeks of native development plus testing.

Path C: Migrate off base44 (high effort, durable)

Rebuild the app on a stack that supports both web and native iOS natively: React Native + Expo, or Flutter, or pure SwiftUI for an iOS-first launch. Move the backend to Supabase, Firebase, or a custom Node/Postgres setup so you are no longer tied to the base44 SDK.

Expect 4–10 weeks of engineering depending on app complexity. This is a vendor lock-in escape, not a fix sprint.

DIY vs hire decision

DIY is realistic only for Path A. The storefront rules on pointing people to the web purchase are subtle, and a paywall that reads as a call to action to buy outside the app can bring a second rejection under 3.1.3.

Path B requires real iOS engineering plus server-side receipt verification, which is Swift and backend work the Base44 editor cannot do for you.

Path C is a full migration. Hire someone who has done it before; the wrong stack choice is expensive to undo.

Need this fix shipped this week?

For Path A workarounds we run a fix sprint: 1 week to compliant build plus support through review cycles. For Paths B and C we run as a complex multi-bug fix or migration project.

Book a complex fix or book a free 15-minute call to scope the right path for your app.

Related problems

• Vendor lock-in via SDK dependency — Path C escape requires decoupling from the base44 SDK.
• Stripe integration breaks after updates — Stripe still carries your web revenue under Path A, so that integration has to stay stable.
• Getting the web version of your app into Google — if the purchase lives on the web, the web app has to be found on its own. Base44 serves crawlers a prerendered version of each page, so the gaps to close are configuration ones: the SEO toggle, per-page meta descriptions and pages left behind a login.