I'd appreciate input from anyone who has shipped a multiplatform productivity service (web + iOS + Android) where the iOS app is free and the website handles subscriptions. We just went through several review cycles on this and want to make sure we end up on the right pattern long-term.
The setup
- Cross-platform productivity SaaS. Users sign up and subscribe on the web.
- The iOS app is fully free. No IAP, no upgrade UI, no pricing screens, no paywalls, no plan-tier badging.
- iOS exists primarily for capabilities a browser/PWA cannot deliver on iOS: native geofencing and native phone-call detection, plus on-the-go time capture.
- The same account a user has on the web is the account they sign into on iOS.
The question
For a multiplatform service like this — what's the safest, App-Review-defensible pattern for the iOS app's relationship to the user's web subscription tier?
There appear to be two patterns in the wild:
-
Tier-identical iOS — every iOS user, regardless of their web plan, sees an identical feature set on iOS. The iOS app surfaces nothing tier-specific. Web subscribers don't gain anything on iOS for being subscribers.
-
Tier-aware iOS under 3.1.3(b) — Free users see a base feature set; users who already paid on the web see additional features mirroring their web account, framed under Multiplatform Services.
What we learned
Pattern 2 reads naturally from 3.1.3(b)'s text about apps "operating across multiple platforms" letting users "access content … acquired … on … your web site." We initially built and submitted with pattern 2.
The piece we underweighted is the "also" in 3.1.3(b): "provided those items are also available as in-app purchases within the app." App Review's reading is that 3.1.3(b) only attaches if IAP is also offered in the iOS app for those items. If IAP is not offered, "Pro features visible to paid web users on iOS" is read as 3.1.1 (paid digital content accessed in-app without IAP), regardless of how the entitlement was granted.
We resolved it by switching to pattern 1 — tier-identical iOS — which made the question moot.
The product cost of pattern 1
Worth flagging for anyone weighing this themselves: pattern 1 (tier-identical iOS) creates a real and visible feature divergence between iOS on one side, and Android + web on the other. On Android we surface the user's paid-tier features just like the web does — there's no equivalent guideline forcing tier-uniformity on the Play Store side. So a Pro user on the same account sees a meaningfully different app on iOS than on their other devices.
That's the trade we accepted to be unambiguously compliant with 3.1.1, but it is a trade — not a free move. Users notice. Support tickets will reflect it. For an internal stakeholder asking "why is iOS missing X," the honest answer is "App Store rules around paid digital content, with no IAP path that fits our pricing model."
Specific things I'd love input on
- For other multiplatform services without IAP — has anyone defensibly shipped pattern 2 in the last ~12 months? If so, what was the framing?
- Is there a documented carve-out under 3.1.3(b) for genuinely free iOS apps, or has the "also available as IAP" language been read strictly across the board?
- For apps that took pattern 1 (tier-identical iOS): did you find any side-effects (e.g. App Store reviewers questioning the value of an iOS app that doesn't differentiate by plan)?
- For teams who took pattern 1: how did you communicate the iOS / Android feature gap to users? In-app message, FAQ, just leave it implicit?
- Are there cases where a phone call from App Review (offered in the rejection email) clarified this faster than the written back-and-forth?
What I think the takeaway is, for posterity
For a free iOS app fronting a cross-platform paid service, tier-identical iOS is the unambiguous safe harbour today. 3.1.3(b) appears to require IAP to be offered before it can be cited as cover for tier-aware behaviour, even if the user paid elsewhere. If anyone has a recent counter-example I'd genuinely like to see it — it would be useful for the next thread someone Googles.
Thanks in advance.
