| This article is part of our series on : App Monetization Strategies: The Best Practices for US App Founders to Choose the Right Revenue Model Before Writing a Line of Code in 2026 |
Introduction: The Bridge From Strategy to Development Scope
A founder picks a subscription as the revenue model. That decision does not name a database schema. It does not name an SDK. It does not specify how entitlements get verified across iOS and Android. The strategy decision and the architecture decision are two separate steps.
RevenueCat StoreKit Play Billing integration is the technical core of most subscription and IAP builds today. AdMob and ad mediation power the advertising model. Stripe powers B2B and marketplace payments. The App Store commission bypasses web payment decision cuts across all three. Each path carries its own development scope, its own compliance surface, and its own cost.
Verify each platform’s current SDK versions and fee structures before locking architecture decisions. The commission-bypass section of this article describes a fast-moving legal situation. It is not a fixed technical spec. It is not a settled policy. It changes what gets built and what the app retains.
Founders scoping custom mobile app development around a defined monetization model need this architecture mapped before sprint one. The billing dashboard and web payment portal scope falls under web application development when B2B invoicing or commission-bypass sign-up flows are part of the deliverable. Both decisions belong in the first scoping conversation.
RevenueCat for Subscription and IAP Management
Without RevenueCat or a comparable abstraction layer, the app needs two separate systems. One for Apple. One for Google. Each has its own purchase-verification flow. Each has its own subscription-status-check logic. Each has its own receipt-validation backend. And reconciling a user who switches platforms requires custom cross-platform entitlement logic.
RevenueCat replaces all of that with one SDK and one webhook endpoint. The app checks a single entitlement state: active or not. The answer comes back the same way regardless of which platform processed the purchase. Purchase restoration, cross-platform syncing, and real-time analytics (MRR, churn, LTV) run through one integration.
Webhook integrations push purchase events to the backend in real time. A new subscription fires a webhook. A renewal fires a webhook. A cancellation fires a webhook. A billing failure fires a webhook. The backend updates user records without polling either platform’s API.
RevenueCat’s Paywalls product adds no-code paywall experimentation. Copy, pricing, and layout change without an app-store resubmission. A/B tests run server-side. Results report into RevenueCat’s dashboard directly. For teams testing pricing or messaging weekly, that iteration speed compounds fast.
RevenueCat saves real development time for most teams. The licensing cost is a fraction of building the same capability from scratch. But experienced teams with deep platform knowledge sometimes build directly against StoreKit 2 and Play Billing. The tradeoff is ongoing licensing cost versus upfront development hours. Teams with a 12-plus-month runway and strong platform engineers may find the direct path cost-competitive over time.
The RevenueCat StoreKit Play Billing integration decision belongs in the first architecture conversation. Switching approaches after launch means rebuilding the entitlement layer.
This integration architecture is the connectivity layer of the full App Monetization Strategies: The Complete Guide for US App Founders.
Apple StoreKit 2 and Google Play Billing — Direct Versus Abstracting
Both platform SDKs have matured enough that building directly is a viable path. The choice depends on team experience, timeline, and long-term licensing math.
Apple StoreKit 2 replaced the original StoreKit API with a substantially cleaner interface. Server-side verification removed client-side receipt validation entirely. Signed transactions provide cryptographic proof of purchase. Subscription renewal handling is simpler than it was under StoreKit 1. The Apple StoreKit 2 Google Play Billing 6 2026 integration pattern uses Swift’s async/await model natively on iOS.
The iOS scope for StoreKit 2 includes the external-link entitlement for US-storefront apps. Configuring that entitlement requires a disclosure screen and a backend that verifies web-originated purchases.
Google’s Play Billing Library enforces pending-transaction handling. It requires deferred-payment support for markets where carrier billing introduces delays. Consent-flow integration for subscription price changes is mandatory.
The Android scope under the current permanent injunction also includes alternative billing without Play Billing. That path requires a separate payment processor and logic reconciling both entitlement sources.
The abstraction-versus-direct decision comes down to three factors. Development time favors RevenueCat. Ongoing cost favors building direct. Cross-platform sync is built into RevenueCat but requires custom work on a direct build. Most teams shipping their first subscription product choose RevenueCat. Teams with deep platform-specific experience and longer timelines sometimes find the direct path cheaper over 18 to 24 months.
The subscription, freemium, and IAP models that drive this architecture choice are broken down in App Monetization Models Compared: Subscription vs. Freemium vs. In-App Purchases vs. Advertising.
The App Store Commission Bypass — Current Reality
This section carries the most time-sensitive content in the cluster. Both Apple and Google currently charge $0 commission on qualifying US external payment links. Neither situation is permanent. Both rest on litigation outcomes.
This is educational content, not legal advice. All content applies to the US App Store and Play Store storefronts only. The EU, Japan, and Brazil operate under separate rules. Consult qualified app-platform counsel before building.
Apple: $0 Commission, Under Active Supreme Court Review
Apple’s native in-app purchase commission runs 15 to 30 percent. The rate depends on developer size and subscription tenure. As of this writing, Apple charges $0 on qualifying US external payment links.
The path that produced this matters. The 2021 Epic v. Apple injunction required Apple to allow external payment links. Apple complied by imposing a 27 percent fee on those purchases. Not a single developer implemented the links. Courts found Apple designed the fee to kill the option.
In April 2025, Judge Yvonne Gonzalez Rogers found Apple in contempt. She barred Apple from charging any commission on external-link purchases. In May 2025, Apple updated App Store Review Guidelines 3.1.1 and 3.1.3 for the US storefront. External links, buttons, and calls to action are explicitly allowed. No entitlement approval process is required. No commission applies.
The Ninth Circuit upheld the contempt finding in December 2025. It ruled that a total commission ban was excessive. Apple should be allowed a “reasonable” commission tied to actual costs. It did not set a rate. Apple petitioned the Supreme Court. The Court denied a stay on May 6, 2026. It was granted certiorari on June 30, 2026. Oral argument is expected in the October 2026 term. A decision is not likely before late 2026 or early 2027.
Apple charges $0 while the petition is pending. Apple can still impose design constraints on external links. The link cannot be more prominent than the IAP button. Font and button sizing are restricted. A neutral leaving-the-app disclosure is required.
Architecture takeaway: build the web payment flow now. Include a configurable commission variable for when the Court sets a rate.
Google: A Bigger Remedy, Also Currently $0
Google’s case goes beyond payment routing. A jury found Google maintained a full illegal monopoly over Android app distribution and billing in December 2023. Not a narrow anti-steering violation. A monopoly finding.
Judge James Donato’s October 2024 permanent injunction is broader than anything in the Apple case. It requires Google Play Billing. It bars anti-steering restrictions. It requires Google to host rival app stores inside the Play Store. Google lost its appeal in July 2025. The Supreme Court declined to review the case. This injunction is final and non-appealable.
Epic and Google proposed an alternative settlement in late 2025. That settlement would have introduced 9 to 20 percent tiered fees on external transactions. Judge Donato expressed significant skepticism. He called an earlier version a “sweetheart deal.” He flagged a previously undisclosed $800 million commercial side deal.
On July 15, 2026, Epic and Google jointly withdrew the proposed settlement entirely. The original 2024 injunction is now the sole governing order. No settlement fees are pending. No further appeals are possible.
Starting July 22, 2026, rival app stores appear inside Google Play in the US. Users download them like any other app. Google’s Play Catalog Access Program opens the full app catalog to enrolled rival stores by default.
Google charges $0 on alternative billing and external-link purchases in the US under the permanent injunction. Unlike Apple, no Supreme Court review threatens this posture.
Architecture takeaway: Google’s $0 commission rests on a final, non-appealable court order. The App Store commission bypass web payment decision on Android sits on firmer legal ground than on iOS.
What This Means for the Web Payment Flow
Both platforms charge $0 in the US right now. A compliant web payment flow currently retains nearly all subscription revenue that would otherwise go to platform commission. The case for building a commission-bypass flow is stronger right now than at any prior point in mobile app history.
A compliant flow has four components. A hosted sign-up page where Stripe or a comparable processor handles the transaction. A purchase-verification backend that confirms the web purchase and provisions entitlements. A disclosure UI meeting Apple’s design constraints. And a cross-platform account-linking system that bridges web and native accounts. The verification backend and account-linking layer are not vendor SDK work, which is why this piece of the flow lands in custom software development.
Development cost runs roughly $15,000 to $25,000. Break-even is fast given the $0-commission reality on both platforms today.
Build the Apple-side flow with a configurable commission variable. Build the Google-side flow with confidence in the permanent order. Revisit the Apple-side assumption when the Supreme Court rules.
This integration complexity is a primary cost driver. The updated unit economics by model are covered in App Monetization Unit Economics: What It Actually Costs to Build Each Revenue Model and What Returns US Apps Can Expect in 2026.
Google AdMob and Ad Mediation Architecture
Ad monetization lives or dies on two decisions. Which ad networks fill each impression. And whether mediation routes requests across competing networks. Most apps answer both at once.
The AdMob ad mediation architecture starts with the Google Mobile Ads SDK on iOS and Android. Supported formats include banner, interstitial, rewarded video, and native ads. Rewarded video earns the highest eCPM and causes the least user disruption. The user opts in to watch an ad in exchange for in-app value like currency or content unlocks.
Ad mediation routes each impression to the highest-bidding network. Without mediation, the app fills from one source. With mediation, competing networks bid for every impression.
Three primary mediation options exist in 2026. AppLovin MAX runs a unified auction where all networks bid simultaneously. Unity LevelPlay is the mediation product formerly marketed under the ironSource brand. ironSource Ads direct demand was sunset on April 30, 2026. The LevelPlay mediation product remains active and widely used in gaming. AdMob Mediation is Google’s own stack. It supports both waterfall and bidding configurations. For teams already on AdMob, adding its mediation layer is the lightest integration lift.
Apple’s ATT framework directly affects iOS ad revenue. Lower opt-in rates mean less precise targeting and lower eCPM from advertisers. The permission prompt must earn genuine consent through clear value communication. Apple prohibits incentivizing the opt-in with rewards or currency.
Rewarded ad units should be gated behind user-initiated triggers. A user watches an ad to earn currency. A user watches an ad to unlock content. That opt-in exchange works at smaller DAU thresholds than passive interstitials or banners.
Stripe for B2B and Marketplace Monetization, and Dynamic Paywalls
Stripe powers two architecturally distinct models. B2B billing and marketplace split payments share a processor but require different integration paths. Dynamic paywalls sit on top of the subscription layer as a separate optimization tool.
Stripe Connect Marketplace Payments
Marketplace monetization requires split-payment architecture. A buyer pays. The platform takes a commission. The seller receives the rest. Stripe Connect marketplace payments handle seller onboarding, identity verification, payout scheduling, and dispute resolution. Three account types exist. Express accounts balance onboarding speed with platform control for most marketplace apps.
Adding Stripe Connect after a Checkout-only integration means rebuilding the payment layer entirely. It is not an extension. It is a rebuild.
Stripe Subscriptions for B2B
Stripe Subscriptions handles enterprise per-seat billing with invoice-based payment. Usage-based metering is built in. Stripe’s billing portal gives enterprise customers self-service subscription management without the platform building a custom portal.
Stripe’s stablecoin payment support is confirmed and currently available. For apps serving crypto-native users or international markets with high card-transaction costs, stablecoin acceptance adds a payment option without building a separate crypto integration.
Dynamic Paywall ML Timing
Dynamic paywalls time the upgrade prompt using behavioral signals. Instead of a fixed trigger (fifth session, end of onboarding, feature gate), the paywall appears when the user’s behavior predicts peak conversion probability.
RevenueCat Paywalls and Superwall are the two primary tools for dynamic paywall ML timing. Both connect to event-tracking platforms like Amplitude, Mixpanel, and Segment. Both support A/B tests on copy, pricing, layout, and trigger timing without app-store resubmission.
This capability belongs to third-party vendors. It is not a custom ML feature. The development scope covers SDK integration, event-source connection, and experiment configuration. No first-party machine-learning model is required.
Final Thoughts
RevenueCat, StoreKit 2, Play Billing, AdMob, and Stripe are the technical core of app monetization in 2026. The commission-bypass decision cuts across all of them. It changes what gets built, what it costs, and what the app retains.
The $0-commission window on both platforms makes the web payment flow investment stronger than at any prior point in mobile history. On Google’s side, a permanent injunction governs that posture. On Apple’s side, a Supreme Court review is pending. Build the Apple-side flow with a configurable commission variable. Build the Google-side flow with confidence in the final order.
NewAgeSysIT scopes every monetization architecture against the current, verified state of both platforms.Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
If monetization architecture is the core of your next sprint, scoping the RevenueCat StoreKit Play Billing integration and the bypass decision against current legal reality keeps the payment layer from needing a rebuild in six months.
