Key takeaways
- Guideline 2.3.1(a) bans hidden, dormant and undocumented features and requires every new feature to be described with specificity in the Notes for Review.
- In a WebView app the risk sits on your server: feature flags, remote config, geo rules and user roles can change the app without a new build.
- Content, products and bug fixes can go live any time; new features, purchase flows and new kinds of data collection belong in a new version with specific notes.
- Apple says data collected via web traffic in web views must be declared, so your App Privacy details change whenever your web content collects something new.
- WebViewGold, made by our team, lets you set a custom user agent that carries your app version, so your website can tie new features to the build App Review approved.
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
We found that your app enables features from a remote source that were not available during our review and are not described in the Notes for Review.
Next Steps
Make all features accessible for review and describe new features, functionality and product changes with specificity in the Notes for Review section of App Store Connect.
Paraphrased example – the exact wording in your message may differ.
What Guideline 2.3.1 requires from a WebView app
A WebView app rejected under Guideline 2.3.1 has rarely hidden anything on purpose. Far more often, App Review came across functionality its reviewer could not reach, that appeared after the review, or that the Notes for Review never mentioned. The guideline has two parts (App Store Review Guidelines, last updated June 8, 2026):
(a) Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review. 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. Similarly, marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price, whether within or outside of the App Store, is grounds for removal of your app from the App Store or a block from installing via alternative distribution and termination of your developer account.
(b) Egregious or repeated behavior is grounds for removal from the Apple Developer Program. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to follow suit; if you’re dishonest, we don’t want to do business with you.
Put simply: everything the app can do must be visible to the reviewer, every new capability must be explained in the notes of the version that brings it, and your marketing – including the website that runs inside your app – must not promise what the app doesn't deliver.
Apple's Developer Program License Agreement points the same way. Section 3.3.1(C) says that, without Apple's prior written approval or the In-App Purchase API, an app "may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store, Custom App Distribution or TestFlight". A server that switches on new app functionality can fall under that sentence.
Remote switches: where hidden features come from in WebView apps
Native apps hide features in code. WebView apps hide them in configuration, usually without anyone deciding to hide anything. Look at these switches first:
| Remote switch | Typical example | What App Review experiences | How to make it reviewable |
|---|---|---|---|
| Feature flags and remote config | A LaunchDarkly, Firebase Remote Config or homemade flag keeps the marketplace off until launch day | A smaller app than users get a week later | Switch it on for the review account and describe it in the notes |
| CMS and admin toggles | A plugin activated later, a "show wallet" checkbox | Sections that did not exist during review | Treat toggles that add functionality like a release |
| Geo-targeting | Delivery booking only in Germany, IP-based redirects | The reviewer's location decides which app they see | List regional differences and how to see each variant |
| Role-gated areas | Seller dashboards, admin consoles, B2B price lists | A basic account that never reaches most of the app | One demo account per role |
| Cohort and time rules | Areas unlocked after seven days, invite-only betas | Features nobody can reach in a review session | Make them reachable for the demo account or keep them out |
| Unlinked routes | /beta, ?debug=1, a staging switcher | Dormant functionality that is reachable but undocumented | Remove them or block them for app users |
None of these tools is forbidden, and staged rollouts are normal engineering. The trouble starts when a switch decides which features exist for app users and the reviewer stood on the wrong side of it. App detection that changes more than layout belongs on the list too – our article on Guideline 5.6 for WebView apps explains how that becomes a conduct question.
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.
What may change on your website after approval – and what needs a new version
Here is the mechanic many teams miss: Notes for Review belong to an app version. The only way to describe a new feature to App Review is to submit a version, so a feature that needs describing also needs a submission – even if the binary barely changes.
| Web change | Route |
|---|---|
| New articles, products, events or translations | Publish any time |
| Bug fixes, speed improvements, a refreshed design of existing screens | Publish any time |
| A new analytics or chat script | Publish, then update App Privacy details; if it tracks users across other companies' apps and websites, App Tracking Transparency comes first |
| A new feature such as bookings, messaging or user uploads | New app version, described in the Notes for Review |
| A new purchase flow or paid tier | New app version, plus In-App Purchase where required – see 3.1.1 for WebView apps |
| A different business or core purpose behind the same app | Never through the website – that is a new product with its own review |
To bind web features to reviewed versions, put the app version into your app's user agent (for example MyApp-iOS/2.4) and let the website enable a new feature only for app versions that went through review with it. Browser visitors get it whenever you like; app users get it with the version whose notes described it. Code that goes beyond web content is a separate topic – see Guideline 2.5.2 and downloaded code.
Writing Notes for Review that hold up under 2.3.1
"Generic descriptions will be rejected" is the bluntest phrase in 2.3.1, and it targets notes like "Bug fixes and improvements". The Notes field under App Review Information holds up to 4,000 bytes, accepts any language and is never shown to customers (App Store Connect Help). Write it like a test script:
- One sentence on architecture: the app shows content from example.com in a WebView and adds push notifications, Face ID sign-in and a QR scanner.
- What is new, feature by feature, with the screen where each one lives and steps a stranger can follow in two minutes.
- Accounts per role. The main demo account goes into the sign-in fields, further accounts into the Notes field – and the demo account must not expire.
- Regional differences and server-side behavior: which content changes without app updates, and that new functionality arrives with app versions.
| Too generic | Specific enough |
|---|---|
| Improved booking experience. | New: rebooking. Bookings tab, open a past booking, tap Book again. The demo account has three past bookings. |
| New social features. | New: recipe comments. Open any recipe, scroll to Comments. Report and block sit in each comment's three-dot menu. |
The What's New text is for customers and has its own rule in 2.3.12; a good release needs both. For login-protected apps, the access side of your notes is covered in our 2.1 Information Needed guide. Templates for more app types are in our guide to Notes for Review that pass 2.3.1.
Keep App Privacy details in step with your web content
Guideline 2.3 explicitly counts "privacy information" among the metadata that must reflect the app and stay current. In a WebView app, that information depends on your website more than on your binary, and Apple says so: "Data collected via web traffic must be declared, unless you are enabling the user to navigate the open web" (App privacy details on the App Store). Typical moments when your label changes:
- Marketing adds a pixel to the tag manager. If it tracks users across other companies' apps and websites, you also need App Tracking Transparency – see Guideline 5.1.2 for WebView apps.
- Support installs a chat widget or session recording tool.
- A form gains a phone number, an address or a date of birth.
Apple says you may update your answers at any time without submitting an app update, and that keeping them accurate is your responsibility. Make it a rule that whoever publishes a new script or form field also updates App Store Connect.
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.
2.3.1 or 5.6: one root cause, two levels of trouble
2.3.1 is the documentation rule: the app contains functionality App Review did not see or was not told about. 5.6, the Developer Code of Conduct, is the trust rule: Apple suspects the gap was intentional. The documentation angle is common – Apple reports rejecting more than 22,000 submissions in 2025 for hidden or undocumented features (Apple Newsroom).
A first 2.3.1 rejection is usually an access and documentation problem you can solve within days. But 2.3.1(b) warns that egregious or repeated behavior can cost you your Developer Program membership, and web features that keep appearing after review are the pattern that turns a documentation case into a conduct case.
How to fix a WebView app rejected under Guideline 2.3.1
- Export every switch that affects app users – flags, config keys, CMS toggles, geo rules, role checks – with its state during review and today.
- Decide per switch. What is live for users goes into this version's notes and becomes reachable for the reviewer. What you are not ready to show stays off for every app user.
- Bind features to versions through the user agent instead of release dates.
- Prepare access: a password-based demo account per role with realistic data, plus a screen recording for anything that depends on location or hardware.
- Rewrite the notes and fix the What's New text if it undersells the release.
- Update App Privacy details and remove claims on your website or listing that the app doesn't deliver.
- Resubmit and reply with the list of switches you documented or removed; upload a new build if the binary changed.
If you want a second opinion before resubmitting, appsubmitter.io offers a free consultation call with an App Specialist.
A release setup that keeps App Review in the loop
Most of this is process, but the native shell can make the process easier. WebViewGold, the website-to-app product built by our own team, gives you a ready-made Xcode project: you put your URL into Config.swift and switch on native modules. Three of its features help with 2.3.1:
- Custom user agent – include your app version, so your website can gate new features by reviewed version.
- Local HTML bundling – screens shipped inside the bundle are part of the binary App Review sees, a good fit for onboarding or offline screens.
- Native modules set at build time – push, Face ID, the QR scanner or In-App Purchases arrive with a build. Enable only modules you use: one your website can call but never did during review is a dormant feature.
WebViewGold is a one-time purchase, you own the project and you publish in your own developer account. It can't promise an approval – the flags on your server stay your responsibility.
appsubmitter.io covers the submission side: an AI-powered pre-submission check plus a human App Specialist, Notes for Review that list every feature, current App Privacy details and the conversation with App Review. Code changes aren't part of the package; if your app needs any, we quote them before you commit. Book the iOS submission service.
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]) and for your feedback regarding Guideline 2.3.1. [App name] displays content from [domain] in a WebView and adds native features ([push notifications, Face ID sign-in, QR scanner]). We have reviewed every server-side setting that affects app users: 1. [Feature, e.g. the marketplace module] was controlled by a remote flag. It is now available to all app users and described below. 2. [Feature, e.g. the seller dashboard] requires a seller account. A second demo account is listed below. 3. [Feature] is only offered in [country]. To see it, [steps] – a screen recording is attached. 4. New web features are now tied to app versions and will be described in the Notes for Review of the version that introduces them. Features in this version and how to test them: - [Feature 1] – [screen] – [steps] - [Feature 2] – [screen] – [steps] Accounts: - Customer: [username] / [password] - [Seller / Admin]: [username] / [password] We have also updated our App Privacy details to cover [data type, e.g. chat messages]. Best regards, [Your name] [Company]
Checklist before you resubmit
- Every feature flag, remote config key, CMS toggle, geo rule and role check that affects app users is listed with its current state.
- Functionality that is live for app users is reachable with the demo accounts named in the Notes for Review.
- Functionality you are not ready to show is off for every app user, not only for the reviewer.
- New web features are gated by app version, for example through the user agent, not by release date.
- The Notes for Review describe each new feature with its screen and test steps – no generic phrases.
- Each role has its own demo account that does not expire.
- App Privacy details match what your web content collects today, including scripts, widgets and form fields.
- Unlinked routes, debug parameters and staging switchers are gone from production.
Frequently asked questions
Can a WebView app be rejected under Guideline 2.3.1 if I never hid anything?
Do I need a new app version for every change to my website?
Are feature flags allowed in an App Store app?
How long can the Notes for Review be?
Do I have to update App Privacy details when my website changes?
Does WebViewGold prevent 2.3.1 rejections?
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 Accurate Metadata
- App Store Connect Help – Platform version information (App Review notes)
- Apple – App privacy details on the App Store
- Apple – Apple Developer Program License Agreement (section 3.3.1)
- Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
- App Store Connect Help – Reply to App Review messages
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.