How to stay on top of guideline changes
Follow these steps in order. Each one is something we do on client work.
- Follow Apple's developer news. Apple posts guideline updates.
- Diff the guidelines. Save a copy and compare after updates.
- Map changes to your features. Payments, privacy, AI, kids.
- Plan fixes before deadlines. Some changes come with dates.
- Update review notes. Explain compliance.
- Re-check before each release. Quick scan.
App Store guidelines changes: key rules and context
Where Apple announces changes. Apple posts updates on Apple Developer News and marks changed sections in the Review Guidelines. Big updates often follow WWDC in June.
Where Google announces changes. Play Console inbox, email to the account owner, and the Policy Center. Google usually gives a compliance deadline.
A routine that works
- Subscribe to both sources.
- When a change lands, note which apps it touches.
- Check payments, privacy, permissions and metadata first.
- Fix before the deadline and note it in your release checklist.
Where we help. If a change has already caused a rejection, see the rejection hub or the App Rejection Fix.
Worked example (hypothetical)
This example is illustrative. The app is made up, and so are any numbers in it.
Say Apple updates a payments rule. A team that sells subscriptions would re-read 3.1.1 and 3.1.2, check their paywall and links, and note any changes in their next release.
Common mistakes
- Ignoring updates. Surprise rejections.
- Relying on blogs. Read the source.
- No diff. Missed changes.
- Last-minute fixes. Rushed releases.
If you want this handled for you, our pricing page lists every fixed package.
The guidelines behind most rejections
The table maps each point to the App Store guidelines changes context. Apple revises the guidelines, so open the live document before you reply to App Review. Where a row paraphrases Apple, the official wording always wins.
| Guideline | What it covers | Usual fix |
|---|---|---|
| 2.1 App Completeness | Final builds, working URLs, no placeholder content | Fix crashes, add a demo account, test every link |
| 2.3 Accurate Metadata | Description, screenshots and previews reflect the app | Re-shoot screenshots from the real app; remove claims you can't show |
| 2.3.7 | Unique name, accurate keywords, no trademarked or irrelevant terms | Remove competitor names and pricing from metadata |
| 3.1.1 In-App Purchase | Digital features and content unlocked via IAP | Move digital unlocks to StoreKit IAP |
| 4.2 Minimum Functionality | More than a repackaged website | Add native, useful features |
| 4.3 Spam | No duplicate bundle IDs or saturated copycat apps | Consolidate apps; show what is unique |
| 5.1.1 Data Collection and Storage | Privacy policy, permissions, account deletion (5.1.1(v)) | Add policy links, clear purpose strings, in-app deletion |
How we measure the result
After you fix and resubmit, keep a short record: the guideline or policy cited, what you changed and the reviewer's reply. Patterns show up quickly. The same issue coming back means the fix didn't reach the root cause, such as a library adding a permission or an old screenshot set in another localization. Before each future release, run the checklist below. It takes less time than a second rejection.
Checklist
Copy this list into your release notes or ticket and tick each item off before you ship.
- News followed
- Copy saved for diff
- Changes mapped
- Fixes planned
- Notes updated
Sources
- Apple: App Review Guidelines (accessed 26 October 2026)
- Google Play Developer Policy Center (accessed 26 October 2026)
Questions
How often does Apple update the guidelines?
Several times a year.
Do changes apply to live apps?
They apply at your next submission, sometimes sooner.
Does Google warn before enforcing?
Usually, with a deadline.
Should I follow blogs?
Use official sources first.
Can you audit my app after a change?
Yes.
Where does Apple publish guideline changes?
On the App Review Guidelines page and in Apple Developer news.