Guideline 5.6 Rejection: Why AI-Built Apps Get Flagged

Key takeaways

Building with AI is allowed. Apple says it has no vibe-coding-specific rules – it enforces existing guidelines against apps that change after review.
A 5.6 rejection is about behavior: features that look hidden, claims the app doesn't keep, manipulative purchase flows or data grabs.
AI builders make these mistakes easy: one-click publishing, default templates, generated marketing copy and sign-in flows reviewers can't complete.
Treat every submission as a release: freeze features, give reviewers full access, describe everything, add native value with WebViewGold and publish in your own account.

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.

Is building an app with AI against Apple's rules?

No. Nothing in the App Store Review Guidelines (last updated June 8, 2026) forbids apps that were designed, coded or generated with AI. When Apple blocked updates of vibe-coding tools such as Replit and Vibecode in March 2026, it said it has no rules specific to vibe coding and was enforcing existing ones (9to5Mac). Those cases were about tool apps that generate and run new apps inside the iOS app, which conflicts with Guideline 2.5.2.

Your Lovable, Bolt or Base44 web app wrapped in your own native shell is a different case. It is still affected by the same principle, though: an app must not change its behavior after review. The volume of new apps makes this matter more than ever. The Next Web, citing The Information, reported in April 2026 that App Store submissions rose 84% in a single quarter as vibe coding went mainstream (The Next Web). More submissions mean more automated screening – and AI-built apps share traits that automated screening notices.

What a Guideline 5.6 rejection is really about

Guideline 5.6 is the Developer Code of Conduct. It covers respectful communication, customer trust and four sub-points: App Store reviews (5.6.1), developer identity (5.6.2), discovery fraud (5.6.3) and app quality (5.6.4). The customer-trust paragraph reads like a list of things AI templates love to generate:

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 rejections developers report in 2026 usually say that Apple identified "a pattern of unusual behavior" commonly associated with fraudulent activity and that the app "contains features that appear to have been intentionally hidden during the review process". The letter rarely names the feature. That is frustrating, but it tells you how the decision was made: by pattern, not by a single screen.

Apple publishes the scale. In 2025 it evaluated more than 9.1 million submissions and rejected over 2 million of them – over 22,000 for hidden or undocumented features and over 371,000 for copying other apps, spam or misleading users. It removed nearly 59,000 apps for bait-and-switch behavior and terminated 193,000 developer accounts over fraud concerns. Apple says machine learning helps it "analyze app similarity, and flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026).

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 →

Six patterns that make AI-built apps look suspicious

Pattern	How it happens with AI builders	Fix
The app changes after review	One click publishes a new version of the web app – including features App Review never saw	Ship new features with a new build and describe them in the Notes for Review
Features reviewers can't reach	Magic-link or one-time-code sign-in, Google login that fails inside a WebView, empty demo accounts, role-gated areas	A password-based demo account with data and full access
Generated sameness	Default component themes, AI-generated icons and the same landing-page structure as thousands of other apps	Your own design tokens, icon, copy and screens built around your use case
Promises the app doesn't keep	Generated copy with invented testimonials, user counts, ratings or "AI-powered" features that don't exist	Remove every claim you can't prove – in the app, on the website and in the listing
Manipulative purchase flows	Template paywalls with fake countdowns, pre-selected upsells or unclear trial terms	Plain pricing, In-App Purchase where required and clear subscription terms
Data grabs	Sign-up walls before any value, forms that ask for phone, address or birthday "just in case"	Collect only what a feature needs and let people look around first

Two more checks belong on the list. Ratings: a "Rate us 5 stars" pop-up generated into your web app breaks 5.6.1, which disallows custom review prompts. Identity: 5.6.2 requires your representation of yourself and your business to be accurate, so publish under the company that actually runs the service. Our article on fixing a 5.6 rejection in a WebView app walks through the diagnosis screen by screen.

Builder by builder: where the traps hide

Every builder has its own way of producing these patterns. Our builder-specific articles go into detail:

Lovable, Bolt and Base44 publish changes in seconds and generate polished but very similar interfaces – see Lovable, Bolt and Base44.
Bubble, Softr, Glide and WeWeb rely on conditions, user roles and visibility rules – exactly what makes features invisible to a reviewer with the wrong account. See Bubble, Softr, Glide and WeWeb.
Replit and v0 make it easy to point the app at the wrong deployment or to switch features with environment variables and flags – see Replit and v0.
Webflow and Framer sites are marketing sites first; wrapped as apps they invite questions about what the app actually does – see Webflow and Framer.
Figma Make and Google AI Studio produce convincing prototypes quickly; the gap between demo and product is where review problems start – see Figma Make and Google AI Studio.

Apps with AI features have one extra duty: Guideline 5.1.2(i) requires you to "clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so". If your app sends user content to a model provider, say so in the app and in your privacy policy before the first request.

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

A pre-submission routine for AI-built apps

Freeze the scope. Decide which features this version contains and stop publishing new functionality to production until the build is approved. Content and bug fixes can continue.
Audit flags and conditions. List every feature flag, environment variable, role check and visibility rule. Anything that hides a feature from the review account is a red flag.
Prepare reviewer access. Create a demo account that signs in with email and password, add realistic sample data, unlock paid areas and test the login inside the app – not just in the browser.
De-template the app. Replace the default theme, icon, placeholder text, generated testimonials and stock claims. If two of your apps share a template, read our Guideline 4.3 article first.
Check money and data. Digital goods need In-App Purchase where Apple requires it, subscriptions need clear terms, and forms should only ask for what a feature needs.
Add native value. Push notifications for real events, a native offline screen, Face ID sign-in and native sharing show the reviewer an app, not a website in a frame.
Write specific review notes. Every feature, where it is and how to test it. Generic descriptions are rejected under Guideline 2.3.1 – our 2.3.1 article for AI-built apps shows how to build that feature list from the code.
Publish in your own developer account. Guideline 4.2.6 rejects apps from app-generation services unless the content provider submits them – see Guideline 4.2.6 for WebView apps.

