Rejected Under 2.3.1(a) and 4.2 at Once: How to Respond

Key takeaways

A combined 2.3.1(a) and 4.2 letter makes two claims – functionality App Review couldn't see or wasn't told about, and an experience that felt like a website – and both need an answer.
App Review pairs them because each finding strengthens the other: unreachable features make an app look thin, and features that appear later make a thin app look like it hid something.
Native apps get this pair too: in a May 2026 forum thread, a native shift-tracking app received it after updates added features.
Fix first when the reviewer was right, reply when they missed something, and appeal to the App Review Board only with specific reasons – one appeal per rejection, after answering any questions.
WebViewGold, made by our team, puts native features into native navigation where reviewers find them; appsubmitter.io can draft the reply, the appeal and the notes.

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.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 2.3.1 - Performance - Accurate Metadata

The app appears to include hidden features, or features that are not described in the Notes for Review.

Guideline 4.2 - Design - Minimum Functionality

The app feels similar to a web browsing experience and does not provide enough app-like functionality.

Paraphrased example – the exact wording in your message may differ.

Rejected under 2.3.1(a) and 4.2: what each half of the letter means

Being rejected under 2.3.1(a) and 4.2 at the same time means App Review makes two separate claims: your app contains functionality the reviewer couldn't find or wasn't told about, and what the reviewer could use felt like a website in a frame. The letter is only resolved when both claims are answered – usually with a corrected build, specific notes and one precise reply.

