WebView App Rejected Under Guideline 5.6: The Fix (2026)

Key takeaways

Guideline 5.6 is about conduct, not technology: Apple flags behavior that looks deceptive, such as features that only appear after review.
WebView apps are exposed because their content can change without a new build – and Apple says it uses machine learning to flag problematic changes.
Most 5.6 cases in legitimate WebView apps come from feature flags, app detection, login walls, redirects or custom review prompts – all fixable.
Fix the cause, describe every feature in the Notes for Review, add native value (for example with WebViewGold) and reply politely with test steps.

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 5.6 - Developer Code of Conduct

We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process.

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

What Guideline 5.6 actually says

Guideline 5.6 is the Developer Code of Conduct, the last section of the App Store Review Guidelines (last updated June 8, 2026). Most guidelines describe something in your build. This one describes how you behave as a developer, which is why a 5.6 rejection feels so personal. Two sentences matter most:

Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program.

Apps should never prey on users or attempt to rip off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.

The section has four sub-points, and each of them can surface in a WebView app:

5.6.1 App Store Reviews – ask for ratings with Apple's API; Apple says it "will disallow custom review prompts". A "Rate us 5 stars" pop-up on your website appears inside your app, too.
5.6.2 Developer Identity – the way you represent yourself, your business and your offerings must be accurate, truthful and up to date.
5.6.3 Discovery Fraud – no manipulation of charts, search, reviews or referrals.
5.6.4 App Quality – excessive customer reports, negative reviews and refund requests can be a factor in judging your conduct.

5.6 overlaps with Guideline 2.3.1, which bans "hidden, dormant, or undocumented features" and requires every new feature to be "described with specificity in the Notes for Review". The difference is the stakes: under 5.6, Apple treats the issue as a question of trust in you, not just a metadata problem. Our Guideline 2.3 guide covers the metadata side in detail.

Why WebView apps get flagged under 5.6

Apple doesn't reject apps for using WKWebView. It flags apps whose behavior it can't trust, and WebView apps have one property that makes them stand out: most of what the user sees comes from your server. The app can change without a new build and without a new review.

Apple is open about watching for exactly that. In its fraud report from May 20, 2026, Apple writes that its systems combine human review with machine learning that can "analyze app similarity, and flag potentially problematic changes in app updates". In 2025, Apple rejected over 22,000 submissions for containing hidden or undocumented features and removed nearly 59,000 apps for bait-and-switch behavior (Apple Newsroom).

Developers who received a 5.6 rejection in 2026 report wording about "a pattern of unusual behavior" that is "commonly associated with fraudulent activity" and "features that appear to have been intentionally hidden during the review process" – often without naming the feature. In WebView apps, these are the usual suspects:

Conditional content. Feature flags, A/B tests, remote config or geo-targeting that show the reviewer a different app than your users get.
App detection that hides more than layout. Hiding your website header inside the app is good practice. Hiding a pricing page, a wallet, a chat or a whole section only while the app is in review is the pattern 5.6 describes.
Login walls. If the reviewer can't sign in, everything behind the login is effectively hidden from review.
Redirects and domain switches. The start URL redirects to another domain, or the domain shows a different site after approval.
Deploys during review. A web release went live while the app was in review, so the reviewer saw two different versions.
Review prompts and incentives. Web pop-ups asking for 5-star ratings, or rewards for leaving a review.
A mass-produced look. Many near-identical wrapper apps from one template or account, which also touches Guideline 4.3 Spam.

Apps built with AI and no-code builders hit several of these at once, because they are easy to redeploy and often share default designs – see why AI-built apps get flagged under 5.6.

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 →

Find your trigger: a structured diagnosis

Apple rarely names the screen it means, so walk through the app the way a reviewer does: a fresh install on an iPhone and an iPad, the demo account from your review notes, no saved cookies. Then compare what you see with what a regular user sees today.

