Skip to content
WebViewGold Vibe Coding to App Store
English
Get WebViewGold

App Store rejection

Guideline 3.1.1 (In-App Purchase): what to do when Apple rejects your Stripe checkout

Your web app charges through Stripe, and that is fine on the web. Inside the iOS app, Apple requires In-App Purchase for anything digital that is used in the app. The fix is not to rip out Stripe; it is to let the iOS build use StoreKit through RevenueCat while the web keeps Stripe.

From $109 one-time per platform, or let our team do it all from $698.

  • Approval guarantee – or money back within 14 days
  • No coding needed
  • One-time payment, free updates
  • 24/7 human support
  • Made in Germany since 2014 · ISO 27001

What 3.1.1 says, in plain words

If your app unlocks features, content or services that are consumed inside the app (subscriptions, premium tiers, AI credits, templates, courses), that purchase must go through In-App Purchase. The guideline also bars buttons, links and wording inside the app that steer people to another way of paying for those digital items. Apple applies it per storefront, and regional exceptions exist (more on that below), but for a small app the practical rule is: digital goods inside the iOS app use IAP.

Lovable, Bolt and v0 templates wire Stripe Checkout by default, and the AI happily puts an "Upgrade for $9/month" button on the pricing page. The reviewer taps it, sees a Stripe form, and writes the 3.1.1 rejection. Nothing about your business model is wrong; the channel inside the app is.

Does your purchase need In-App Purchase?

What you sellInside the iOS appGuideline
Subscription to app features, premium tierIAP required3.1.1
AI credits, tokens, generationsIAP required (consumable)3.1.1
Templates, e-books, courses used in the appIAP required3.1.1
Physical goods and services used outside the app (shipped products, food delivery, a cleaning visit)Stripe or any processor allowed; IAP must not be used3.1.3(e)
Real-time one-to-one services between two people (tutoring, consultations)Other payment methods allowed; one-to-many must use IAP3.1.3(d)
Content bought on the web, only consumed in the app (reader apps: books, audio, video, news)May be unlocked without IAP; no in-app purchase buttons or links to buy elsewhere3.1.3(a)

Switch the iOS build to In-App Purchase with RevenueCat

Stripe stays on the web; the app calls one URL scheme.

  1. Create the products in App Store Connect

    Sign the Paid Apps agreement (account holder), then add the subscription or consumable with an identifier such as pro_monthly. Add a sandbox tester in Users and Access for testing.

  2. Set up RevenueCat and Config.swift

    Create a RevenueCat project, import the products, and paste the key and project ID into revenueCatAPIKey and revenueCatProjectID in Config.swift. Bundle ID in Xcode, App Store Connect and RevenueCat must match. Full walkthrough: RevenueCat setup for web-wrapped apps and the In-App Purchases docs.

  3. Let the web app know it is running in the app

    Set useragent_iphone in Config.swift to the default user agent plus a marker such as MyAppiOS, then check navigator.userAgent in your web app. In the app, replace the Stripe button with a link to revenuecat://purchase?external_id=USER_ID&product=pro_monthly, or open a native paywall with revenuecat://launchPaywall?external_id=USER_ID&offering=default (iOS 15 or later).

  4. Sync the entitlement to your backend

    Use RevenueCat webhooks (or the injected planID and transactionIdentifier variables) to set the plan on the user record in Supabase or Firebase, so the same account is premium on the web and in the app.

  5. Add restore and manage links

    A visible "Restore purchases" link to restoreinapppurchases:// and a "Manage subscription" link to cancelinapppurchase://, which opens Apple's subscription management. Both are expected by reviewers.

  6. Remove every external payment hint from the app

    No "cheaper on our website", no Stripe billing portal, no email saying "upgrade at yourdomain.com" triggered from the app, no pricing page comparing both. Then upload a new build and reply in Resolution Center with the product IDs.

My iOS WebView is finally approved. Thanks!!

Taha Farooqui · CodeCanyon

One purchase function for web and app

The web keeps Stripe; the iOS build routes to RevenueCat. Detect the app through the custom user agent marker.

javascript
// Config.swift: useragent_iphone = default UA + " MyAppiOS"
var isIosApp = navigator.userAgent.indexOf("MyAppiOS") !== -1;

function buy(productId, userId) {
  if (isIosApp) {
    // StoreKit via RevenueCat inside the WebViewGold app
    window.location.href = "revenuecat://purchase?external_id=" + encodeURIComponent(userId) + "&product=" + productId;
  } else {
    // Stripe Checkout on the web
    window.location.href = "/checkout?plan=" + productId;
  }
}

External payment links: rules vary by region

Rules vary by region. In the United States, following a 2025 court order, apps on the US storefront may link to external purchase options; the European Union has alternative terms under the Digital Markets Act; elsewhere the classic rule applies. These rules change and carry their own disclosures, so check Apple's current text before relying on them. For a one-person app, IAP through RevenueCat passes review on every storefront with the least paperwork; see the Stripe vs In-App Purchase decision guide for the business side.

Frequently asked questions

Can I keep Stripe for the web version and use IAP only in the app?

Yes, that is the normal setup. The same account gets the entitlement from either channel; your backend treats a RevenueCat webhook and a Stripe webhook the same way.

Can I just hide the pricing page in the app and ask users to subscribe on the website?

Hiding the purchase is allowed for reader-type content, but telling users in the app to go to the website is not. If the app itself has nothing to buy and never points elsewhere, reviewers generally accept it; most apps do better by adding IAP.

Do consumables like AI credits really need IAP?

Yes. Credits that are spent inside the app are digital content. Create them as consumable in-app purchases and credit the balance on your backend after the RevenueCat webhook arrives.

Three ways to get your app into the stores

Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.

Do it yourself

$109 per platform, one-time

The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.

See plans on the main page

Cloud Builder

$349 per license, one-time add-on

No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.

How the Cloud Builder works Try the free demo

Full Service

$698 per platform $798

Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.

Full Service details Powered by WeSetupYourWebViewApp

Winter Sale prices valid until December 31, 2026.

Ready to ship your app?

App Store & Google Play approval guarantee – or your money back within 14 days

Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.

Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.