How to wrap an AI-built web app so reviewers see a real app

Most AI builders produce web apps, so the path to the App Store usually runs through a native wrapper. How you wrap matters. A thin shell that loads your production URL and nothing else invites Guideline 4.2 and, if the web app keeps changing, 5.6. A wrapper with native features that serve your core journey gives the reviewer something to approve.

WebViewGold, the website-to-app solution built by our team, is made for exactly this. It turns any web app that runs in Safari or Chrome – including projects from Lovable, Base44, Replit, Bubble and Figma Make – into native Xcode and Android Studio projects. You switch on push notifications (OneSignal, Firebase or Pushwoosh), a native offline screen, universal links, Face ID, a QR scanner, StoreKit in-app purchases and Apple's native rating dialog in the configuration. It is a one-time purchase and you publish in your own accounts.

Two rules make WebViewGold apps reviewable: use the native features in your main user journey, and use app detection (WebViewGold can set a custom user agent) only to adapt layout – never to hide features from review. Our guide to converting a Lovable app to iOS shows the full setup for one builder.

The submission itself is where appsubmitter.io comes in: we set up code signing and CI/CD in your own Apple Developer account, prepare the listing and App Privacy details, run AI-powered pre-submission checks with a human App Specialist on top, write the review notes and handle the communication with App Review. Book the iOS package or start with a free consultation call.

Already rejected? The recovery path

Don't resubmit unchanged. A 5.6 flag rarely disappears on its own, and repeated submissions of the same build don't help your case.
Find and fix the pattern with the table above, then upload a new build.
Reply in App Store Connect with what you checked, what you changed and a complete feature list with test steps. Stay polite – 5.6 itself asks for respect in your communication with Apple.
Appeal only if App Review misunderstood the app; Apple allows one appeal per rejected submission.
Ask for a 30-minute App Review appointment through Meet with Apple if you can't identify the trigger.
Never open a second developer account to get around the rejection. That turns a fixable rejection into an identity problem under 5.6.2.

If the stakes are high – a client launch, an existing app with users – let an App Specialist look at it before you answer. appsubmitter.io handles rejections for apps built with every major builder, and we tell you honestly whether a fix is quick or whether the app needs more native work first.

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 your feedback on [App name] (version [x.y], build [build number]) regarding Guideline 5.6.

We built the web part of this app with [builder] and have reviewed the app for anything that could appear hidden or inconsistent. In this build:

1. All features are available to every user and are listed below; no feature is switched on or off after review.
2. [We removed a feature flag / visibility rule that hid [feature] from some accounts.]
3. [We replaced a custom rating pop-up with Apple's native review request.]
4. [We removed unverified claims from the app and the App Store description.]

Demo account (full access, sample data): [username] / [password]

Features and how to test them:
- [Feature 1] – [location] – [steps]
- [Feature 2] – [location] – [steps]

A screen recording is attached. If a specific screen or flow raised the concern, we would appreciate a pointer so we can address it directly.

Best regards,
[Your name], [Company]

Checklist before you resubmit

No new functionality was published to the web app while the build is in review.
Every feature flag, environment variable, role and visibility rule has been checked against the review account.
The demo account signs in with a password inside the app and reaches every paid and role-based area.
Default theme, icon, placeholder copy and generated testimonials have been replaced with your own.
Description, screenshots and in-app claims only promise what the app actually does.
Purchases of digital content use In-App Purchase where required, with clear prices and terms.
Sign-up forms ask only for data a feature needs; people can see what the app does before registering.
Data sent to third-party AI providers is disclosed and users give explicit permission first.
The app is published in your own developer account under your business name.
The Notes for Review list every feature with its location and test steps.

Frequently asked questions

Does Apple reject apps because they were built with AI?

No. Apple said in March 2026 that it has no vibe-coding-specific rules and enforces its existing guidelines. AI-built apps are rejected for the same reasons as any other app – changes after review, hidden features, spam-like similarity or misleading claims – they just run into those problems more often.

Why does my 5.6 rejection mention hidden features when I hid nothing?

Because a feature the reviewer couldn't reach looks the same as a hidden one. Login flows that fail in the app, role-based visibility rules, feature flags and web changes published during review are the usual causes. Fix access, document every feature and reply with test steps.

Can I keep using my AI builder after the app is approved?

Yes. Keep shipping content and bug fixes through your builder as usual. Ship new functionality together with a new app build whose review notes describe it, so the app App Review approved stays the app your users get.

Is WebViewGold enough to get an AI-built app approved?

No tool can promise an approval – Apple judges your app and your conduct. WebViewGold gives your web app the native side reviewers expect (push, offline screen, Face ID, in-app purchases, native rating dialog), and it is made by our team. Flags, claims and access problems in the web app are still yours to fix.

Will a 5.6 rejection close my developer account?

Not automatically. Guideline 5.6 says accounts are terminated for conduct that breaks the code, and Apple terminated 193,000 accounts over fraud concerns in 2025. A first rejection that you resolve transparently is usually fixable – repeated or deceptive behavior is what puts the account at risk.

Do I have to tell Apple my app was built with AI?

There is no such requirement in the guidelines. What you must disclose is what the app does: every feature in the review notes and, under Guideline 5.1.2(i), any sharing of personal data with third-party AI services, with explicit user permission.

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.

Guideline 5.6 Rejection: Why AI-Built Apps Get Flagged – and How to Get Approved