How To Add Subscriptions Before Publishing An AI-Built App

You built a working product with an AI app builder in a weekend. The hard part starts now: turning that build into a paid iOS product ready for Apple's review. This guide walks through how to add subscriptions for AI-built apps before you hit submit, so your first release earns revenue instead of collecting another rejection notice.

Why subscriptions ship before release

Founders shipping from tools like Lovable, Replit, Base44 and v0 usually treat monetization as a version-two problem. On the App Store it is a version-one problem. Apple reviews the paid experience, not just the free one, and a product with no purchase path is judged on whether it has enough standalone value to exist at all under guideline 4.2.

There is a commercial argument too. Every install you buy or earn before the paywall exists is a user you cannot monetize twice. Cohorts that land on a free-only build convert at a fraction of the rate of cohorts that see an offer in the first session. Building the paid flow first also forces you to answer the only question that matters: what would somebody pay for here?

The third reason is technical. Retrofitting purchases into a shipped app means re-signing, re-testing and re-submitting. Doing it up front costs a day. Doing it later costs a release cycle. Our App Store readiness checklist treats the paywall as a launch gate for exactly that reason.

The three-layer subscription stack

Every compliant iOS subscription has three layers, and AI builders only give you the top one. The presentation layer is your paywall screen — the copy, the plan selector, the trial badge. The transaction layer is StoreKit, which Apple requires for digital goods. The entitlement layer is the server-side record of who paid for what, which your backend reads before unlocking anything.

Web builders hand you a Stripe checkout, which sits in the wrong layer entirely. Inside an iOS app, a Stripe checkout for digital content is an instant rejection. The fix is to sell digital subscriptions inside the iOS app through Apple in-app purchase, while your website keeps its own billing for web customers. See how we do this for Replit builds and Base44 builds.

Get the three layers straight and everything else in this guide is plumbing.

Step 1: Define what the paid tier unlocks

Write one sentence: free users get X, paying users get Y. If you cannot write it, your paywall will not convert and your reviewer will not understand the app. Strong splits for AI-built products are usage volume, history and export, automation, and anything that costs you money per request.

That last one matters. If your app calls a model on every tap, your marginal cost scales with usage, and an unlimited free plan will bankrupt the product before it grows. Gate the expensive path, keep the cheap path open, and let the free tier prove value fast. Our paywall strategy hub covers where to place the gate for each app category.

Decide before you build: one paid tier or two. One tier converts better at launch. Two tiers help later, once you know which segment upgrades. Start with one.

Step 2: Price around real cost

Price from the bottom up. Take your per-active-user infrastructure cost, add Apple's commission, add refunds, and set the floor. Then price to the value of the outcome, not the cost of the code. Most AI-built consumer apps land between $4.99 and $12.99 monthly, or $2.99 to $6.99 weekly.

Weekly plans dominate the consumer charts because they lower the entry barrier and pair well with a three-day trial. They also churn hard, so only run them with retention hooks in place. We break down the mechanics in the weekly subscriptions guide, with variants for Replit and Base44 builds.

Enrol in the Apple Small Business Program on day one. Under a million dollars in annual proceeds, your commission drops from 30% to 15% — the single largest margin lever available to a pre-launch founder. Details for Replit and Base44 teams are identical in substance.

Step 3: Create products in App Store Connect

Products live in App Store Connect, not in your code. Create a subscription group first — every plan a customer can switch between belongs in the same group, so upgrades and downgrades prorate correctly. Then create each product with a stable identifier you will never rename.

For each one you need a display name, a description, a price tier per territory, a review screenshot of the paywall, and localisations for every language you list. Missing localisation is the quietest rejection cause we see. Add the introductory offer here too, not in your client.

Do this before you build the paywall, because the identifiers you create become the contract between your app and Apple. Our in-app purchases walkthrough shows the exact fields, as do the Replit and Base44 versions.

Step 4: Wire StoreKit 2 into the native app

Purchases run through StoreKit 2 in native code: the app fetches products, shows prices, runs the transaction and reports the result back.

StoreKit 2 makes this far less painful than the old receipt-validation dance. Transactions are verified by the system, entitlements are queryable at any moment, and renewals arrive without polling. What you still owe is server-side verification, because a client that grants its own entitlement will eventually be told to grant one it did not earn.

If you do not have an iOS app yet, start with Build for iOS — the same path exists for Replit and Base44 projects — then layer purchases on top.

Step 5: Build a paywall that converts

A native paywall beats a web paywall on both conversion and compliance. It loads instantly, it reads system pricing in the customer's own currency, and it never shows a broken layout mid-scroll. Keep the structure boring: outcome headline, three proof points, plan selector with the annual option pre-selected, a single primary button, and the legal row underneath.