Check	What to look for	Typical fix
Feature flags and remote config	Any flag that was off during review and is on for users now	Ship features with a build and describe them in the review notes
App detection	Code that checks the user agent, a URL parameter or a JavaScript bridge and changes features, not just layout	Use app detection for layout and native integrations only; same features for every app user
Reviewer access	Expired demo account, one-time codes sent to your inbox, an empty account without data	A password-based demo account with sample data and notes on where every feature lives
Redirects	Start URL that jumps to another domain, a landing page or a "coming soon" page	Load the final URL directly and keep the domain stable
Payments	A web checkout for digital goods that users see but the reviewer didn't, or the other way round	In-App Purchase where required, shown consistently – see 3.1.1 for WebView apps
Ratings	Custom "rate us" modals or rewards for reviews	Only Apple's native review request
Identity and metadata	Description promises features the app lacks; seller name unrelated to the website's owner	Match the listing to the app and publish under the business that runs the service

Then check your deploy history. If anything went live on your website between submission and rejection, write down exactly what changed. That list often explains the rejection, and it belongs in your reply.

How to fix a WebView 5.6 rejection step by step

Remove reviewer-specific behavior. Delete any logic that treats a review session differently from a normal user. Differences between the app and the browser are fine when they concern presentation or native integration, such as hiding the site footer or using native sharing. They are not fine when they decide which features exist.
Freeze new features during review. Keep publishing content and bug fixes as usual, but release new functionality to app users only after a build whose review notes describe it has been approved.
Make everything reachable. Provide a demo account that signs in with a password, comes with realistic data and has access to every paid or role-based area. If some features need special hardware or a location, say so and attach a short screen recording.
Describe every feature in the Notes for Review. Guideline 2.3.1 says generic descriptions will be rejected. List each feature, where it lives and how to test it.
Replace custom review prompts. Use Apple's native review request (StoreKit) and remove rating pop-ups from your web content when it runs in the app. WebViewGold includes a native in-app rating dialog that you can trigger from your web code.
Add native value to the core journey. A reviewer trusts an app more when it clearly is an app: push notifications for real events, a native offline screen, Face ID sign-in, universal links. WebViewGold ships these as configurable modules in an Xcode project, so you don't have to build them from scratch.
Check identity and metadata. Seller name, support URL, privacy policy and description should all point to the same business and describe what the app really does.
Ship a new build. Increment the build number, test it on a real device through TestFlight, select it for the version in App Store Connect and only then reply and resubmit.

If you are unsure which of these applies to you, our App Specialists can look at the rejection with you in a free consultation call before you resubmit.

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

What you can still change on your website after approval

Showing fresh web content is the whole point of a WebView app, and Apple accepts it. The line runs where a change alters what the app is or does without a review. In its statements on blocked vibe-coding app updates in March 2026, Apple pointed to Guideline 2.5.2 and its developer license terms, under which downloaded code must not change the app's primary purpose (9to5Mac).

Usually fine without a new build	Ship with a new build and review notes	Never
Articles, products, prices of physical goods, events, bug fixes, visual refreshes within the same purpose	New major features, new purchase flows, user-generated content, new data collection, account deletion changes	Switching the app to another business or purpose, unlocking content you kept away from review, gambling or crypto features added silently

A simple rule works for most teams: if a change deserves a new line in your review notes, it ships with a new build. And if the web content starts collecting new kinds of data, update your App Privacy details as well – see our article on Guideline 2.3.1 for WebView apps for more examples.

Replying to App Review – and when to appeal

Reply in App Store Connect

Open the rejected submission and use Reply to App Review. Replies are limited to 4,000 characters and you can attach files such as a screen recording (App Store Connect Help). Guideline 5.6 itself asks you to treat everyone with respect, "including your responses in App Store Connect", so keep the tone factual even if the accusation feels unfair.

A good reply lists what you checked, what you changed and how the reviewer can test every feature. If the message doesn't say which feature looked hidden, ask politely for the screen or flow concerned – and in the same reply, explain the features most likely to have caused the concern.

Appeal to the App Review Board

If you are confident the app hid nothing and App Review misunderstood it, you can appeal via Apple's App Review page. Apple asks for specific reasons why the app complies, allows one appeal per rejected submission and expects open questions to be answered first.

Talk to App Review

Apple offers 30-minute video appointments with App Review through Meet with Apple. After a 5.6 rejection, a conversation can clear up a misunderstanding faster than another round of messages.

If your account is affected

Guideline 5.6 states that a Developer Program account will be terminated for conduct that breaks the code, and that you may provide a written statement detailing the improvements you plan to make to restore it. Apple terminated 193,000 developer accounts over fraud concerns in 2025. Don't open a new account to get around a rejection – that makes the case worse, not better.

