App Store Review Guidelines: A Practical Guide for Small Teams

Apple's App Review Guidelines are long, and most of them will never apply to your app. The trouble is knowing which ones will. This guide maps how the document is organised, picks out the rules that most often hold up a small team's submission, and looks closely at one rule that matters if your app shows feedback from other users. Everything here is as of 19 March 2026.

Shipping on Android too? The Google Play version of this guide is Google Play Developer Policy: A Practical Guide for Small Teams.

The short version

• The guidelines have an introduction, a "Before You Submit" checklist, five numbered sections (Safety, Performance, Business, Design and Legal) and an "After You Submit" section.
• Apple says that, on average, over 40% of unresolved issues relate to guideline 2.1, App Completeness: crashes, placeholder content and missing information.
• Metadata (2.3), minimum functionality (4.2), in-app purchase (3.1.1) and privacy (5.1.1) are the other usual suspects.
• You are responsible for third-party SDKs in your app, including their content.
• If other users can read what people post in your app, guideline 1.2 on user-generated content expects filtering, reporting, blocking and published contact details.

How the guidelines are organised

The document opens with an introduction that sets the tone: Apple wants a safe store and a fair chance for developers, and it reserves the right to reject anything it believes is "over the line". Two points in the introduction are worth remembering. Trying to trick the review process gets apps removed and developers expelled from the program. And you are responsible for everything in your app complying with the guidelines, including ad networks, analytics services and third-party SDKs.

Then comes Before You Submit, a short checklist: test for crashes, complete your metadata, keep your contact details current, give App Review full access (a demo account or a full demo mode), keep your backend live during review, and explain non-obvious features in the review notes.

The body is five numbered sections:

It closes with After You Submit, which covers timing, status updates, expedited reviews, release dates, rejections, appeals and bug fix submissions. Our post on publishing an app on the App Store walks through the submission itself.

The guidelines that most often catch small teams

2.1 App Completeness

Apple's App Review page says that, on average, over 40% of unresolved issues relate to guideline 2.1. The guideline asks for a final version with working URLs and no placeholder text, tested on a device, with demo account details if the app has a login, and with your backend switched on. Most 2.1 rejections are avoidable with a test pass on a clean device and a demo account that still works on the day of review.

2.3 Accurate Metadata

Your description, screenshots and previews must reflect the app's core experience. Three parts come up often:

• 2.3.1: new features, functionality and product changes must be described specifically in the Notes for Review field.
• 2.3.3: screenshots show the app in use. Our screenshot sizes guide covers the rest of the screenshot rules.
• 2.3.12: the "What's New" text must describe new features and product changes. A generic line is fine for small fixes, not for significant changes.

Guideline 2.3.7 also caps app names at 30 characters and asks you not to stuff metadata with trademarks, other apps' names or pricing.

4.2 Minimum Functionality

An app has to be more than a repackaged website. If your app is mostly a web view around your site, expect questions. Native features, offline use and platform integration are what lift an app above that line.

3.1.1 In-App Purchase

If you unlock features or content inside the app, you must use in-app purchase. Licence keys, QR codes and similar mechanisms for unlocking are not allowed. Read the rest of section 3.1 before you design a paywall, because the exceptions are specific. If you are weighing the cost, our guide to the App Store Small Business Program covers the commission side.

5.1.1 Data Collection and Storage

Every app needs a privacy policy link, both in App Store Connect and somewhere easy to find inside the app. If your app lets people create an account, it must also let them delete that account from inside the app. And if the app has no significant account-based features, people should be able to use it without logging in.

1.5 Developer Information

Your app and its Support URL need an easy way to contact you. It sounds trivial, and it is often the missing piece in a rejection for user-generated content too.

Guideline 1.2: user-generated content and in-app feedback

Guideline 1.2 covers apps with user-generated content. As of 19 March 2026, it says such apps must include four things:

1. A way to filter objectionable material before it is posted.
2. A way to report offensive content, and timely responses to those reports.
3. A way to block abusive users from the service.
4. Published contact information so users can reach you easily.

Does a feedback board count?

Apple doesn't define a threshold, so this is our reading, not Apple's. It depends on who can read what people write.

• A private form, where a user's text goes to you and nobody else, works like a support channel. Other users never see it.
• A board other users can read, where requests, descriptions and comments from one person appear on another person's screen, is user-generated content shown to the public. We would treat that as covered by 1.2 and plan for all four items.

Most feature voting boards are the second kind. That is the point of them: people see what others asked for and vote instead of posting a duplicate. So if you add one, budget for moderation the same way you would for comments or reviews, and describe how you moderate in your App Review notes.

Before you press Submit

• Test the release build on a real device, signed out and signed in.
• Check that the demo account works and the backend is live.
• Describe every new feature in Notes for Review, and every significant change in What's New.
• Check the privacy policy link in the app and in App Store Connect.
• If users can create accounts, test in-app account deletion.
• If users can see each other's posts, check you have filtering, reporting, blocking and contact details.
• Review the SDKs you added since the last release, including what they show to users.

Beta builds go through their own review for external testers. Our TestFlight beta testing guide covers that side.

How FeedbackKit fits in

FeedbackKit puts a feature request board inside your app. Users post requests, read other people's requests, vote and comment. So by our reading above, it is user-generated content under guideline 1.2, and you should plan for it.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

To be plain about where things stand on 19 March 2026: the FeedbackKit SDK screens don't include a report button, user blocking or a filter for objectionable text. What you do have:

• In the native admin apps for iPhone, iPad and Mac you can remove a comment. In those apps or the web dashboard you can reject a request, and project owners and admins on Pro and Team can delete a request outright.
• The Swift SDK lets you hide the comment section on the detail screen if you don't want comments shown to other users.
• You choose where the board appears, so you can link your support contact next to it.

That covers removal and contact details, not filtering, reporting or blocking. If your board is visible to every user, add a reporting route of your own (for example, a "Report a post" link that emails your support address) and say in your review notes how quickly you act on reports. Setup is in the Swift docs, and the Kotlin SDK covers Android.

If you want users to vote instead of repeating themselves in reviews, start free.