Guideline 2.3.1 Rejection in AI-Built Apps: How Prompts Create Hidden Features and How to Document Them

What a Guideline 2.3.1 rejection means for an AI-built app

A Guideline 2.3.1 rejection means App Review found a gap between what your app can do and what you showed or told the reviewer. In AI-built apps that gap rarely comes from intent. It opens on its own: the agent added features nobody listed, a republish changed the live app, or generated copy promised more than the app delivers.

The rule sits in the Accurate Metadata section of the App Store Review Guidelines (last updated June 8, 2026). Read phrase by phrase, it sets four duties and one warning:

This is not a rare edge case. Apple's own count for 2025 is more than 22,000 rejected submissions for hidden or undocumented features, and its review pairs people with machine learning built to "flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026). An app that changes a lot between submissions gives that system plenty to look at. The listing side of the same section – names, keywords, screenshots, What's New – is covered in our Guideline 2.3 guide.

Why do AI-built apps end up with undocumented features?

Hand-written apps drift too, but AI builders remove the natural brakes: code review, release branches and a person who knows what changed. Four mechanisms stand out.

• Every prompt can add a feature. Agents rarely do exactly one thing. Ask for a settings page and you may also get a CSV export, team invitations and a theme switch. Each extra is functionality the reviewer may find and your notes don't mention.
• The chat history is not a changelog. It records what you asked for, including attempts that were reverted or overwritten later. It can't tell you which features were live in which build – and that is the question App Review asks.
• Publishing is a release. One click deploys the web app, and a native app that loads your URL changes with it. The app Apple approved and the app your users run can differ within a day, without anyone deciding to change the iOS app.
• Scaffolding stays behind. On the way to what you wanted, the agent may have built an admin dashboard, seed data, test routes and half-finished screens. Code that exists but isn't reachable is the textbook dormant feature.

A fifth source isn't code at all: the marketing text the builder generated for you. It gets its own section below.

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.

Free consultation call Book our service →

Hidden, dormant, undocumented: how each one shows up in generated apps

Leftovers are the easiest of the three to remove. Search the code for routes such as /admin, /test, /debug or /dev, for sample users and placeholder records in seed files, and for components no screen links to. Guideline 2.1 already asks for "placeholder text, empty websites, and other temporary content" to be scrubbed before submission; in an AI-built app the same cleanup protects you under 2.3.1.

The feature inventory: turn your code into a feature list

Apple rarely names the feature it means, and nobody remembers two hundred prompts. Build the list from the source instead. It takes an afternoon and becomes the base of every later submission.

1. Export the routes. Sync the project to GitHub or download the code, then list every page and route, including those no menu links to.
2. List the server side. Database tables, serverless or edge functions, scheduled jobs, webhooks and integrations such as payments, email or AI models. They are invisible in the interface but often power what is visible.
3. Ask the agent, then check the answer. A prompt like List every user-facing feature, its route and every role, plan or flag that controls it. Do not change any code. gives you a first draft. Verify it against the routes – agents describe what they meant to build, which isn't always what exists.
4. Map each feature to a screen and a test step that a stranger can follow in two minutes, plus the account to use.
5. Flag what the reviewer can't reach: anything behind a role, plan, region, flag, device or sign-in method the review account lacks.
6. Decide per flag. Make it reachable, explain it (a screen recording for hardware, for example) or remove it for every user.
7. Diff against the last approved version. Everything that is new since then belongs in this submission's notes.

The result is a short table you keep next to the code:

Builder by builder: where to start looking

The mechanics differ per builder (as of October 2026), and so does the first place to check. Our product articles go into detail:

If App Review has already escalated to the Developer Code of Conduct, the product articles on 5.6 for Lovable, Bolt and Base44 cover that situation.

Where 2.3.1 meets Guidelines 4.2 and 5.6

Not only a WebView problem

In May 2026 a developer described on the Apple Developer Forums how a fully native shift-tracking app – no WebView at all – passed review twice and then had updates rejected under 2.3.1(a) and 4.2 after gaining features such as a monthly calendar with shift templates. The letter said the app "has hidden features and feels similar to a web browsing experience", and App Review's answer in the thread pointed to an appeal to the App Review Board. One anecdote proves little, but the lesson is useful: new features that weren't spelled out can trigger 2.3.1 whatever the technology. Our article on the 2.3.1 and 4.2 combination explains how to answer such a letter.

The rule and the escalation

