The subscription and in-app purchase gotchas by platform

Teams building their first subscription-based mobile app often assume iOS and Android handle recurring billing similarly enough that one implementation covers both. The platforms diverge in specific, consequential ways, and missing one of these differences has delayed more than one client launch.

Both platforms offer a grace period for failed payment retries before actually canceling a subscription, but the default windows and configuration options differ between App Store Connect and Google Play Console. We configure both explicitly rather than accepting platform defaults, since the difference directly affects how much revenue is recovered from temporarily failed cards.

Apple requires apps to provide a way for users to manage or cancel a subscription that meets specific guidelines, and rejecting or obscuring this path is a common review rejection reason. Google's requirements differ in specific detail. We build subscription management flows against both platforms' current guidelines directly rather than assuming one satisfies the other.

Client-side-only purchase validation is vulnerable to manipulation on both platforms, and both provide server-to-server notification systems specifically so a backend can validate purchases and subscription status independently of the client. We treat server-side validation as required scope on every subscription app, not an optional hardening step.

Introductory pricing, free trial length options, and promotional offer eligibility rules differ between the two platforms' subscription systems in ways that affect how a marketing team can actually run a promotion. We map out the actual available promotional mechanics on both platforms before a marketing team commits to a specific promotional campaign structure.

A user who subscribes on iOS and later opens the same app on Android expects their subscription status to carry over, which requires the backend, not either platform's native billing system, to be the actual source of truth for entitlement. We design this explicitly rather than assuming either platform's billing APIs handle cross-platform sync automatically, since neither one does.

"Add subscriptions" as a single line item in a project scope hides a meaningful amount of platform-specific complexity that affects both timeline and cost. We scope iOS and Android subscription implementation as distinct, named pieces of work specifically because treating them as one undifferentiated task is where estimates go wrong.

Both platforms take a commission on in-app purchases and subscriptions, with rates that can differ based on subscription length and, in some cases, program eligibility, and that commission has a direct effect on what price point actually delivers the margin a business needs. We involve whoever owns pricing strategy in this conversation early, since it's a business decision with real engineering-adjacent dependencies, not a detail that can be resolved purely on the engineering side.

This becomes especially relevant for a business that also sells the same subscription through its own website, since a price that works well through a lower-commission web checkout may need to be different through an app store purchase to preserve the same margin, and presenting genuinely different prices across channels raises its own set of platform policy considerations that need to be checked explicitly rather than assumed.

Apple and Google both have their own refund policies and processes that a business selling subscriptions through either store has limited control over compared to a web-based payment processor, and this affects how a support team needs to be trained to handle refund requests that come in through each channel. We document this difference explicitly for client support teams, since assuming one refund process covers both platforms creates real confusion during actual customer support interactions.

Given how many platform-specific details this involves, we push back on any launch date set before subscription implementation has been fully scoped against both platforms' current guidelines, since platform policy changes reasonably often and a scope done even six months earlier can be meaningfully out of date by launch.

Apple and Google both provide sandbox testing environments for subscriptions specifically so a team can test renewal, cancellation, and billing failure scenarios without real money changing hands, but each sandbox has its own quirks and accelerated time behavior that doesn't perfectly mirror production. We budget real QA time specifically for sandbox testing on both platforms, since a subscription bug that only surfaces at a real renewal cycle is far more expensive to discover in production than in a sandbox built to catch exactly that kind of issue.

Given how frequently both platforms' subscription and billing guidelines shift, we schedule a final policy compliance review immediately before app store submission, not weeks earlier during development, since a review done too early can miss a guideline change that took effect in the interim. This final check has caught real, submission-blocking issues that would otherwise have delayed a launch by a full review cycle.

Nearly every platform-specific integration, not just billing, benefits from the same discipline: scope each platform's requirements as distinct named work, validate against current guidelines close to launch rather than early in development, and budget real QA time for each platform separately rather than assuming a passing test on one platform implies the other will behave the same way.

Budget real calendar time specifically for platform-specific subscription work in the project timeline, not folded silently into a generic "build the app" estimate, since that's the single change most likely to prevent the launch delays we've seen happen to teams that assumed the two platforms would behave the same way. It's a small line item to add upfront relative to the schedule risk it removes later.