The first half rests on the opening sentence of Guideline 2.3.1(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.

The second half is the first sentence of Guideline 4.2 Minimum Functionality:

Your app should include features, content, and UI that elevate it beyond a repackaged website.

One developer quoted a letter that squeezes both into a single line: the app "has hidden features and feels similar to a web browsing experience". Treat it as two questions with two kinds of evidence:

	The 2.3.1(a) half	The 4.2 half
What App Review concluded	Some functionality wasn't visible, reachable or described	The reachable experience matches the website in a browser
Typical evidence	Features behind an unshared role or sign-in, things switched on after review, notes that only say "improvements"	Web menus, full-page reloads, browser behavior, no device features in the main journey
What answers it	Access to every feature, and notes that say what changed and where	Native value in the core journey that the reviewer meets without searching

Why App Review pairs hidden features with minimum functionality

At first sight the pairing looks contradictory: how can one app be too thin and full of hidden features? From the reviewer's chair it is consistent. A reviewer judges the app they can reach in one session with the account you provided. Whatever they can't reach earns you nothing under 4.2 – and if there are signs it exists, it counts against you under 2.3.1.

Two loops produce the combined letter:

Hidden makes thin. The substance of the app sits behind a login, a role or a menu the reviewer never opens. What remains – a start page, a sign-in form, a few static screens – is a textbook 4.2 case.
Thin, then surprising. A modest version passes, and functionality grows afterwards, through the server or a large update. The next reviewer meets features no note announced and starts asking what else changed.

Apple says it watches for the second loop: its fraud report of May 20, 2026 describes machine learning that can "flag potentially problematic changes in app updates" (Apple Newsroom). Assume every update is compared with what was approved before, and make the difference easy to read.

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 →

A native app got the same letter: the May 2026 forum case

The combination isn't reserved for wrappers. In May 2026, a developer turned to the Apple Developer Forums after their shift-tracking app – written natively, with no web view and no embedded website – was rejected repeatedly. Versions one and two had been approved. The trouble began when updates brought more: a monthly calendar with shift templates, live tracking with Live Activities and the Dynamic Island, a shift history, overtime and extra-pay rules, notifications and export, spread over four tabs.

The answer App Review posted in the thread didn't discuss the app itself. It pointed to an appeal to the App Review Board and set three ground rules: give specific reasons why the app complies with the guidelines, submit only one appeal per rejection, and respond to any requests for additional information before appealing.

We don't know how the case ended, so treat it as an anecdote rather than a precedent. Three lessons hold anyway:

The 4.2 half describes the reviewer's experience, not your technology – a native app can be told it feels like browsing.
Big updates are where 2.3.1(a) bites. When a release adds half a dozen features, notes that map each one to a tab and a test path spare the reviewer from discovering them alone.
Appeals have a format, and App Review spelled it out. Use it.

How WebView apps end up with both findings in one letter

In wrapper and hybrid apps, the same root causes show up again and again – and most of them feed both halves at once:

Pattern	Reads as 2.3.1(a) because	Reads as 4.2 because	Fix
Most of the app sits behind sign-in, and the demo account fails, expires or is empty	The listing promises features the reviewer never reaches	What's left is a start page and a login form	A working account with realistic data and a list of what lies behind the login
Native features reachable only through the website's menu	The scanner or Face ID exists, but nothing points to it	The visible app is web navigation on web pages	Native entry points in a tab bar or sidebar, named in the notes
Content or features switched on after review	Classic hidden functionality	The reviewed version was emptier than the live one	Release features with versions; switch on only what was reviewed
Native modules compiled in but wired to nothing	Dormant features	They add nothing the reviewer can see	Remove them or connect them to a visible task
App mode strips sections the website has	The app does less than its listing suggests, without explanation	Fewer features, same web interface	Use app detection for layout only and document deliberate differences
"Bug fixes and improvements" on a release with new tabs	Apple says generic descriptions will be rejected	The reviewer misses the new native parts	One note per feature: what, where, how to try it

The single-guideline articles go deeper: 2.3.1 for WebView apps on remote switches and 4.2 for WebView apps on the side-by-side Safari comparison.

Fix first, reply or appeal? A decision tree for the combined letter

Work through these questions in order. Each one either sends you to a fix or on to the next question.

Does the letter ask you anything? Answer every question first. Apple expects information requests to be handled before an appeal, and sometimes the question is the whole problem.
Did anything change on your side while the app was in review? Check deploys, CMS toggles and flags. If yes, the 2.3.1 half is probably right: freeze or document the change, then resubmit with notes that cover it.
Can a stranger reach every feature? Install the submitted build fresh and sign in with the exact credentials from your notes. If anything fails, fix access first – that alone can explain both halves.
Does the main journey still match your website in Safari? Then the 4.2 half is right, and no wording will change it. Add native value, upload a new build and describe it.
Everything checks out? The reviewer probably missed something. Send the two-part reply described below.
Rejected again for the same reasons? Appeal to the App Review Board with specific reasons – one appeal per rejection – or request a 30-minute App Review appointment through Meet with Apple and walk through the app together (Apple's App Review page).

Don't jump straight to the last step. Apple warns that apps repeatedly rejected for the same guideline violation take longer to review, and an appeal can't change what the build is. If you're unsure where you stand, appsubmitter.io can go through the letter with you in a free consultation call.

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.

Discover WebViewGold Let us submit your WebViewGold app

How to answer both halves in one reply to App Review

Answer in App Store Connect, under the rejected submission. Replies hold up to 4,000 characters plus attachments (App Store Connect Help) – enough if you write in lists and keep the two halves apart:

Context in one sentence: what the app does, for whom, and how it is built.
The 2.3.1(a) part, feature by feature. Every feature of the version with its location and a test path, new ones marked as new. If something had been switched on after an earlier review, say so and say what you changed.
The 4.2 part, capability by capability. Each native capability with the user task it serves and how to trigger it, for example "scan a ticket: Tickets tab → Scan → use the sample QR code attached".
Access: accounts per role, sample data, any one-time code the reviewer needs.
A closing question asking which screen raised either concern, if the letter didn't say.

Then copy the same content into the version's Notes for Review: the reply answers this reviewer, the notes brief the next one. Templates for that field are in our article on Notes for Review under 2.3.1.

What the screen recording should prove

For this letter a recording does double duty: it shows that every feature is reachable and that the app behaves like an app. Film the submitted build on a physical iPhone from a fresh install, sign in with the review credentials, visit the features in the order of your reply and include the moments a website can't fake – a push arriving and opening its screen, the offline screen in Airplane Mode, a Face ID prompt, a scan. If the app pairs with external hardware, Apple wants a video of the physical setup instead; our 2.1 Information Needed guide covers the recording mechanics.

Prevention: update notes that say what changed and where to find it

Most combined letters are prevented by a habit, not a feature. Apple's page on providing information for a complete review puts the core of it in one line:

Updates: Describe what's changed, and where reviewers can find significant new content or features.

The same page asks for the devices and OS versions you tested, the external services behind your core functionality and any regional differences. Build that into every release:

Keep a changelog per version written for a reviewer, not for your team.
Freeze feature deploys to your web content while a build is in review; content and fixes can continue.
Write both texts: What's New for customers (Guideline 2.3.12) and Notes for Review for App Review.
Re-test the demo account on submission day – Apple says credentials that expire or change before the review starts may get the submission rejected.
Give new native features a visible entry point where the reviewer lands, not three menus deep.

Making native value visible with WebViewGold – and help with the reply

In WebView apps, the 4.2 half is often less about missing features than about features nobody finds. WebViewGold, the website-to-app product built by our own team, is a ready-made Swift project for Xcode: you set your URL in Config.swift and switch on native modules. For a combined letter, these do the most work:

Native navigation footer or sidebar – main sections and native features become visible entry points instead of items in a web menu.
Push notifications via OneSignal, Firebase or Pushwoosh that open the matching screen.
A native offline screen instead of a blank view when the connection drops.
Face ID and Touch ID to reopen signed-in areas.
QR, barcode and document scanners where users would otherwise type or upload.
App Version Check API and custom user agent – your web code learns which app version is running, so a feature appears only in the build whose notes describe it.

WebViewGold is a one-time purchase; you own the project and publish in your own developer account, and the separately sold Cloud Builder builds without a Mac. It can't promise an approval – the reviewer still judges the journey you build. If a hybrid can't carry your product, a native rebuild, Capacitor with bundled web assets or a progressive web app outside the App Store are the honest alternatives.

appsubmitter.io covers the paperwork side of this letter. An App Specialist combines an AI-powered guideline check with a human review to choose between fix, reply and appeal, drafts the two-part reply or the App Review Board appeal, rewrites your Notes for Review and talks to App Review from your own developer account. Code changes aren't included and are quoted upfront if you need them. 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 [number]). We have gone through both points in your message – Guideline 2.3.1(a) and Guideline 4.2 – and would like to answer each of them.

About the app: [App name] helps [audience] to [main task]. [It shows content from [domain] in a WebView and adds native navigation, push notifications and a scanner. / It is a native app built with [framework].]

1. Guideline 2.3.1(a) – all features and where to find them
New in this version:
- [Feature] – [tab or screen] – [how to test]
- [Feature] – [tab or screen] – [how to test]
Already in earlier versions:
- [Feature] – [tab or screen]
[Nothing in the app is switched on or changed after review. / We found that [feature] had been enabled after the previous review; it is now part of this version and described above.]

2. Guideline 4.2 – what the app adds beyond a website
- [Native navigation: Home, Orders, Scan and Account are native tabs.]
- [Push notifications for [event] that open the matching screen. To test: [steps].]
- [Offline screen with a retry button; [content] stays readable without a connection.]
- [Face ID re-login / barcode scanning for [task]. To test: [steps].]

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

A screen recording of all of the above on [device, iOS version] is attached. If a particular screen raised either concern, we would be grateful for a pointer.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

You decided which half of the letter was right: hidden or undocumented functionality, a web-like experience, or both.
Every question in the letter is answered before any appeal.
Nothing was deployed, flagged on or unlocked between submission and rejection without a matching note.
Every feature can be reached on a fresh install with the demo accounts from your notes, and those accounts hold realistic data.
Native features have visible entry points in native navigation, not only in a web menu.
Native modules nothing uses are removed or connected to a visible task.
The core journey differs from your website in Safari in ways a reviewer notices within minutes.
Your reply answers 2.3.1(a) feature by feature and 4.2 capability by capability, within 4,000 characters.
A screen recording from a physical iPhone shows the submitted build, every feature and the native moments.
The Notes for Review of the next version say what changed and where to find it.

Frequently asked questions

What does "hidden features and feels similar to a web browsing experience" mean?

It packs two findings into one sentence. "Hidden features" points to Guideline 2.3.1(a): App Review believes the app contains functionality it couldn't see, reach or read about in your notes. "Similar to a web browsing experience" points to Guideline 4.2: what the reviewer could use felt like your website in a frame. Each needs its own answer – access and documentation for the first, visible native value for the second.

Can a fully native app be rejected under 2.3.1(a) and 4.2?

Yes. In a May 2026 Apple Developer Forums thread, the developer of a native shift-tracking app without any web view reported exactly this pair after updates added features such as a shift calendar and Live Activities – the first two versions had passed. It's one anecdote, but it shows that the letter reflects the reviewer's experience of the app, not the framework behind it.

Should I appeal a combined 2.3.1(a) and 4.2 rejection?

Only when the build is sound: every feature reachable and documented, and a core journey that clearly offers more than your website. Answer any open questions first, then appeal to the App Review Board with specific reasons why the app complies – one appeal per rejection. If the reviewer was right about either half, fix the build instead; an appeal can't change what the app is.

Do I need a new build to answer this rejection?

For the 4.2 half, usually yes, because native value lives in the binary. For the 2.3.1(a) half it depends: if the reviewer only lacked access or clear notes, fixing the demo account and the notes may be enough. If features were switched on after review, decide what stays, make it reachable and ship it in a version whose notes describe it.

How long can my reply to App Review be?

Up to 4,000 characters, with attachments such as a screen recording, according to App Store Connect Help. That fits a context line, a feature list with test paths, the native capabilities and the accounts – if you write in lists. The Notes field under App Review Information holds up to 4,000 bytes, so accented and non-Latin characters use more of it.

Will WebViewGold get a WebView app past this rejection?

No tool can promise an approval. WebViewGold, made by our team, supplies the native pieces the 4.2 half asks about – navigation footer or sidebar, push, an offline screen, Face ID, scanners – plus an App Version Check API that ties web features to app versions for the 2.3.1 half. Placing them in the core journey and documenting them is still your part.

Sources and further reading

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.

Rejected Under 2.3.1(a) and 4.2: Hidden Features That Feel Similar to a Web Browsing Experience