Lower Store Fees by Their Structure, Not Their Rate — Apple SBP and Google Play's June 2026 Pricing

Google Play's June 30, 2026 Model — Service Fee and Billing Fee Split

Starting June 30, 2026, Google Play separated its service fee from its billing fee. It began in the US, the European Economic Area (EEA), and the UK, and is expanding to other markets on a schedule. That split actually creates room that favors indie developers.

The core: the service fee starts at 10% on your first $1M of annual earnings regardless of charge type, and the extra 5% billing fee (US/UK/EEA) applies only when you use Google Play's billing system. Charge through an external system or a link to your own site and that 5% does not apply.

Subscriptions carry a flat 10% service fee with no $1M cliff, which is plainly good for an indie subscription app. Non-subscription charges, once you pass $1M, split by whether the user is a "new" or "existing" install — defined by whether their first install or first update happened on or after the date the new model launched in that market. Choose external billing or a site link for "other charges" and the 5% billing fee disappears, leaving only the service fee — but you then carry checkout, refunds, and taxes yourself. For small-ticket subscriptions I pay Google Play's 15% to keep operational load low; for higher-priced one-time charges, external billing is worth considering.

Compute Your Effective Fee With Your Own Numbers

Instead of memorizing rates, keep a function that returns your effective fee from the conditions. This TypeScript returns the effective rate for Apple and Google and drops straight into a Rork backend such as Cloudflare Workers.

type Store = "apple" | "google";
type ChargeKind = "subscription" | "other";
type InstallType = "new" | "existing";
 
interface FeeInput {
  store: Store;
  kind: ChargeKind;
  // Year-to-date proceeds (USD), used for the $1M threshold test
  ytdProceedsUsd: number;
  // Apple: enrolled in SBP / Google: using Play billing
  enrolledOrPlayBilling: boolean;
  installType?: InstallType; // needed for Google "other charges"
}
 
const ONE_MILLION = 1_000_000;
 
// Returns the effective fee rate (%). Without Play billing, the 5% billing fee is excluded.
function effectiveFeeRate(i: FeeInput): number {
  if (i.store === "apple") {
    // 15% if enrolled in SBP and YTD proceeds are at or below $1M, otherwise 30%
    const eligible = i.enrolledOrPlayBilling && i.ytdProceedsUsd <= ONE_MILLION;
    return eligible ? 15 : 30;
  }
 
  // Google Play (in markets on the post-2026-06-30 model)
  const billingFee = i.enrolledOrPlayBilling ? 5 : 0;
 
  if (i.kind === "subscription") {
    // Subscriptions: flat 10% service fee, no $1M cliff
    return 10 + billingFee;
  }
 
  // Other charges: 10% up to $1M, then 20% new / 25% existing
  let serviceFee = 10;
  if (i.ytdProceedsUsd > ONE_MILLION) {
    serviceFee = i.installType === "existing" ? 25 : 20;
  }
  return serviceFee + billingFee;
}
 
// Example: a small subscription served through Play billing
console.log(
  effectiveFeeRate({
    store: "google",
    kind: "subscription",
    ytdProceedsUsd: 40_000,
    enrolledOrPlayBilling: true,
  })
); // => 15
 
// Apple, SBP enrolled, $40k YTD proceeds
console.log(
  effectiveFeeRate({
    store: "apple",
    kind: "subscription",
    ytdProceedsUsd: 40_000,
    enrolledOrPlayBilling: true,
  })
); // => 15

The point is to derive the rate from conditions so a half-remembered "15%" never sneaks into pricing. Google's non-subscription path in particular branches four ways across installType and ytdProceedsUsd, so a function is safer than mental math. Because the year-to-date total is an argument, feeding ytdProceedsUsd from your monthly rollups flips the effective rate automatically in the month you cross the threshold.

Fold Fees Into Take-Home and Break-Even

Once you have the effective rate, work backward from price to take-home. For a monthly subscription at an effective 15%:

Only after you layer on payment-side FX and taxes, plus fixed costs like your Rork paid plan and backend (Cloudflare Workers, RevenueCat), does the real break-even appear. Running several apps taught me that leaving fees vague as "a deduction that hits later" while setting price leads to a specific error: you hit your target MRR but miss your take-home goal.

In practice, deciding your fee-inclusive take-home first and then reverse-computing the display price is more stable. Subscription pricing itself is covered in Subscription Pricing Design Principles, and per-currency display in StoreKit 2 Currency and Locale Pricing.

A Practical Submission and Migration Checklist

On the Apple side, estimate your prior-year proceeds in USD from the Payments and Financial Reports in App Store Connect and confirm they are at or below $1M, aggregating any associated accounts. Accept the latest Paid Apps agreement and enroll in SBP. Since the rate applies from the approval fiscal month-end plus 15 days, align that date with a price change or a new subscription launch to run at 15% from month one.

On the Google side, confirm in Play Console whether the new model has started in your distribution markets (US/UK/EEA first, others rolling out). Subscriptions are a flat 10% (plus 5% with Play billing), while non-subscription charges pick up the new/existing distinction above $1M — so if you skew toward non-subscription charges, model it against your own revenue mix. Dropping the 5% billing fee via external billing is an option, but weigh it against carrying payments, refunds, and taxes yourself.

Reconciling take-home across multiple stores and apps is covered in Reconciling AdMob, App Store, Play, and Stripe Across Six Apps. Understanding the fee structure and then building the reconciliation to match actual deposits helps you catch changes like a threshold crossing early.

Wrapping Up

Today, compute the effective fee for a single app of yours. Put the store, charge type, year-to-date proceeds, and billing method into the function above, and the gap from the rate you had memorized should show up. That gap is exactly what has been slipping out of your pricing. Fees are an unavoidable deduction, but once you understand the structure they become a variable you can design. I am still tracking the per-market rollout myself, and I will keep sharing what I learn. Thank you for reading.