Apple edits the App Store Review Guidelines a few times a year, and most small app teams find out when a build gets rejected. This is the setup I use to get a Slack message the day the guidelines page changes.

The first time a guideline change hit us, we didn't read about it. We got a rejection. A build that had passed review for months came back citing a section none of us had opened since launch. The rule had been updated weeks earlier. Apple had posted about it. Nobody on the team saw the post.

That's the normal way small app teams learn about guideline changes, and it's the expensive way. You lose a release day, sometimes a week, arguing with App Review about a rule you could have planned for.

So now the guidelines page posts into Slack. When Apple changes it, a short message tells us which section moved and what it says now. Here's the setup.

Which page to watch

The rules live on one long page: developer.apple.com/app-store/review/guidelines/. It's the source of truth, and the sections are numbered (3.1.1 for in-app purchase, 4.2 for minimum functionality, 5.1.1 for data collection and so on), which makes alerts easy to read.

I also watch Apple's developer news page, developer.apple.com/news/, because Apple usually announces guideline updates there. The news post tells you that something changed. The guidelines page tells you what.

Why a plain "page changed" alert is useless here

The guidelines page is huge. A basic diff watcher will fire on a fixed typo, a reworded link, or a navigation change, and it'll hand you a wall of highlighted text with no idea which part matters.

What I actually want is one line. So I write the alert as a sentence instead of a selector:

Alert me when a numbered guideline section is added, removed or reworded. Name the section number and summarize the change in one or two sentences. Ignore navigation, footer, typo and link-only edits.

For the news page it's simpler:

Alert me when Apple posts news about App Review or the App Store Review Guidelines.

Route it to the people who ship

We send both to a #app-store channel with the iOS lead, the product manager and whoever owns subscriptions. An alert looks like this:

App Store Review Guidelines changed: section 3.1.1 now has new wording about links to external purchase options. Summary in thread.

The iOS lead replies in the thread with one of three words: "fine", "check" or "ticket". That's the whole process. Most changes get "fine". The ones that touch payments, login or data collection usually get "ticket", and those are the ones that would have been a rejection.

Things I learned the hard way

  • Check daily. The page doesn't change often, and hourly checks just add noise to your quota.
  • Watch Google Play's policy updates too if you ship Android. Same problem, different page.
  • Read the full section when an alert fires. The summary tells you where to look. It doesn't replace reading the rule.
  • Keep the channel small. If the whole company is in it, nobody owns the reply.

The tool

I run this on AyeWatch because I can describe the change I care about in plain English and it posts straight to Slack. There's a Free Preview, and Pro is $9/month. Any page monitor that can summarize a change and push to Slack would do the job.

The goal is boring. The next guideline change should show up as a Slack line you read over coffee, not as a rejection email on release day.

Originally published on Medium.