Can I just use Stripe for iOS subscriptions and avoid StoreKit?

No, not for digital goods. Apple's Guideline 3.1.1 requires StoreKit / In-App Purchase for digital content, subscriptions, and consumables. Stripe is allowed only for physical goods, real-world services, person-to-person services, and a few other exceptions. App reviewers reject digital-subscription apps that route payment through Stripe, and the rejection is non-negotiable. The 30% Apple fee is the price of being on the App Store.

Is there any workaround that keeps the base44 app on iOS with paid features?

Three paths exist. First, restrict iOS to a free tier and let users subscribe on the web; the iOS app then unlocks features via account state. Apple permits this if the iOS app does not link to or mention the external purchase. Second, build a thin native iOS shell that handles StoreKit and embeds the base44 app for non-payment functionality. Third, migrate off base44 to a native or React Native stack.

Why doesn't base44 add StoreKit support?

StoreKit requires Swift/Objective-C bridges, native iOS app review handling, and certificate management — none of which fit base44's web-first AI agent architecture. Adding it would mean the platform supports native mobile development, which is a fundamentally different product. Base44's mobile story is web-app-as-PWA-or-wrapper, and StoreKit support is unlikely to ship in 2026.

What does the rejection email actually say?

Reviewers cite Guideline 3.1.1 — In-App Purchase. The rejection states that apps offering digital subscriptions, content, or features for purchase must use StoreKit. They reference your app's payment flow and require resubmission with StoreKit integrated. Repeated rejections can lead to account-level review escalation, so do not just resubmit hoping for a different reviewer.

Is the web-view wrapper approach itself a separate rejection risk?

Yes. Apple Guideline 4.2.2 rejects apps that are essentially a web view wrapping a website — the documented base44 issue. Even fully free apps with a web-view-only interface get rejected for not providing native iOS functionality. Combined with the StoreKit issue, base44's iOS export is in a tough position with App Review. Android (Google Play) is more permissive.

How long does the migration to native or React Native take?

For a typical base44 app of moderate complexity (5–15 screens), a clean rebuild in React Native with StoreKit takes 4–10 weeks depending on backend complexity. The bulk of the work is not the UI but porting the base44-SDK-coupled backend logic to a stable backend (Supabase, Firebase, or custom). We size and quote this as a migration, not a fix.

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

What's happening

You built a SaaS or content app on base44, exported it to iOS, paid your $99 Apple developer fee, and submitted to the App Store. Two days later you got rejected. The rejection cites Guideline 3.1.1 — your app sells digital subscriptions or content but does not use StoreKit / In-App Purchase. You point at base44's mobile export and there is no StoreKit option to enable.

A user on the feedback board summarized it: "Cannot offer subscriptions inside iOS app; missing StoreKit/In-App Purchase support." This is the post that catalogues the problem under "Apple In-App Purchase StoreKit". A separate but related rejection cites Guideline 4.2.2: "Apps that are essentially a web view wrapping a website are routinely rejected."

The combined effect is that base44 apps with paid content effectively cannot ship to iOS. Free apps face the web-view-wrapper rejection separately. 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. Digital goods, subscriptions, and consumable content must use StoreKit / In-App Purchase. The rule has been enforced since 2011 and Apple's enforcement got stricter in 2023–2024 after antitrust scrutiny. Stripe and other web-payment processors are explicitly disallowed for digital goods on iOS. The 30% Apple fee — sometimes 15% for small developers — is the cost of being on the platform.

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 mobile export wraps your web app in a WebView container. The web app runs inside the WebView. There is no Swift-level bridge between the WebView's JavaScript context and the host iOS app's native StoreKit calls. Even if base44 added a primitive 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 deeper architectural mismatch: base44 was designed to ship web apps fast with an AI agent. iOS in-app purchase is a complex, heavily-regulated payment subsystem that Apple owns end-to-end. The two stacks do not connect, and there is no realistic platform-level fix.

The web-view-wrapper rejection (Guideline 4.2.2) compounds the issue. Even if you somehow avoided the IAP problem (for example, a fully free app), Apple's reviewers reject apps that offer no native value beyond a website. Base44's iOS export, by design, is a website in a wrapper.

Source: developer.apple.com/app-store/review/guidelines (3.1.1, 4.2.2); feedback.base44.com Apple In-App Purchase StoreKit thread; multiple reviews documenting actual rejection emails.

How to test if you are affected

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

Does your iOS app sell digital subscriptions, premium content, virtual currency, or unlock features for money? If yes, you will be rejected for 3.1.1 unless StoreKit is integrated.
Does your iOS app deliver any native iOS-only feature beyond the web app? If no, you may also be rejected for 4.2.2.
Have you tested submission yet? Apple's automated pre-checks do not catch these — only human reviewers do, on the third or later submission.

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

Step-by-step fix

There is no way to make base44 native-StoreKit-compatible. The fixes are workarounds and architectural changes.

Path A: Free iOS, paid web (lowest effort)

Restrict the iOS app to a free tier. Let users sign up and subscribe on your website. The iOS app reads the user's account state from your backend and unlocks paid features accordingly.

Apple permits this with a critical constraint (Guideline 3.1.3): the iOS app must not link to, mention, or in any way direct users to the web purchase flow. No "subscribe at example.com" copy, no in-app browser to your pricing page, nothing.

Steps:

Remove all purchase, pricing, and subscription UI from the iOS app build.
Add a server-side check: user.subscriptionActive reads from your backend.
Keep paid feature flags client-side, gated by the server response.
Submit. If the reviewer pushes back on Guideline 4.2.2 (web-view wrapper), implement at least one native iOS feature (push notifications via APNs, Sign In with Apple, native share sheet, biometrics).

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.

Steps:

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

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 constraint of not mentioning external purchase is subtle — most teams trip over it on the second review cycle, then escalate to specialist help anyway.

Path B requires real iOS engineering plus server-side receipt verification. Few base44 builders have that skillset.

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.

Vendor lock-in via SDK dependency — Path C escape requires decoupling from the base44 SDK.
Stripe integration breaks after updates — Stripe still works for web revenue; you need that path stable.
CSR makes apps invisible to Google — if iOS is restricted, your web app must rank on its own.