In-app purchases: Apple and Google's cut, and how it changes pricing

Apple and Google both take a cut of in-app purchases and subscriptions, historically up to 30 percent, dropping to 15 percent for smaller developers and in the first year of a subscription in many cases. That fee isn't just a cost line to plan around. It should actively shape how a product structures its pricing and its purchase flow from day one.

We've watched founders discover this fee for the first time midway through a launch, having priced their product around a margin assumption that quietly didn't account for it, and the resulting scramble to fix pricing after users are already accustomed to the old number is a much harder problem than pricing correctly from the start would have been. The fee needs to be part of the very first pricing conversation, not a correction made after the fact.

Directing users to purchase through a web browser instead of in-app avoids the platform fee entirely, and both platforms have, at different points and under regulatory pressure, allowed more flexibility here than in the past. The tradeoff is a meaningfully worse conversion rate: adding any extra step between a user's intent to buy and completing the purchase costs conversions, and that cost needs to be weighed honestly against the fee it's avoiding.

We test this tradeoff explicitly rather than assuming the answer either way. For a product with high-value, considered purchases, a business tool with an annual plan, the drop in conversion from an added step is often small relative to the margin saved by avoiding the platform fee entirely. For a low-friction, impulse-driven purchase, a small in-app upgrade a user decides on in seconds, the added step costs more in lost conversions than the fee it avoids, and staying in-app despite the cut is usually the better call.

We help clients set in-app pricing that accounts for the platform cut explicitly, rather than pricing as if the fee doesn't exist and quietly eating a lower margin than the business model assumed. A subscription priced without accounting for a 30 percent fee often turns out to be unprofitable at the unit level in a way that's easy to miss until months of data make the pattern obvious.

This is a simple exercise in spreadsheet terms, take the target margin, work backward through the platform fee to the price that actually delivers it, but it's a step we see skipped surprisingly often, especially by teams pricing based on competitor benchmarks rather than their own real cost structure. A competitor's listed price tells you nothing about whether they've actually priced the platform fee in correctly either.

Both platforms' reduced first-year subscription fee changes the actual lifetime value calculation for a subscription business: retention past year one is worth meaningfully more to margin than the raw revenue number suggests, since the fee drops. That's a real reason to weight retention-focused product work more heavily than acquisition in a subscription app's roadmap.

We model lifetime value for subscription clients with the fee schedule built in explicitly rather than using a flat blended rate, since a flat rate understates just how much more valuable a subscriber who renews into year two actually is. Seeing that number modeled out concretely tends to shift product priorities in a healthy direction, toward the onboarding and retention work that gets a subscriber to that second year, rather than purely toward acquisition volume.

Annual plans, priced correctly, benefit from the fee structure more than monthly plans do in most cases, since fewer individual transactions mean less cumulative fee exposure over a subscriber's lifetime and a stronger incentive for the platform to treat the developer favorably on renewal pricing. We often steer clients toward a pricing structure that nudges users toward annual commitment for exactly this reason, alongside the more commonly cited benefit of improved cash flow predictability.

Before a client sets a single price, we walk through the full fee schedule for their specific situation, including the small-developer exemption threshold many teams don't realize they qualify for, and build the pricing model around the real number rather than a rough assumption. It's a short conversation that prevents a much more painful correction down the line, once real subscribers are already anchored to a price that never actually worked at the margin the business needed.

We also flag the small-developer program specifically because it's easy to miss and genuinely changes the math for an early-stage app. A team under the qualifying revenue threshold paying the reduced rate from the start has real breathing room in its pricing that a team assuming the standard rate doesn't, and building a financial model around the wrong assumption here can make a genuinely viable product look marginal on paper when it isn't.

A subscription priced identically across iOS, Android, and web sounds like the obvious default, but the different fee structures and different payment processing costs across each platform mean identical list prices don't actually deliver identical margin. Some teams intentionally price slightly differently by platform to normalize margin; others accept the variance and price uniformly for simplicity's sake, accepting a lower margin on whichever platform costs more to transact on.

We help clients make that decision deliberately rather than by default, since the wrong assumption compounds at scale. A one or two percentage point margin difference per platform looks trivial on a single subscription and becomes a meaningful line item once a product has real volume across both major app stores and a web-based option running simultaneously.

Promotional pricing adds another layer of complexity most teams don't plan for upfront. A discounted introductory offer run through the app store still carries the platform fee on whatever discounted amount is actually charged, which means an aggressive promotional price can end up delivering close to zero margin once the fee is applied, even though the sticker price looked reasonable in isolation. We model promotions against the post-fee number specifically, not the list price, before approving any discount campaign.