# WebView App Rejected Under Guideline 5.6: The Fix Apple has no rule against WebViews. Guideline 5.6 rejections on web-built apps come from three things: an interface that looks like the tool that generated it, an app that adds nothing over your website, and a build a reviewer could not verify. Here is what clears each one. ## Does Apple reject apps for using a WebView? No. There is no guideline against WebViews, and guideline **2.5.6** requires apps that browse the web to use the appropriate WebKit framework and WebKit JavaScript, with an entitlement path for alternative browser engines in the EU and Japan. On iOS, WKWebView is the sanctioned way to render web content. The advice circulating online is that Apple rejects WebView apps, so you have to rebuild in Swift. That is wrong in a way that costs people months. WKWebView is also the foundation used by mainstream hybrid wrappers such as Capacitor and Cordova. What does get flagged is different. Guideline **5.6** is the Developer Code of Conduct, and a rejection under it arrives with language about a pattern of unusual behavior associated with fraudulent activity and features that appear to have been hidden during review. Unlike a purely technical rejection, it carries account-level implications, because Apple states that a Developer Program account will be terminated for actions not in accordance with the code, and that restoring it means a written statement of improvements Apple has to approve. References below are checked against the [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) as updated on June 8, 2026. ## What is Apple actually measuring? Similarity, utility, quality, accurate representation, and whether the app can be verified. Apple publishes that its systems analyze app similarity, but not how signals are weighted. All of those are things its review rules explicitly evaluate. None is a rendering engine. Apple's App Review team evaluated more than 9.1 million submissions in 2025. Over 371,000 were rejected for copying other apps, spam, or misleading users, against roughly 22,000 for hidden or undocumented features. Those are global category totals, so they cannot tell you why any single app was flagged, but they do show where enforcement volume sits. Source: [Apple's 2025 App Store fraud analysis](https://www.apple.com/newsroom/2026/05/the-app-store-stopped-over-2-point-2-billion-usd-in-fraudulent-transactions-in-2025/). Guideline **4.3(b)** puts the similarity point plainly: do not submit apps that are indistinguishable from what is already widely available. ## Why does an AI-built interface look suspicious? Because a thousand projects ship the same one. Leaving an AI builder's default theme in place produces the same palette, radius, font stack, and card rhythm across unrelated apps. Apple has not disclosed screen weighting, so treat this as the first similarity signal worth eliminating. The component libraries are not the problem. shadcn/ui is well built and accessible and is explicitly designed to be customized: the components land in your repo as source you own, and the visual identity lives in CSS variables you are meant to set. What produces the generic result is an agent scaffolding it and stopping there. Being built with AI is not itself an App Review violation. Apple regulates what the resulting app does and how it is submitted. Where AI-built apps run into trouble is low-effort similarity, and an untouched default theme is what that looks like from outside. The auth screen is where it shows most, because it is the first thing a reviewer sees on an app they cannot otherwise verify. Centered card, rounded icon tile, "Welcome back", Continue with Google, an OR divider, iconed email and password fields, "Don't have an account? Create one". Every project from that builder has it. 1. **Set your tokens first.** Palette, radius scale, typeface, spacing rhythm, border weight. Every component generated afterwards inherits your identity instead of the default one. 2. **Change the auth composition.** Move off the centered card. Split layout, top-anchored form under a full-bleed header, or a two-step email-then-password flow. 3. **Set a typeface.** Highest-leverage single change available. The default system stack is the most recognizable tell there is. 4. **Rewrite every string** on the auth screens in your product's voice. 5. **Replace the generated icon.** Ship a flat 1024x1024 PNG with no alpha channel, made deliberately rather than prompted and shipped. Changing the accent color is not a redesign. The layout is the fingerprint. ## What does your app need to add beyond your website? Enough that installing it is worth doing. Guideline **4.2** asks for features, content, and UI that elevate the app beyond a repackaged website, and **4.2.2** says apps should not primarily be marketing materials, web clippings, content aggregators, or a collection of links. The test is utility, not architecture. **The question to answer: what does the installed app experience add over opening your site in Safari?** If you cannot answer it, the guideline is talking to you. This is not a question about what browsers can technically do. Modern Safari and Home Screen web apps support a great deal, including web push, badging, and sharing, so framing native capability as things a browser cannot do is both wrong and beside the point. What 4.2 asks for is app-level integration that improves your specific product. Examples of app-level integration: * StoreKit purchases and subscriptions, and Play Billing on Android * Face ID and Touch ID through the platform's own biometric flow * Native notification handling, including how alerts behave when the app is backgrounded * Native camera and photo picker flows * Platform share integrations, both sharing out and receiving shares * Native haptics * Contacts, calendar, and precise location access * App-specific deep link and universal link behavior * Background capabilities * Offline behavior that survives a cold start You do not need all of them. You need the ones your product would genuinely use, implemented and reachable in the build you submitted. More importantly, these integrations are how you demonstrate the additional utility and app-like experience that 4.2 asks for. A submission that opens a URL and stops fails that test. Rewriting the same product in Swift would not, by itself, cure it, because the guideline is about what the app does rather than what it is written in. ## Why could the reviewer not verify your app? Two causes, and both land a legitimate app in the hidden-features bucket by accident. Either the build points at an environment that does not expose everything you are asking Apple to approve, or the reviewer could not sign in and could not find features you never described. **The build points at an incomplete environment.** Apple does not require production specifically, but the features you are submitting have to be accessible to App Review under guidelines **2.1(a)** and **2.3.1(a)**, and a staging URL or a preview deployment usually lags the live app. Separately, guideline **2.5.2** prohibits downloading, installing, or executing code that introduces or changes features or functionality after review, which is why over-the-air content updates are fine and post-approval functionality changes are not. Check your start URL before every submission. **Review could not get in or could not find things.** Guideline **2.1(a)** requires demo account details when the app has a login, final metadata with no placeholder content, and your backend live during review. Guideline **2.3.1(a)** goes further: features must be accessible to review, and every new feature must be described with specificity in Notes for Review, with Apple stating outright that generic descriptions will be rejected. In App Store Connect: 1. Open your app, then the version you are submitting. 2. Scroll to **App Review Information**. 3. Tick **Sign-in required** and enter demo credentials. 4. Verify those exact credentials on a real device the same day you submit. 5. In **Notes**, name each native capability and where to find it. "Face ID unlock: Profile tab, Security. Push notifications: prompted on first launch after onboarding." That field is where you tell a reviewer which parts of your app are native, which is worth doing when the interface runs in a WebView. 6. Say how to reach anything behind a purchase, a role, or a region. 7. Confirm your support URL and privacy policy URL both load. Also: **2.3.3** states screenshots should show the app in use, not merely title art, a login page, or a splash screen. ## How do quality problems become a conduct issue? Through guideline **5.6.4**, which names excessive customer reports, negative reviews, and excessive refund requests as indications of failing to maintain quality, and states that an inability to maintain high quality may factor into whether a developer is abiding by the Developer Code of Conduct. That is the mechanism people miss. Quality problems can therefore become part of a conduct judgment rather than remaining only a technical issue. A reviewer who suspects a template spends the rest of their time looking for confirmation, and a screen that does not work hands it to them. Before submitting, walk the app on a real device: every screen, every button, every form completed to the last field. Anything that dead-ends converts a suspicion into a decision. ## Are your store claims accurate? Guideline **5.6.2** requires your representation of yourself, your business, and your offerings to be accurate, truthful, relevant, and up to date. Read your name, subtitle, description, and in-app claims as a reviewer would, then delete anything you could not evidence. Any claim about who built the app, what qualifications sit behind it, what it is certified to do, or what results it produces has to be true and verifiable. Generated marketing copy overstates by default, which is why this catches more AI-built apps than people expect. ## Does guideline 4.2.6 ban building on a platform? No. It says apps from a commercialized template or app generation service are rejected unless submitted directly by the provider of the app's content. Submitting it yourself, rather than having the platform mass-submit client apps from its own account, addresses that ownership requirement. The rule exists to stop agencies mass-submitting near-identical apps from one account. Meeting the ownership condition is necessary rather than sufficient, so the customization work above still applies. Apple says as much itself: those services should offer tools that let their clients create customized, innovative apps that provide unique customer experiences, which is the same standard as everything above, stated in Apple's own words. ## When is the rejection correct? When the app genuinely is thin. If it is a link to your marketing site, a catalog with no interaction, an aggregator of other people's content, or a shell around a page you did not build, guidelines 4.2 and 4.2.2 apply and they apply correctly. Rewriting it in Swift produces the same rejection, because the guideline is about what the app does. The same goes for an app that only works if another app is installed, which is 4.2.3(i), or one functionally indistinguishable from apps already on the store, which is 4.3(b). ## What do you do if the letter already arrived? Do not resubmit the same binary with a bumped version, because Apple states that review takes longer when an app is repeatedly rejected for the same guideline violation. Make the changes, reply in Resolution Center before submitting the new build, and list what changed with screenshots attached. ```plaintext We have addressed the issues as follows. Visual identity: replaced the default component theme with our own palette, radius, typography and spacing across the app. Sign-in: redesigned with our own layout and copy. App-level integration: Face ID unlock, notification handling, native camera access and the share sheet are implemented and reachable in this build. Paths are listed in Notes for Review. App icon and store screenshots: replaced. Screenshots now show the app in use. Metadata: reviewed the listing and removed claims we cannot evidence. Review access: demo account added under App Review Information and verified today. The submitted build points at the same environment our users get. No functionality is gated, remote-flagged or withheld from review. ``` No argument and no emotion. Evidence of change is what moves a 5.6 letter. The [appeal path](https://developer.apple.com/contact/app-store/?topic=appeal) exists, but it is slower than fixing and resubmitting. ## The summary There is no guideline against WebViews, and Apple's own rules point web-browsing apps at WebKit. What gets flagged is an app that looks like every other submission that week, adds nothing over visiting your website, or cannot be verified by the person reviewing it. Make the interface yours, add the platform integrations your product would actually use, point the build at an environment that shows everything you are asking Apple to approve, and tell the reviewer where it all is. That is what separates an approved app from a rejected one, in any stack. ## Get it on the stores Once the app itself is review-ready, the remaining problem is getting the build signed and onto the stores. Take the web app you already built and ship it to iOS and Android as a real native binary, under your own developer account, with 50+ native device features available from your existing codebase and content updates over the air. Code signing and submission run from the browser, with no Mac and no Xcode required. [See the setup docs at setup.despia.com](https://setup.despia.com) ## FAQ ### Does Apple reject apps for using a WebView? No, Apple does not reject apps for using WebView. Guideline 2.5.6 requires apps that browse the web to use WebKit. WKWebView is the recommended way to render web content on iOS. ### Why does an AI-built interface look suspicious? AI-built interfaces often look suspicious because they share the same default theme, palette, and layout, making them indistinguishable from other apps. Customizing these elements helps differentiate your app. ### What does your app need to add beyond your website? Your app should offer features and UI that elevate it beyond a repackaged website. Examples include native notifications, Face ID, offline capabilities, and app-specific integrations. ### Why could the reviewer not verify your app? Reviewers might not verify your app if it points to an incomplete environment or lacks demo credentials. Ensure features are accessible and described in the review notes. ### Does guideline 4.2.6 ban building on a platform? No, it doesn't ban platform use. It requires apps from templates to be submitted by the content provider, not the platform, and encourages unique customer experiences. ### What do you do if the rejection letter already arrived? Do not resubmit the same binary. Make the necessary changes, reply in the Resolution Center detailing the updates, and attach screenshots as evidence of change.