Key takeaways
- Guideline 2.3.1 requires new features and product changes to be described with specificity in the Notes for Review – generic descriptions will be rejected.
- Apple's list for a complete review covers business model, changes and where to find them, audience, devices, external and AI services, regions and accounts.
- The Notes field holds up to 4000 bytes in any language; accounts per role, authentication codes and an expired-subscription account belong there.
- For WebView and hybrid apps, say what is native, what is web and what changes without a build – new functionality ships only with a reviewed version.
- Name each WebViewGold module – push, offline screen, Face ID, scanners, universal links – with its screen and a way to trigger it.
Our recommended solution
Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame
WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.
What the rejection typically looks like
Guideline 2.3.1 - Performance - Accurate Metadata
The Notes for Review don't describe the new features in this version with enough specificity for us to locate and review them.
Paraphrased example – the exact wording in your message may differ.
What does Guideline 2.3.1 expect from your Notes for Review?
Notes for Review are the reviewer-only text field under App Review Information in App Store Connect, and Guideline 2.3.1 turns them into an obligation: every new feature must be described there with specificity, and generic descriptions will be rejected. Good notes tell the reviewer what the app is, what changed, where to find it and how to get in.
The sentence that matters sits in 2.3.1(a) of the App Store Review Guidelines (last updated June 8, 2026):
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.
Apple's "Before You Submit" list also asks for "detailed explanations of non-obvious features and in-app purchases in the App Review notes", and Guideline 2.1(b) wants the notes to explain any configured in-app purchase the reviewer can't find.
The field is simple. According to App Store Connect Help, it "can contain up to 4000 bytes", accepts any language and, like all App Review Information, is hidden from customers and editable at any time. The sign-in account "must not expire"; further accounts go into the notes. What's New is a separate, customer-facing field (2.3.12).
Apple rejected more than 22,000 submissions in 2025 for hidden or undocumented features (Apple Newsroom) – and to a reviewer, a feature nobody wrote down looks exactly like a hidden one.
Apple's list for a complete review, item by item
Apple's help article Provide information for a complete review lists what App Review wants up front and warns: "Incomplete submissions will be rejected." Its items make a good skeleton:
| Item | In Apple's words | What to write |
|---|---|---|
| New apps | "Describe your app's concept and business model." | Audience, main job, revenue model: free, In-App Purchase, physical goods or B2B contracts |
| Updates | "Describe what's changed, and where reviewers can find significant new content or features." | One entry per change with its screen and test steps |
| Purpose and audience | "Describe the app's purpose and target audience." | One sentence; for business apps, who issues accounts |
| Devices tested | "List the device models and operating systems you tested the app on before submitting." | Exact iPhone and iPad models with OS versions |
| External services | "…data providers, authentication services, payment processors, or AI services" | Each service and its job, including the AI provider |
| Regional differences | "…or confirm that the app functions consistently across all regions." | Each difference and how to see it, or a confirmation |
| Account types | "…use the Notes field to add additional credentials for each type." | One password-based account per role, with sample data |
| Subscriptions | "…a demo account with an expired subscription to enable review of the entire purchase flow." | An account whose auto-renewable subscription has lapsed |
| Authentication codes | "…include it in the Notes field in advance." | The fixed code for the review account |
| Demo mode | "…show your app's full features and functionality using demonstration data." | Sensitive or regulated apps only; 2.1(a) requires Apple's prior approval |
Take the code row seriously: without the code, Apple says, "a call may be required to continue the review" – typically three to five business days. Hardware apps need a video (not a screen recording) on a physical device, regulated apps attach licenses, and if you're unsure what your review needs, Apple suggests a one-on-one App Review appointment first.
Rejected or stuck? Talk to an App Specialist – for free.
Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.
Generic descriptions will be rejected: what specific looks like
Specific doesn't mean long; it means the reviewer never has to guess. Test each line with four questions: what is it, where is it, how do I see it work and with which account, data or hardware? Five app review notes examples, before and after:
| Generic | Specific |
|---|---|
| Minor improvements and new features. | New in 2.4: table reservations. Restaurant page → Reserve → any date. The demo venue "Test Bistro" always has free slots. |
| The app works like our website. | Loads shop.example.com in a WebView. Native: order-status push (OneSignal), Face ID unlock, barcode scanner in Search. Web: catalog, cart, account. |
| AI features added. | New: packing suggestions. Trips → open a trip → Suggest. Trip name and dates go to [AI provider] after the user accepts a consent screen; no account data is sent. |
| Premium content available. | Auto-renewable subscription. Paywall: Profile → Go Premium. Account 3 below has an expired subscription for the full purchase flow. |
| Bug fixes. | No new features. Fixed: photo uploads over 20 MB failed; the checkout button was cut off on small iPhones. |
Quote on-screen labels exactly, in the interface language – German button names for a German app, even in English notes. And a release without new features should say so plainly.
How to structure Notes for Review for a WebView or hybrid app
Reviewers know that a WebView app can change on the server, so strong notes answer that question up front. Five blocks fit almost every hybrid app:
- Architecture: the domain the app loads and the native features the binary adds, in two sentences.
- Native parts: each module with its screen and a way to trigger it (WebViewGold modules are covered below).
- Server-side updates: what changes without a build – articles, products, schedules, prices of physical goods – and the commitment that new functionality only arrives with a version described in its notes.
- What's new: feature by feature in what–where–how–with form; for a first submission, the main journeys.
- Access and context: accounts per role, codes, services, devices, regions and in-app purchases.
Block 3 only helps if it's true: if a flag or CMS toggle can still add functionality after approval, fix that first – see remote switches and hidden features in WebView apps. And if App Review also said the app feels like a website, block 2 is your best argument; read 2.3.1(a) and 4.2 in one rejection, which also covers the update case of a fully native app.
Four Notes for Review templates to adapt
Replace the brackets, delete what doesn't apply and check the byte count before pasting. All four leave room for extra accounts.
Template 1: a new WebView app
About: [App name] by [company] helps [audience] [main task]. Business model: [free / In-App Purchase subscriptions / physical goods paid by card or Apple Pay].
How it is built: [domain] in a WebView, plus [OneSignal push for order updates], [Face ID unlock] and [a QR scanner for tickets].
Main journeys: 1) [Home → product → cart → checkout] 2) [Account → orders] 3) [Tickets → Scan].
Server-side content: [Products and articles] change daily; new functionality only ships with a new app version described in its notes.
Services: [hosting or CMS], [payments], [push], [analytics].
Tested on: [iPhone model, iOS version], [iPad model, iPadOS version].
Regions: [identical everywhere / delivery only in [country]].
Template 2: an update with new features
Version [x.y]: [two] new features, [three] fixes, sign-in and purchases unchanged.
New – [feature 1]: [Tab → screen → button]. [Result.] Test with [account and data].
New – [feature 2]: [Path, steps, permission prompt and when it appears.]
Changed: [Screen] now [difference]. Removed: [feature] – [reason].
Tested on: [devices and OS versions].
Template 3: AI features and third-party AI services
AI feature: [Name] at [path]: the user [enters text / takes a photo] and gets [result].
Provider and data: Our server sends [the entered text] to [provider], never [contacts, location or account details].
Consent: A screen names [provider] and asks for permission before the first request (Guideline 5.1.2(i)); users can withdraw it under [Settings → AI].
Safeguards: [daily limit], [content filter], [report button].
To test: [account] → [screen] → enter "[sample prompt]". Expected: [result]. If the service is down, the app shows [message].
Template 4: a role-based B2B portal
Who uses it: Employees of organizations under contract with [company]; their admins create accounts, there is no consumer sign-up [and nothing is sold in the app – licenses go to organizations only, 3.1.3(c)].
Accounts: Admin [user / password] – users, reports. Manager [user / password] – approvals. Employee [user / password] – requests, documents. All in the demo company "[name]" with sample data; together they reach every screen.
Sign-in: Customers use [SSO provider]; the demo accounts use passwords [plus the fixed code [code]].
Native features: [document scanner at Expenses → Scan], [push for pending approvals].
The fastest fix for most WebView rejections
WebViewGold: native features for your web app
Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:
- Push notificationsOneSignal or Firebase, for real, personal events
- Native offline screenNo browser error pages when the connection drops
- Native splash screenApp-like start instead of a loading web page
- Deep linksLinks open the right screen inside the app
- QR & barcode scannerDevice features the website alone can't offer
- In-app purchasesNative purchase flows where the store requires them
No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.
When should you attach a screen recording for App Review?
Some flows don't fit into text. Beyond the licenses and hardware videos Apple requires, a short screen recording often saves a round trip: for pushes triggered by real events, for features tied to a place, a time or a physical code – Apple's "Before You Submit" list mentions "a sample QR code" – and for the purchase flow of the expired-subscription account.
After a rejection, use Reply to App Review: up to 4,000 characters, with Attach File for recordings, screenshots or PDFs (App Store Connect Help). Copy anything new into the Notes field too, so the next version starts complete. Requests for missing accounts or videos are covered in our 2.1 Information Needed guide.
Keep your Notes for Review versioned in the repository
Notes typed straight into the App Store Connect form get copied forward until they describe an app that no longer exists. Treat them like code:
- A file per release. fastlane
deliverreadsmetadata/review_information/notes.txt(ornotesinapp_review_information), andapp_review_attachment_fileuploads an attachment such as an .mp4. Passwords belong in CI secrets, not in Git. - Same pull request, same line: a change users will see adds its note in the PR that introduces it.
- A byte check: fail CI if
wc -c < notes.txtexceeds 4000 – dashes, curly quotes and accented letters take more than one byte. - The web repository too: a web release that adds functionality waits for the app version whose notes describe it.
Describing WebViewGold features – and how we write notes for customers
If your app runs on WebViewGold, the website-to-app template built by our own team, its native modules are exactly what a reviewer looks for in a hybrid app – provided the notes point to them:
| WebViewGold module | What the notes should say |
|---|---|
| Push (OneSignal, Firebase or Pushwoosh) | Provider, trigger, when the permission prompt appears and how to receive a push – or that a recording is attached |
| Offline screen, local HTML | "Turn on Airplane Mode and relaunch to see the offline screen"; which bundled screens work offline |
| Face ID / Touch ID | Where users switch it on and what it protects |
| QR, barcode and document scanner, NFC | The screen and what to scan; a sample code as an attachment, a device video for NFC tags |
| Universal links | Paths that open the app, such as example.com/orders/*, and a link to tap in Mail |
| In-app purchases, ATT, rating dialog | Paywall path and products; when the ATT prompt and Apple's rating dialog appear – no custom rating prompts |
| Custom user agent | That the website hides its header and footer in the app and features match the browser unless listed |
At appsubmitter.io, review notes are part of every submission we handle: our AI-powered pre-submission check compares build, metadata and feature list with the guidelines, then an App Specialist checks each line against the build with every demo account, writes the notes in this structure and answers App Review's follow-up questions in your developer account. Code changes aren't included; if something needs fixing, we quote it upfront. Book the iOS submission service or bring your notes to a free consultation call. For the marketing half of 2.3.1, read Guideline 2.3.1 misleading marketing.
Template: how to reply to App Review
Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.
Hello App Review Team, Thank you for reviewing [App name] (version [x.y], build [build number]). We have rewritten the Notes for Review so that every new feature in this version is described with specificity and can be reached during review. New in this version: 1. [Feature 1] – [tab or menu path] – [steps to test] – [account to use] 2. [Feature 2] – [path] – [steps] – [account] How the app works: [App name] shows [domain] in a WebView and adds [push, Face ID, QR scanner]. [Products / articles] change on our server; new functionality only ships with a new app version described in its notes. Accounts (also listed in the Notes field): - [Role 1]: [username] / [password] - [Role 2]: [username] / [password] - Expired subscription: [username] / [password] External services: [push provider], [payment processor], [AI provider – users give permission before any data is sent]. Tested on: [devices and OS versions]. Regional differences: [none / description]. A screen recording of [flow] is attached. If any feature needs more detail, we will gladly add it. Best regards, [Your name] [Company]
Checklist before you resubmit
- New app: concept, audience and business model come first. Update: a short summary of what changed.
- Every new feature has its own line – what it is, where it lives, how to test it and with which account.
- The notes say which parts are native, which are web and what changes on the server without a build.
- External services (push, payments, sign-in, AI), tested devices, OS versions and regional differences are listed.
- Each account type has a non-expiring demo account; subscription apps add an expired-subscription account; codes are included in advance.
- The notes stay within 4000 bytes, measured in bytes rather than characters.
- The notes file is versioned in the repository and updated in the change that adds a feature.
Frequently asked questions
What should I write in the Notes for Review for Guideline 2.3.1?
Is the Notes field limited to 4000 characters or 4000 bytes?
wc -c before pasting it.Do I need new Notes for Review for every update?
How should I describe WebViewGold features in my review notes?
Will detailed notes get my app approved?
Recommended solution
From WebView rejection to approval: WebViewGold + appsubmitter.io
- 1 Build with WebViewGold Turn your website into native iOS and Android projects.
- 2 Add native value Push, offline screen, deep links or scanning in your main flow.
- 3 We submit it Our App Specialists submit and talk to the review team.
WebViewGold is made by our team (jocapps GmbH). It is a tool, not a guarantee – approval decisions are made by Apple and Google.
Sources and further reading
- Apple – App Store Review Guidelines, 2.3.1
- Apple – Provide information for a complete review
- App Store Connect Help – App Review Information (Notes, sign-in)
- App Store Connect Help – Reply to App Review messages
- Apple – Request an App Review appointment
- Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
- fastlane docs – deliver (app review information)
Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.