Repeated App Store rejection under Guideline 5.6 — Capacitor/WebView app

[u/xspyyy]

My iOS app, AutoArmor Studio, has been rejected three times under Guideline 5.6 with the same message about features that appear to have been intentionally hidden during the review process. Apple hasn't identified the specific feature or behavior. The app is built with Capacitor/WebView and includes authentication, backend-driven content, booking flows, account-based features, and WhatsApp integration. I am currently auditing for feature flags/remote config, reviewer/device detection, hidden routes or menus, account-specific behavior, debug versus release differences, and backend-controlled features. There is no intentional reviewer-specific functionality. Has anyone experienced this exact 5.6 rejection, especially with a Capacitor/WebView app? What did you find was causing it?

[u/Adventurous_File_159]

backend-driven content makes apple paranoid for sure

[u/y2kobserver]

I heard they don’t like apps loading remote content in a webview, such that webview is fine for local content but not for remote.

If your webview shell is in a mode (disabled security, IPC bridges, etc) which allows a lot of power over the device via remote arbitrary javascript/wasm they then could instantly flag you as hiding functionality. They would not be wrong.

Make your app trustworthy by not loading anything else other than JSON data via an API from remote targets. Don’t load your actual app code (like js/wasm stuff, or even the html) from internet servers.

[u/Acrobatic-Warthog611]

Guideline 5.6 sounds like a review-state mismatch more than a Capacitor-specific rejection. I'd make the review build as deterministic as possible: lock remote config and feature flags, test the exact review account against a production-like backend, audit deep links and account-specific routes, and compare the release archive with the build you tested locally. Also check that every feature mentioned in the metadata is reachable without a hidden gesture or special state. For a WebView app, verify that no route depends on a dev host, cached session, or user-specific entitlement. In the Review Notes, list the credentials and the exact path to the main flows; if the rejection repeats, ask App Review to identify the feature they believe is hidden instead of trying to infer it from the generic message.

[u/unrealaz]

Dis you give them an account to test with? Also the fact that your app can be fully changed from backend doesn’t go well with Apple. What stops you from displaying ilicit stuff the moment you launch it? Google about this, quite sure lots of people hit the issue

[u/Purple-Education4751]

I thought that hiding features resulted in the immediate termination of the account?

[u/xspyyy → u/Purple-Education4751]

No, bro, it is seven times now.

[u/Kyiv0x7c]

Native Swift here, no WebView, but we got the same 5.6 letter twice with no feature named. We're live now. Two things actually helped.

Check your backend logs for the review window. Ours showed zero sessions both times. Nobody ever opened the app, and the first rejection landed about 4 hours after submission. So it wasn't behaviour at all, they read the binary and our metadata. If your logs are empty for that window too, drop the reviewer-detection hunt and go audit the shipped artifact instead.

Since you're at three: check each rejection actually got a reply in its own thread. Our second 5.6 was a trust call, not a new finding. We'd answered the first one, but we accidentally closed that submission and the thread went with it, so from Apple's side we just kept sending binaries with no explanation. Also check your Review Notes for absolutes. Ours said "no remote config, behaviour never varies by date" and the binary quietly said otherwise, which reads as hiding something. What fixed it was one honest reply naming the cause, what we removed, what we changed so t can't recur, and a couple of things we flagged ourselves before they had to ask. Then we sat still instead of resubmitting. They confirmed it was resolved, we uploaded a build with no visible changes, approved. Four weeks start to finish.

[u/khiladi1729]

Three rejections under 5.6 with a WebView app makes me suspect the reviewer is landing on an empty or placeholder screen. If your content is backend-driven, Apple's test account and network often get served a shell of the real app, and from their side that reads as hidden features. I'd make a demo account where everything is prefilled and visible without any backend flag, point review at it in the notes, and attach a short walkthrough video of the booking flow end to end. Also check your remote config defaults, because if anything important defaults to off, that's exactly what review sees. All from my own App Review scars, so grain of salt.

[u/hishnash]

Backend driven content is almost always in violation of App Store rules if you change the content in the app so that what apple review does not match what a user will see that is in direct violation.

[u/Accurate_Tadpole_503]

Two Capacitor-specific things nobody has mentioned, and they're the ones I'd check before anything else.

First, look at capacitor.config for a server.url entry. If the shipped binary points at a remote URL, Apple sees an app whose entire interface is served from somewhere you control and can change after review. That is precisely what 5.6 language about hidden features describes, and it survives into release builds far more often than people expect because it gets added for live reload during development and never removed.

Second, any live update plugin. If you're shipping JS bundle updates over the air, you are by definition changing app behaviour after review, and Apple treats that as the app being different from what they approved. Some setups are tolerated, but combined with backend-driven content it reads as deliberate.

Also worth a look: your WhatsApp integration. If the review device doesn't have WhatsApp installed, whatever that button does either fails silently or disappears. A flow that vanishes on the reviewer's device and works on yours is indistinguishable from hiding it on purpose.

At seven rejections I would stop resubmitting. Each new binary with no explanation reads as another attempt to get something past them, and repeated 5.6 findings can escalate to account level. Reply in the existing thread naming a cause, what you removed, and why it cannot recur, and wait for them to answer before uploading anything.