How to keep your WebView app out of 5.6 trouble

Release discipline: no feature deploys to app users while a build is in review; content and fixes are fine.
Feature flag policy: flags may stage a rollout of a reviewed feature, never switch on something App Review hasn't seen.
Pre-submission check: test the review account, the start URL and every paid area on the day you submit.
Consistent app detection: detect the app (for example via a custom user agent suffix) only to adapt layout and enable native modules.
Review notes in the repository: versioned next to the code and updated with every feature change.

This is the kind of work appsubmitter.io takes off your plate: AI-powered pre-submission checks flag risky patterns, and an App Specialist reviews the app, writes precise review notes and handles the communication with App Review in your own developer account. Code changes aren't included, but we discuss and quote them upfront if your app needs any. When the native side is missing, we usually recommend WebViewGold, the website-to-app solution built by our team, and submit the result for you – book appsubmitter.io or start with a free 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]). We take Guideline 5.6 seriously and have reviewed the app carefully.

The app has no hidden or dormant features. All app users get the same functionality as the reviewer. To make this fully transparent, we have:

1. [Removed / documented] [e.g. a feature flag that enabled the in-app chat after review]. The chat is now included in this build and described below.
2. Provided a demo account with full access and sample data: [username] / [password].
3. [Replaced our web rating pop-up with Apple's native review request.]

Features and how to test them:
- [Feature 1] – [where it is] – [steps]
- [Feature 2] – [where it is] – [steps]
- [Feature 3] – [where it is] – [steps]

A short screen recording of these flows is attached. If a specific screen or flow raised the concern, we would be grateful for a pointer so we can address it directly.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

No feature flag, remote config or A/B test switches on functionality the reviewer has not seen.
App detection (user agent, URL parameter, JavaScript bridge) only changes layout and native integrations, never which features exist.
No web deploys with new features while the build is in review.
The demo account signs in with a password, has realistic data and reaches every paid or role-based area.
The start URL loads directly without redirects to other domains or landing pages.
Rating requests use Apple's native review API; no custom rating pop-ups or review incentives.
The Notes for Review list every feature with its location and test steps.
Description, screenshots, seller name and support URL match the app and the business behind it.
The core journey includes native features such as push, offline handling or Face ID.
A new build was tested through TestFlight before replying and resubmitting.

Frequently asked questions

Does Apple reject apps just for using a WebView?

No. There is no rule against WebViews, and many approved apps use them. Apple judges what the app offers (Guideline 4.2) and whether it behaves honestly (Guideline 5.6). A 5.6 rejection means something about the app's behavior looked deceptive – the WebView only made it possible.

Apple didn't say which feature was hidden. What should I do?

Work through feature flags, app detection, login walls, redirects and recent web deploys, fix what you find, then reply with a complete feature list and test steps. Politely ask which screen or flow raised the concern. If you get no clarity, a 30-minute App Review appointment via Meet with Apple can help.

Can I still update my website after the app is approved?

Yes. Content, products, articles and bug fixes are normal for a WebView app. New major features, purchase flows or anything that changes the app's purpose should ship with a new build and be described in the review notes.

Can a Guideline 5.6 rejection cost me my developer account?

It can. Guideline 5.6 states that accounts will be terminated for conduct that breaks the code, and Apple terminated 193,000 developer accounts over fraud concerns in 2025. Most first rejections are resolved by fixing the cause and replying transparently. Never try to get around it with a new account.

Will WebViewGold prevent a 5.6 rejection?

No tool decides how Apple judges your conduct. WebViewGold removes typical WebView weak spots – it gives you a native rating dialog, push notifications, an offline screen, Face ID and StoreKit in-app purchases – but feature flags or hidden areas on your website are yours to fix. Our team can check both before you resubmit.

Should I hide my web paywall from the iOS app?

If the app unlocks digital content, Apple generally expects In-App Purchase, and external purchase links are only allowed in certain storefronts. Whatever you decide, apply it consistently to every app user, not just during review. Our Guideline 3.1.1 guide explains the current rules.

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.

WebView App Rejected Under Guideline 5.6: How to Fix a Developer Code of Conduct Flag