The app is through review. The developer account is paid for. The paywall screen is designed, the plan names are written, and there is nothing behind the button that takes money.
Base44’s store build runs your app inside a WebView with no native bridge to StoreKit, so in-app subscriptions cannot be added to it by you, by a vendor SDK, or by a developer you hire, as of 16 August 2026. Charge somewhere other than inside the app, or move the app into a shell you own.
This page is about what to do next. What a Base44 store build actually is, and whether Base44 can package a mobile app at all, is the earlier question with its own answer, and the end-to-end route from a Base44 build to a published listing is a separate walkthrough. Here the question is narrower: why the wall exists, which four routes get round it, and which part of that is worth paying someone for.
Everything below is read from Base44’s documentation, Apple’s App Store Review Guidelines, Google Play’s policy pages and RevenueCat’s documentation and support forum, all checked on 16 August 2026. No Base44 app was submitted or tested for this page. One Base44 owner, writing publicly in r/Base44 on 6 August 2026 and recorded in AxonBuild’s outreach corpus, put the discovery in one clause: “…base44 is a waste of time if you want app based paid subscriptions.” That reaction is what this page is trying to make cheaper.
What Apple’s rule actually says about charging inside an app
Apple’s App Store Review Guidelines put one rule at the centre of this, guideline 3.1.1. If your app unlocks features, functionality, premium content or a full version, that unlock has to be bought through in-app purchase, and your own mechanisms for unlocking it are not allowed. Subscriptions to your own app are named in the examples. Read on 16 August 2026.
Most people half-know that much. The clause underneath it gets missed, and missing it costs approvals:
“Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.”
Restore has to be designed in, and it has a firmer version on Apple’s subscriptions page. That gets its own section further down.
Apple takes a commission on every in-app purchase, at a standard rate and a lower one for smaller developers under its App Store Small Business Program, checked 16 August 2026. The rates themselves, and the annual fees, belong on a page about what publishing actually costs.
Why Base44’s own store build cannot do it, and why hiring someone does not help
Start with what Base44 publishes. Its store-submission documentation, read on 16 August 2026, tells owners not to put Stripe payments inside the mobile app for digital goods such as subscriptions or in-app features, because Apple and Google require their own billing for digital content, and says an app that does it anyway gets rejected. The same page describes a built-in StoreKit and Google Play Billing integration as something the company is working on. That is a documented absence with a date on it, and it could change any week.
The same page is much friendlier about the other half of commerce. Under the label “Physical goods and services” it says plainly: “Using Stripe is allowed in the app stores.”
What Base44’s docs do not explain is why the gap exists, and that is the part that decides whether money can solve it. RevenueCat’s community forum answered it in June 2026, in a thread from a Base44 owner trying to add a subscription paywall. The reply of 3 June 2026 carries RevenueCat’s staff badge on the thread page and says “Base44 is not a supported no-code builder from RevenueCat so we do not have directions on how to integrate but I can try to help with this.” Then the mechanism:
“When Base44 exports your app for the App Store, it creates a native iOS wrapper, but the app itself runs inside a WebView. RevenueCat’s iOS SDK needs to communicate directly with Apple’s native StoreKit framework.”
And the consequence, in the same reply:
“Because Base44 apps run inside a WebView, and Base44 does not currently provide a native bridge to StoreKit or RevenueCat’s iOS SDK, there currently is not a way to directly connect a Base44 mobile app to App Store subscriptions in the same way you would with a native iOS app. This would be the same whether RevenueCat was used in a Base44 app or not, as the missing piece is the native billing connection inside the Base44 app itself.”
That last sentence should change your shopping list. The missing piece sits inside the Base44 app, so a different billing vendor hits the same wall, and so does a better developer. Someone writing StoreKit code needs somewhere native to put that code and a bridge to call it from your app, and in a Base44 store build there is no such place as of 16 August 2026. Anyone who takes the job anyway is selling you hours against a wall. This is the sharpest example of the line between what can and cannot be fixed in a Base44 app.
The order people find this out in is the cruel part. The build works, review passes, then this:
…and now I’ve hit a roadblock in the final hour. Has anyone hit this roadblock and found a work around? Everything is done but this is stopping me from being able to charge a subscription for my app which was always the plan.
That is a Base44 owner writing publicly in r/Base44 on 3 August 2026, recorded in AxonBuild’s outreach corpus.
What you are selling decides which rule applies
Before choosing a route, check whether the rule reaches you at all. Apple writes its payment rules per kind of purchase, and plenty of Base44 apps sell something in-app purchase was never aimed at. Every row below is read from the App Store Review Guidelines and Google Play’s payments policy on 16 August 2026.
| What you charge for | Which rule | How you may take the money |
|---|---|---|
| Access to your app, premium features, a Plus tier | Apple 3.1.1, Google Play payments policy | In-app purchase and Play billing only |
| A physical product you ship | Apple 3.1.3(e), Play’s physical-goods exclusion | Stripe or Apple Pay, and in-app purchase is not allowed |
| A real-world service delivered off the phone: cleaning, delivery, a haircut | Apple 3.1.3(e), Play’s physical-services exclusion | Stripe or a card form, and in-app purchase is not allowed |
| A live one-to-one service between two people: tutoring, a consultation | Apple 3.1.3(d) | A payment method other than in-app purchase is permitted. One-to-few and one-to-many must use in-app purchase |
| Nothing inside the app, which is a free companion to a paid web tool | Apple 3.1.3(f) | Charge on the web, provided nothing is purchasable in the app and no call to action points outside it |
| Something bought on your website that the app then unlocks | Apple 3.1.3(b) | Permitted only if the same item can also be bought by in-app purchase inside the app |
Apple’s wording on the third row is direct: “If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.” The direction catches people out. For physical goods and real-world services, in-app purchase is the method Apple forbids.
For a booking app, a shop that ships things, a trades business taking deposits or a delivery service, rows two and three are the whole answer, Stripe stays fine, and the rest of this page is background reading.
The four ways to charge, ranked by how much control you keep
Four routes exist, and they trade money against control in fairly predictable ways. The same four routes from a web app onto phones, ranked by rejection risk rather than by money, make a different comparison. This list stays on the money.
- Sell on the web and keep the app free. Cheapest and fastest. You keep everything except your payment processor’s cut, and no store commission applies because no purchase happens in the app. The conditions come from Apple 3.1.3(f) and the United States carve-out in the next section, and they are strict about what the app itself may say.
- Skip the store and ship a progressive web app. No annual developer fee, no review queue, no commission, and no store listing either. Whether that trade works depends on how your customers find you, which is the older web app or native app question.
- Move the front end into a shell you own, then add billing there. RevenueCat’s staff answer of 10 June 2026 is explicit about what changes: “…if you have it in a native wrapper (Capacitor, React Native, native Swift app, etc.), RevenueCat should work because the wrapper contains native code that talks to StoreKit and RevenueCat.” RevenueCat’s installation documentation lists SDKs for iOS and Apple platforms, Android, React Native, Expo, Flutter, Kotlin Multiplatform, Cordova, Capacitor, Unity, Web and Roku, so the tooling is ordinary once there is somewhere native to put it. This is the only route that produces genuine in-app subscriptions, and it is a rebuild of the shell rather than a setting you switch. Your Base44 backend can stay where it is; what Base44’s exported code contains is what you are moving.
- Pay a vendor that supplies the native bridge for you. Several companies sell exactly this integration for Base44 apps, including
wanilla.co,appbuild.diyanddespia.com. Their domains stay unlinked here because they compete with the work AxonBuild sells. Two questions decide whether one of them is a good buy: whose Apple Developer account the app gets submitted under, which is a real guideline question rather than a formality, and what happens to your shipped build the month you stop paying.
A fifth line is to wait. Base44 says it is working on the integration, so if you are reading this well after 16 August 2026, open Base44’s store documentation and product changelog before planning around a gap that may have closed.
Selling on your own website: what the United States rule changed
Apple’s guideline 3.1.1(a) now treats the United States storefront differently from everywhere else, and the difference is large enough to change which route you pick. Read on 16 August 2026, it says entitlements for external purchase links “are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps”, and that the general prohibition applies “In all other storefronts, except for the United States storefront, where this prohibition does not apply”.
In plain terms, as of 16 August 2026: an app on the US storefront may point customers at your own website to buy. Outside the US storefront, the prohibition still stands and a link out needs one of Apple’s external purchase entitlements, which are limited to specific regions.
Treat that as a live legal position rather than settled law. The carve-out sits on top of ongoing litigation between Apple and Epic Games. The Supreme Court docket in Apple Inc. v. Epic Games, Inc., No. 25-1311 records the petition granted on 30 June 2026, limited to the first question presented, with briefing running to 14 September 2026 for Apple and 13 November 2026 for Epic, and no argument date set. Checked 16 August 2026. A business model that depends on linking out of a US app is exposed to whatever comes next.
Google’s rule is a different shape and needs checking separately. Play’s payments policy, read on 16 August 2026, requires Play’s billing system for in-app digital products, and allows alternative billing inside the app, or leading users outside it, only for developers enrolled in the applicable programs in eligible countries and regions. The user choice billing pilot lists its markets as European Economic Area countries, Australia, Brazil, Indonesia, Japan, South Africa, the United Kingdom and the United States, and requires among other things that the “Developer must be registered as a business”. Enrolment is the gate, not geography alone.
Your app needs a Restore Purchases button before Apple approves it
A Restore Purchases control is a shipping requirement for auto-renewable subscriptions on iOS. Apple’s subscriptions page lists it among the details a sign-up screen must include, and guideline 3.1.1 asks for a restore mechanism for any restorable in-app purchase. Both read on 16 August 2026.
Restoring means giving a customer back what they already paid for. Someone subscribes, then wipes their phone or reinstalls your app. The receipt lives with their Apple Account rather than in your database, so the app has to ask Apple what this person owns and switch their access back on without charging them twice.
Apple states the requirement in two places with two different strengths. Guideline 3.1.1 says you “should make sure you have a restore mechanism for any restorable in-app purchases”. The firmer one is on Apple’s subscriptions page, which lists what a subscription sign-up screen must include and names “A way for current subscribers to sign in or restore purchases” alongside the subscription’s name, duration and full renewal price. That covers exactly the screen a paid tier needs, so treat it as required there and strongly advised elsewhere.
If you get as far as route 3, the plumbing is already written. RevenueCat’s restoring-purchases documentation says “It is recommended that all apps have some way for users to trigger the restorePurchases method, even if you require all customers to create accounts.” One method, one button, requirement met.
One separation, because two different people search this. If you are a customer and something you bought has gone missing, Apple’s support page on what to do if you cannot find or use your in-app purchases is where to start. And if a rejection notice is already in hand, reading the guideline number Apple cited before changing anything saves a resubmission.
The Google Play side, and what “sell an app on Google Play” actually means
Selling on Google Play means one of three different things, and only one of them is about billing. Play’s payments policy requires Play’s billing system for in-app digital products, excludes physical goods and physical services outright, and allows alternative billing only through enrolment in a named program. Checked 16 August 2026.
The monetisation sense is the one this page owns. Play’s policy covers apps that require or accept payment for access to in-app features or services, and its published exclusions are broad and specific. They include physical goods such as groceries, clothing and electronics; physical services such as transportation, cleaning, airfare, gym memberships, food delivery and event tickets; credit card and utility bill remittances; peer-to-peer payments; online auctions; and tax-exempt donations. If your Base44 app sells any of those, Play billing is not required and Stripe is fine on Android too.
The other two senses go elsewhere. Selling the app itself as a paid download is a pricing decision inside Play Console. Selling your app as a business is a company sale, not a billing question.
One Android landmine is worth flagging before you rebuild anything. If you take route 3 and produce a new binary from a different toolchain, the signing key and package name Google already associates with your listing become a live problem, and an upload key that changes on a rebuilt Base44 binary is its own troubleshooting story.
What this costs you, and what is actually a one-result job
The hire-or-do-it-yourself question is the one Base44 owners are already asking each other out loud:
I’ve been researching options like GitHub, wrappers, RevenueCat, StoreKit and Google Play Billing, but I’d really like to hear from people who have actually done it with a Base44 app. What setup did you use? Did you need a developer, or were you able to handle it yourself?
That is a Base44 owner writing publicly in r/Base44 on 10 August 2026, recorded in AxonBuild’s outreach corpus.
Here is the honest boundary. Fixing one entitlement check that lets the wrong people through may fit AxonBuild’s $99 first job. It is available once to a new client for one agreed blocker and is completed within three business days once access works. You pay after seeing it work. Wiring up a new billing stack is larger work and is quoted after the code has been reviewed.
Moving a Base44 app off the WebView build into a shell you own, with billing attached and receipts validating, is not one small repair. Anyone quoting that move as one small repair is either doing something smaller or will be back later for the rest. For a good share of the people who land here, row two or row three of the table above means they never needed any of it.
Common questions about charging inside a Base44 app
Can I use Stripe for subscriptions in my Base44 app?
Not for digital subscriptions inside the mobile app. Base44’s store documentation, read on 16 August 2026, tells owners not to use Stripe for digital goods there, because Apple and Google require their own billing, and says the app gets rejected if you do. Stripe stays correct for physical goods, real-world services, and anything sold on your website.
Can I add RevenueCat to a Base44 app?
Not to a Base44 store build on iOS. RevenueCat’s staff answered this on 3 June 2026: Base44 is not a supported no-code builder, the app runs inside a WebView, and Base44 provides no native bridge to StoreKit or RevenueCat’s iOS SDK. RevenueCat’s Stripe Billing integration can take web purchases, which is a different thing from App Store subscriptions.
Has anyone actually shipped a paid Base44 app to the App Store?
Yes, at least one. AxonBuild’s outreach corpus records a Base44 owner posting in r/Base44 on 7 August 2026 that an AI companion app built on Base44 reached the App Store with a free tier and a paid tier. The post does not say where the money is taken, so it is no evidence that a store build charges in-app.
A subscription sold on the web fits that description equally well.
Do I have to give Apple a cut if people subscribe on my website instead?
No, if the purchase genuinely happens outside the app and the app is not selling the same unlock inside itself. Apple’s commission applies to in-app purchase. What the guidelines control is what the app may say about buying elsewhere, and guideline 3.1.1(a) plus the United States storefront carve-out decide that, as of 16 August 2026.
Does my app get rejected if there is no Restore Purchases button?
For an auto-renewable subscription, expect a problem. Apple’s subscriptions page names “A way for current subscribers to sign in or restore purchases” among the details a sign-up screen must include. Guideline 3.1.1 uses the softer “should” for restorable in-app purchases generally. Treat restore as required on a subscription paywall.
Is a progressive web app a real answer, or a downgrade?
A progressive web app is a real answer when your customers do not find you through the App Store. It installs to the home screen from a browser, costs nothing, has no review queue and takes no commission. What it gives up is store discovery, so the trade turns on how people arrive.
If I move to React Native or Capacitor, do I lose my Base44 backend?
No. Those routes replace the shell your app runs in and leave the data behind it alone. Your Base44 backend and its rules can stay where they are while the front end moves into a native container that can talk to StoreKit. The work and the risk sit in the move itself.
Before you spend anything
Two facts here have short shelf lives, both read on 16 August 2026. Base44 describes its StoreKit and Google Play Billing integration as work in progress, and that sentence could be replaced any week. The App Store rules on linking out of a US app are attached to litigation the Supreme Court has agreed to hear.
Base44 is also not alone in this, and which AI builders can make mobile apps with native billing attached differs from one builder to the next.
So the first move is not a purchase. Find your row in the table, then reopen Base44’s store documentation and Apple’s guideline 3.1.1 and check whether the answer still holds. Plenty of people will sell you a bridge before you have established that you need one.
Need this fixed in your own app?
New clients can start once with one agreed blocker for $99. We fix it within three business days once access works, and you pay after seeing it work.