Three things move the number more than design does. First, timing — a paywall shown after the first moment of value converts better than one shown on launch. Second, honesty about the trial: say when the charge lands. Third, one decision per screen.

Templates and code live in our native paywalls guides for Replit and Base44, plus the screen-level iOS paywall patterns for Replit and Base44.

Step 6: Restore, entitlements and refunds

Apple requires a visible Restore Purchases control on any screen that sells something. It is a one-line requirement and one of the top three reasons paid apps get bounced. Put it in the paywall footer and in settings.

Behind it, your entitlement service should be the only thing that decides access. The client asks "is this account entitled?" and the server answers from verified transaction state. That design survives refunds, family sharing, billing retries and account switches. Implementation notes: Lovable, Replit, Base44.

Handle the grace period explicitly. When a renewal fails, Apple keeps the subscriber in billing retry for days. Treat them as entitled and prompt gently — cutting access immediately turns a recoverable payment issue into a churned customer.

Step 7: Test in sandbox before you submit

Sandbox testing is the step everyone skips and everyone regrets. Create sandbox accounts in App Store Connect, sign out of the production account on device, and run the full matrix.

• Fresh purchase — trial starts, entitlement unlocks, receipt verifies server-side.
• Renewal — sandbox compresses a month into minutes; confirm access persists.
• Cancellation — access continues to period end, then stops.
• Restore — reinstall, tap restore, entitlement returns without a second charge.
• Upgrade and downgrade — proration behaves and only one plan stays active.
• Offline and interrupted — kill the app mid-purchase; the transaction completes on relaunch.
• Refund — revoked transactions remove access on next check.

Log every step. When review asks how purchases work, that log becomes your answer.

Step 8: The review metadata Apple checks

Reviewers open your paywall within the first minute. Make sure the surrounding paperwork matches it. You need the subscription length, price and content clearly stated in the binding, functional links to your terms and privacy policy, and an App Store description that repeats the same terms.

Your privacy nutrition labels must reflect every SDK you ship, including analytics and attribution. Sign in with Apple is mandatory if you offer any third-party login. Demo credentials are mandatory if anything sits behind an account.

The submission mechanics — build upload, encryption declaration, age rating, screenshots — are covered in our App Store submission guides for Replit, Base44 and v0 projects, plus the broader pre-submission diagnosis of what usually goes wrong.

The Google Play parallel checklist

If Android is in scope, mirror the work with Google Play Billing. Products are created in Play Console, base plans and offers replace introductory pricing, and the fourteen-day closed testing requirement means you must start earlier than you think. Full walkthrough: Google Play Publishing For AI-Built Apps.

Android also changes your funnel maths. Play accepts alternative billing in some regions, refund windows differ, and trials behave differently. Plan the Android build after iOS revenue is proven, using convert to Android for Replit and Base44 projects when you get there.

Cross-platform entitlements

The moment you have two stores plus a web checkout, a customer can pay twice for the same thing. Prevent it with a single entitlement record keyed to the account, not the device or the store. Every purchase source writes to it; every client reads from it.

Where Apple's guidelines allow it, existing subscribers can sign in to access what they already bought; anything sold inside the iOS app goes through Apple in-app purchase. See the builder-specific guides for Lovable, Replit and Base44, plus cross-platform subscriptions for Replit and Base44.

Subscription metrics from day one

Ship analytics with the paywall or you will fly blind through the only weeks that matter. Track paywall views, start rate, trial-to-paid conversion, day-30 retention, refund rate and realised revenue per install. Segment by acquisition source from the first day, because blended numbers hide the one channel that works.

Both compound; neither fixes a weak offer.

Add push early too — lifecycle messaging is the cheapest retention lever a subscription product has. Setup notes for Lovable, Replit and Base44.

Hybrid monetization without breaking rules

Not every product suits a flat subscription. Credit packs suit bursty usage, one-off unlocks suit tools, and a light ad tier suits high-volume utilities. You can combine them, provided every digital purchase still runs through the store.

The common mistake is mixing a consumable balance with a subscription entitlement in the same field. Keep them separate: subscriptions grant capability, credits grant quantity. Your server should be able to answer both questions independently.

If you are weighing an infrastructure vendor for this, compare Lovable RevenueCat alternative · Lovable Adapty alternative · Replit RevenueCat alternative · Replit Adapty alternative · Base44 RevenueCat alternative · Base44 Adapty alternative, or read the RevenueCat vs Adapty vs Wanilla breakdown.

Rejection triggers to clear before you submit

Trigger	Guideline	Fix
External payment for digital content	3.1.1	Route through StoreKit; keep Stripe for physical goods only
No restore control	3.1.1	Add Restore Purchases to paywall and settings
Missing subscription terms	3.1.2	State length, price and content next to the buy button
Repackaged website	4.2	Add native capability: push, biometrics, offline, haptics
Third-party login only	4.8	Add Sign in with Apple
Inaccurate privacy labels	5.1.1	Declare every SDK's data collection
Reviewer cannot reach paid features	2.1	Supply demo account and a sandbox walkthrough note

