How to write App Store Notes for Review that pass

Notes for Review is the free text field in the App Review Information section of each version in App Store Connect, and it is now the part of a submission that most often decides whether an update sails through. Apple's guideline 2.3.1(a) says that all new features, functionality and product changes must be described with specificity in Notes for Review, and that generic descriptions will be rejected. A note that passes tells the reviewer three things: what changed in this build, exactly where to find each change, and what the reviewer needs to reach it (an account, a purchase state, a region, a piece of hardware). This guide gives you a template, good and bad examples, demo account rules and a checklist you can run before every submission.

What Apple actually asks for

The wording of guideline 2.3.1(a) is short and strict:

All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.

Two words matter. Specificity means a reviewer can act on the note without guessing. Accessible means the reviewer can actually get to the feature during the review, which is where demo accounts, sandbox purchases and feature flags come in.

On October 16, 2026 Apple published two related updates. The App Review Guidelines gained 2.5.19, which Apple describes as clarifying its long standing policy on hidden, dormant or undocumented features, a rule that used to sit under 2.3.1. The text is direct: don't include any hidden, dormant or undocumented features, and your app's functionality should be clear to end users and App Review. In a separate news post about bait and switch apps, Apple explained that 2.5.19 targets apps that misrepresent what they do during review and change after approval, for example by adding features that were not in the version submitted to App Review. Apple says apps doing this are subject to removal from the App Store and from the Apple Developer Program.

For most honest indie apps the practical change is simple: if something in the build can be switched on, the note should say it exists and how to see it.

Apple's App Review help page on providing information for a complete review lists what it wants in the App Review Information section:

• For a new app: the concept and the business model.
• For an update: what changed, and where reviewers can find significant new content or features.
• Purpose and target audience.
• The device models and OS versions you tested on.
• External services the app depends on, such as data providers, authentication services, payment processors or AI services.
• Regional differences in features or content, or a confirmation that the app works the same everywhere.

The 4000 byte limit

App Store Connect Help says the Notes field can contain up to 4000 bytes, and you can write notes in any language. Bytes, not characters. In UTF-8, plain English letters take one byte each, but accented letters usually take two, most Chinese, Japanese and Korean characters take three, and emoji take four. A note in Japanese runs out at roughly a third of the length of an English one.

To check before you paste, save the note as a text file and run wc -c notes.txt. If you are over, cut history first: the reviewer needs the current build, not the story of how you got there. Regulated apps should attach documents in the App Review Information section instead of describing them.

A template that works

This structure has held up across a lot of submissions. Fill in what applies and delete the rest.

WHAT CHANGED IN 3.4 (build 212)
1. [Feature name]: [one sentence on what it does].
   Where: [Tab] > [Screen] > [Control].
   Needs: [account type, data, permission or purchase state].
2. [Next change, same shape.]
Bug fixes: [the two or three that a user would notice, with where].

HOW TO TEST
Sign in with the account in Sign-in Information. It has sample
data loaded and a Pro subscription.
[Steps for anything not visible on first launch.]

OTHER ACCOUNTS
Free user: [username] / [password]
Expired subscription: [username] / [password]

PURCHASES IN THIS VERSION
[Product names, where the paywall appears, anything unusual.]

FLAGS, REMOTE CONFIG AND REGIONS
All features in this build are enabled for the review accounts.
[Any regional difference, or "Works the same in all regions."]

EXTERNAL SERVICES
[Sign in provider, payment processor, AI service, data source.]

TESTED ON
[Device models and OS versions.]

Good and bad examples

These are the patterns that come back with a 2.3.1 rejection, next to versions that give the reviewer what they need. The examples use a made up habit app called Streakly.

A full good note for that Streakly update reads like this:

WHAT CHANGED IN 3.4 (build 212)
1. Shared streaks: two people can keep one streak together.
   Where: Today > tap any habit > Share (top right).
   Needs: a second account to accept the invite (below).
2. Pro: yearly plan added next to monthly.
   Where: Settings > Streakly Pro.
Bug fixes: reminders now fire after a time zone change.

HOW TO TEST
Account A (Sign-in Information) is Pro with 30 days of data.
Account B: reviewer2@streakly.example / [password]
Share a habit from A, accept the invite on B.

FLAGS, REMOTE CONFIG AND REGIONS
No remote flags in this build. Same features in all regions.

What's New is not Notes for Review

Guideline 2.3.12 asks you to clearly describe new features and product changes in What's New, and allows a generic description only for simple bug fixes, security updates and performance improvements. That text is for customers. Notes for Review is for one person testing your build. Write both, and don't paste one into the other.

Demo accounts that do not stall the review

Guideline 2.1(a) asks you to include demo account information, and to turn on your back end, if your app has a login. Apple's help pages add the details that cause most delays:

1. Credentials must work when you submit. Apple says credentials that expire or change before the review starts may get the submission rejected. Don't rotate the review password while a build is in the queue.
2. One account goes in Sign-in Information, the rest in Notes. App Store Connect Help says details for additional accounts belong in the Notes field. If you have admin and member roles, give one of each.
3. Subscriptions need an expired account. If your app offers auto-renewable subscriptions, Apple asks for a demo account with an expired subscription so the reviewer can go through the entire purchase flow.
4. Plan for one time codes. If sign in needs an authentication code, put it in the Notes in advance. Apple warns that without it a call may be needed, and that calls typically complete within three to five business days.
5. Make the account look used. Seed it with realistic data so no screen in your note is an empty state.
6. Check your own blockers. Rate limits, geo blocking, device limits and fraud checks are common reasons a reviewer cannot sign in. Allowlist the review accounts.

If you cannot provide a demo account for legal or security reasons, guideline 2.1(a) allows a built in demo mode instead, but only with prior approval from Apple.

Feature flags, remote config and 2.5.19

Most small apps use some remote configuration. The safe reading of 2.5.19 and the October news post is that the reviewer should be able to see everything the build can do. In practice:

• If code for an unfinished feature ships in the binary, either remove it or make sure it cannot be turned on until it goes through review in a later version.
• If a feature is behind a flag, say so in the note and turn the flag on for the review accounts.
• If behavior differs by region, list the difference. Apple's complete review page asks for this explicitly.
• Don't use a server switch to add functionality after approval. That is the pattern Apple describes in its bait and switch post.

New articles or levels are normal content updates. Apple's line is about features and functionality, so when in doubt, document it and ship it in a reviewed version.

Checklist before you press Submit

• Every user visible change is listed with a path to reach it
• No line says only "improvements", "fixes" or "new features"
• The demo account works today, will not expire and has data
• Extra account types are in the Notes with credentials
• An expired subscription account is included if you sell auto renewable subscriptions
• One time code or sign in method is explained
• In-app purchases in this version are listed with where to find them (guideline 2.1(b))
• Flags and remote config are listed, and everything is on for review accounts
• Regional differences are stated
• External services are named
• Test devices and OS versions are listed
• The note is under 4000 bytes
• What's New is written separately, for users
• The contact phone number is in international format with a plus sign

Let your changelog write the first draft

The hard part is remembering everything that changed since the last approved version. Your commit history already knows. asopilot reads the changes you describe or your GitHub commits, drafts Notes for Review and What's New from the same input, asks a follow up question when a change is too vague to describe, and only writes to App Store Connect after you approve. If you want to see how your current product page holds up first, run the free App Store audit.

The same specificity applies to your public metadata. Our guide to the subtitle and keyword field covers the fields reviewers read under guideline 2.3.7, and if you are shipping for the new foldable, see preparing screenshots for iPhone Duo.