How to Comply with Apple’s Schedule 2, Section 3.8(b)
At WWDC 2019 Apple updated Section 3.8(b) and has let up a ton on what is required.
August 2024 Update
Apple now only requires the following now to comply with Schedule 2, Section 3.8(b):
You clearly and conspicuously disclose to users the following information regarding your auto-renewing subscription:
• Title of auto-renewing subscription, which may be the same as the in-app product name
• Length of subscription
• Price of subscription, and price per unit if appropriate
Links to Your Privacy Policy and Terms of Use must be accessible within Your Licensed Application.
June 2019 Update
At WWDC 2019 Apple updated Section 3.8(b) and has let up a ton on what is required.
Have you read Paid Applications Agreement, Schedule 2, Section 3.8(b)?
If you’ve ever submitted an app to the App Store, you know the frustration when Apple rejects your submission. Even more so when you thought you’d followed all the rules. As it turns out, Apple can bury requirements wherever they want, and it’s your burden to keep up.
About a year ago, Apple started rejecting apps that didn’t comply with Schedule 2, Section 3.8(b) of the Paid Applications Agreement, a verbose list of self-evident truths about subscriptions. The Paid Applications Agreement is a 37-page document that you had to agree to before you could submit your app. It is only available via iTunes Connect in the form of downloadable PDF.
The actual contents of Schedule 2, Section 3.8(b):
3.8(b) requires that you “clearly and conspicuously disclose to users” all of the above bullets. The first few items seem harmless enough but then we start to get off into the weeds.
Apple wants you to reproduce, “clearly and conspicuously”, all the details of auto-renewing subscriptions. This information should be part of the standard StoreKit subscription purchase flow. None of these bullets have anything app specific to them. They are just boilerplate legalese.
Apple has an iOS level user interface flow for in-app purchases that is quite good as of iOS 11. This view already covers most of the in-the-weeds bullets, except telling users about the 24-hour renewal policy.
Requiring every developer to implement their version of 3.8(b) is costly and creates a fractured experience for the user. Apple should be putting it in the standard sheet. But it’s Apple’s walled garden. When they say jump, you say “fine, whatever.”
How to Comply With 3.8(b)
According to recent rejections that I’ve seen (as of Jan. 8th, 2018), reviewers are being more particular about what your purchase flow requires. From a recent rejection:
Adding the above information to the StoreKit modal alert is not sufficient; the information must also be displayed within the app itself, and it must be displayed clearly and conspicuously during the purchase flow without requiring additional action from the user, such as opening a link.
All of the information in 3.8(b) must be “displayed clearly and conspicuously during the purchase flow without requiring additional action from the user, such as opening a link.” Your beautiful and compact purchase flow must include in it, somewhere, nine bullets written by a lawyer.
Confide, recently updated, achieved it with the following:
According to one reviewer, being below the fold with a leading arrow qualifies as “clearly and conspicuously.”
For another data point, I know of one recently rejected developer who had the same information, but in another view that was linked from the purchase flow with a button. This did not qualify (according to one reviewer).
A Template
Include a customized version of the following “clearly and conspicuously” in your purchase flow:
A [purchase amount and period] purchase will be applied to your iTunes account [at the end of the trial or intro] on confirmation]. Subscriptions will automatically renew unless canceled within 24-hours before the end of the current period. You can cancel anytime with your iTunes account settings. Any unused portion of a free trial will be forfeited if you purchase a subscription. For more information, see our [link to ToS] and [link to Privacy Policy].
Put it on the screen where you initiate the in-app purchase, below the fold might be OK, but you might want to put something to lead users there.
UPDATE: Readers are telling me it may also be required that you include it in your app store description. It’s a much easier change to include so I recommend you add it there to.
Why has Apple Taken a Legal Problem and made it Ours?
Apple shouldn’t be burying submission requirements in the bodies of contracts that nobody will read. If Apple wants developers to know something, they should put it in the App Store Guidelines, HIG, or developer documentation. The cost of making changes in a software project right at the end can be astronomical. Dropping a bomb like this on developers at submission shows a total lack of regard for our costs.
Why didn’t they just update the iOS in-app purchase sheet? I speculate that Apple discovered some legal exposure from in-app subscriptions and fixed it with lawyers instead of designers. This problem could be universally solved with an iOS update, but I think some side effect of Apple being a vast, lumbering bureaucracy made forcing 3.8(b) onto developers the more politically convenient path. Apple, if you are reading this, please either update the iOS sheet or move the requirements to the App Store guidelines, so fewer developers get caught unawares.
You might also like
- Blog post
Implementing in-app purchases and monetizing your Roku app: A step-by-step guide
A comprehensive guide to implementing and monetizing your Roku channel, from choosing the right strategy to technical tips and integration best practices.
- Blog post
How we built the RevenueCat SDK for Kotlin Multiplatform
Explore the architecture and key decisions behind building the RevenueCat Kotlin Multiplatform SDK, designed to streamline in-app purchases across platforms.
- Blog post
Inside RevenueCat’s engineering strategy: Scaling beyond 32,000+ apps
The strategies and principles that guide our global team to build reliable, developer-loved software