Apple Will Reject Your Subscription App if You Don’t Include This Disclosure

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):

I really like the part about privacy policies.

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.

iOS’s purchase UI, more than enough information.

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.

RevenueCat is the best way to implement subscriptions in your mobile app. We handle all the complicated parts so you can get back to building. Request an invite today at https://www.revenuecat.com/