2.3.1 is the rule: functionality was undocumented or out of reach. Guideline 5.6 is the escalation. Developers who received 5.6 letters in 2026 report wording about features "that appear to have been intentionally hidden during the review process" – the same facts, read as a question of intent. 2.3.1(b) connects the two, because repeated gaps can end your program membership. Fix the process after the first 2.3.1 letter and the conduct question rarely comes up.

Generated marketing copy and prices count too

The same paragraph of 2.3.1 treats misleading marketing – "promoting content or services that it does not actually offer" or a false price, "whether within or outside of the App Store" – as grounds for removing the app and terminating the developer account. AI builders produce exactly this kind of copy in seconds:

• Landing pages with invented user numbers, star ratings and testimonials.
• Feature grids listing integrations or "AI-powered" tools the agent never built.
• Pricing tables with a "free" plan that is really a trial, or discounts that ended weeks ago.
• App Store descriptions pasted from that landing page.

If your wrapped app opens on the landing page, that page is part of the app as well as your marketing. Check it with the same care as the listing – the article on misleading marketing under 2.3.1 walks through claims, prices and AI promises in detail.

Fixing the rejection and keeping it fixed

1. Freeze new functionality until the next build is approved. Content updates and bug fixes can continue.
2. Run the feature inventory and remove leftovers.
3. Prepare accounts. Apple wants a username and password "that work at the time of submission"; for several account types, such as admin and regular users, the extra credentials go into the Notes field. Our 2.1 Information Needed guide covers codes, region locks and demo videos.
4. Write the notes. Apple's guidance for updates reads: "Describe what's changed, and where reviewers can find significant new content or features." Add the external services the app depends on – Apple's examples include authentication services, payment processors and AI services. The field holds up to 4,000 bytes; templates are in our Notes for Review guide.
5. Upload a new build if code changed, then reply to App Review with what you found and fixed.

For the native side, WebViewGold – the website-to-app product our team builds – gives an AI-built web app a few mechanics that support 2.3.1. Its App Version Check API passes the installed version and build number to your web code, and a custom user agent can carry the same marker, so a new feature can stay off until the build whose notes describe it. Screens that must not change after review, such as onboarding, can be bundled into the app as local HTML. Native modules – push, Face ID, the QR scanner, StoreKit purchases, Apple's rating dialog – are enabled at build time, which makes them easy to list in your notes. You buy it once and release under your own developer account; like any tool, it can't make App Review's decision for you.

appsubmitter.io covers the review paperwork: an AI-powered pre-submission check, then an App Specialist who goes through your feature list with you, writes precise Notes for Review and talks to App Review from within your own developer account. Code changes are discussed and quoted separately. Book the iOS submission service, or ask your questions first in a free consultation call.

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 pointing out the issue under Guideline 2.3.1.

The web part of our app is built with [builder] and served from [domain]. We compared the code with our previous Notes for Review and found these gaps, which this submission resolves:

1. [Feature] was added after our last approved version and was not described. It is now listed below with test steps.
2. [Feature] was only reachable with an [admin / paid] account. An additional demo account is included below.
3. [Unused admin route / test checkout] was left over from development and has been removed.
4. [Claim on our website or in the description] did not match the app and has been removed.

Features in this version and how to reach them:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]

Accounts:
- [Role 1]: [username] / [password]
- [Role 2]: [username] / [password]

From now on, new functionality reaches app users only with a new version whose Notes for Review describe it.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Every route, page and backend function in the repository appears in your feature inventory.
• Each feature has a screen, a test step and an account that can reach it.
• Scaffolded admin pages, test routes, seed users and placeholder content are gone.
• No flag, test key or "coming soon" switch waits to activate functionality after approval.
• Everything new since the last approved version is described specifically in the Notes for Review.
• Demo credentials work at submission time, and every account type has its own login in the Notes field.
• Landing page, ads, listing and in-app copy only promise what the app does, at prices that are true.
• No new functionality is published to the web app while the build is in review.
• Authentication, payment and AI services the app relies on are named in the notes.
• New features reach app users only with the build whose notes describe them, for example via a WebViewGold version marker.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
• Apple Developer – Provide information for a complete review
• App Store Connect Help – App Review information (Notes, demo account)
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
• Apple Developer Forums – Repeated 2.3.1(a) + 4.2 rejection after adding more native features (May 2026)
• 9to5Mac – Apple pushing back on vibe coding iPhone apps (March 18, 2026)
• WebViewGold Docs – App Version Check API (iOS)

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.