Add a native capability or two while you are building the native app anyway — Face ID login is the fastest credible answer to 4.2, and works the same for Replit and Base44 builds. If your builder has gaps, the limitations and fixes guide lists workarounds.

A two-week timeline

Week one: lock the offer and pricing, enrol in the small business programme, create products in App Store Connect, build the native iOS app, and wire StoreKit with server-side verification. Week two: build the paywall, add restore, run the sandbox matrix, complete privacy labels and metadata, record a reviewer walkthrough, submit.

Teams that have done it before compress this to about three days. Teams doing it for the first time usually lose a week to certificates, provisioning and a rejection they could have predicted. Budget for one rejection and you will not be disappointed.

Platform-specific paths: Lovable publishing, Replit publishing, Base44 publishing, or the Base44 to mobile overview and the Replit to mobile walkthrough.

Launch-day checklist

Before you press submit, confirm: products live and localised, paywall renders store pricing, restore works after reinstall, entitlements verified server-side, grace period handled, analytics firing, privacy labels accurate, demo account supplied, terms and privacy links live, and the small business programme active. If Android is in scope, re-read Google Play Publishing For AI-Built Apps and start testing early.

Then ship. A paid launch with fifty subscribers teaches you more than a free launch with five thousand installs, and it is far easier to add users to a working business than to add a business to a working app. Wanilla builds the native iOS app with you and prepares your submission, ready for you to submit from your own Apple Developer account; Apple reviews and makes the final decision.

What we see go wrong in real launches

The first pattern is the free-forever trap. Founders launch without a paywall, gather a few thousand installs, and then discover that retrofitting a price to an audience trained to expect free costs them most of that audience. Charging from install one is less popular and far more informative: within a week you know your true conversion rate rather than a hopeful guess.

The second is the hidden cost curve. AI-heavy features look cheap at ten users and ruinous at ten thousand. Model your gross margin at the usage level you are actually targeting, then set caps that protect it. A fair usage limit written plainly into the plan description is normal and reviewers accept it; an unlimited promise you cannot honour is a refund queue waiting to happen.

The third is treating the paywall as a static screen. Your first version will be wrong. Ship it, measure it, then change one variable at a time — placement, price point, trial length, headline. Two disciplined iterations in the first month usually beat any amount of pre-launch theorising, and every change is a metadata update rather than a new binary.

The fourth is fragile plumbing. Purchases fail in the wild for reasons your happy-path test never surfaces: expired tokens, region changes, family sharing, a customer who bought on an iPad and opened on an iPhone. Every one of those is handled cleanly by a server-owned entitlement record and handled badly by a client flag stored in local storage.

The first thirty days after approval

Approval is the start of the work, not the end of it. In week one, watch trial starts and installs by source; if the paywall sees traffic but no starts, the offer is wrong, not the design. In week two, look at your first renewal cohort — the gap between trial starts and paid conversions tells you whether the product delivered value inside the trial window.

By week three you should have enough signal to make one pricing decision and one onboarding decision. By week four, revisit the store listing itself: keyword placement, screenshots and the first two lines of the description do more for organic installs than anything inside the binary. Re-check your listing quality score before spending on paid acquisition, and keep a steady cadence of small listing improvements rather than one big rewrite a quarter.

Throughout, keep refunds visible. A refund rate above the low single digits is a product message, not an accounting line: it usually means the paywall promised something the first session did not deliver.

Platform playbooks

Lovable subscription guides

Lovable in-app purchases · Lovable native paywalls · Lovable weekly subscriptions · Lovable restore purchases · Lovable cross-platform subscriptions · Lovable iOS paywall · Lovable App Store submission · Lovable App Store publishing · Lovable Build for iOS · Lovable convert to Android · Lovable push notifications · Lovable Face ID login · Lovable Apple Small Business Program

Replit subscription guides

Replit in-app purchases · Replit native paywalls · Replit weekly subscriptions · Replit restore purchases · Replit cross-platform subscriptions · Replit iOS paywall · Replit App Store submission · Replit App Store publishing · Replit Build for iOS · Replit convert to Android · Replit push notifications · Replit Face ID login · Replit Apple Small Business Program

Base44 subscription guides

Base44 in-app purchases · Base44 native paywalls · Base44 weekly subscriptions · Base44 restore purchases · Base44 cross-platform subscriptions · Base44 iOS paywall · Base44 App Store submission · Base44 App Store publishing · Base44 Build for iOS · Base44 convert to Android · Base44 push notifications · Base44 Face ID login · Base44 Apple Small Business Program