v0 App Rejected Under Guideline 5.6: Preview URLs and Flags

Key takeaways

A 5.6 rejection of a v0 app is about consistency, not about AI: the app App Review tested has to be the app your users get.
Vercel gives every v0 working branch its own preview URL. The iOS app must load your production domain – never a preview, a generated deployment URL or a protected deployment.
Environment variables, Global Config flags, proxy rewrites and Instant Rollback can change features without a new build. Freeze them while a build is in review.
Fix Stripe paywalls for digital features, generated claims and the default shadcn/ui look, add native value with WebViewGold, built by our team, and reply with exact 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.

v0 app rejected under Guideline 5.6: the short diagnosis

A v0 app rejected under Guideline 5.6 has usually shown App Review one version of itself and its users another – or kept features out of the reviewer's reach. Apple reads that as a breach of the Developer Code of Conduct. The fix is rarely in the code v0 wrote. It is in how the project is deployed, switched and tested.

v0 is Vercel's AI agent for building apps, renamed from v0.dev to v0.app on August 11, 2025. By default it generates Next.js with the App Router, React Server Components, server actions and API routes, styled with Tailwind CSS and shadcn/ui, and deploys to Vercel. None of that bothers Apple. The March 2026 dispute over vibe coding concerned tool apps that run generated code inside their own iOS app, and Vercel's own v0 iOS app was reportedly not even restricted (Michael Tsai, citing The Information).

Developers who received 5.6 letters in 2026 quote the same phrases: "a pattern of unusual behavior" commonly associated with fraud, and features "intentionally hidden during the review process". Apple rarely names the feature. Its rule for new functionality is Guideline 2.3.1(a):

All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.

For the cross-builder background, read our 5.6 overview for AI-built apps, and for a general WebView diagnosis, the WebView 5.6 article. What follows is specific to v0 and Vercel.

Which Vercel deployment did App Review actually see?

According to v0's deployment docs, working branches get preview deployments with unique URLs, while publishing updates the production deployment behind your project's stable production URL. For GitHub-backed projects, Publish merges a pull request into the base branch and waits for the production build. One project therefore has several addresses – and only one belongs in an iOS app:

Address	What it serves	When it changes	Fine as the app's start URL?
Your production custom domain	The current production deployment	On every Publish Changes, merge or rollback	Yes – the stable choice
The project's `vercel.app` production domain	The same production deployment	Same as above	Works, but brands the app with the host
A generated deployment URL	One frozen build	Never – it keeps the old build	No – stale and, under Standard Protection, restricted
A preview or branch URL	Unfinished work from a v0 chat branch	With every change v0 commits	No – unreviewed features, often behind a login

Deployment Protection makes a wrong choice very visible. Vercel's recommended Standard Protection covers every deployment except production domains, and the stricter All Deployments setting protects production too (Vercel docs). A wrapper pointing at the wrong address shows the reviewer a Vercel login instead of your app – which looks exactly like features locked away from review.

Rollbacks are the second trap. Vercel's Instant Rollback restores a previous production build within moments. Use it while a build is in review, and the reviewer's next session may run older code than the version your notes describe.

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 →

Five switches in Next.js and Vercel that change features without a build

Environment variables per environment. Vercel keeps separate values for Production, Preview and Development. A feature enabled by a Preview-only variable is invisible in production, and a variable changed after review changes the app with the next deployment. Variables prefixed with NEXT_PUBLIC_ end up in the browser bundle – which also means any secret placed there is readable inside your iOS app.
Global Config flags. Vercel's Global Config, previously called Edge Config, is a data store for feature flags, A/B tests and redirects that take effect without a redeploy. Ideal for staged rollouts, risky when a flag switches on something App Review never saw.
Flag providers. Flag services from the Vercel Marketplace work the same way, and v0 even offers PostHog as an MCP preset "for product analytics and feature flags". One toggle, new behavior.
Proxy rules. The Next.js file convention formerly called middleware, now proxy, can rewrite or redirect every request based on user agent, country or cookies. A rule that routes requests by region or device can hand reviewers a different app than your users get.
Server-side gates. Server actions and route handlers that check roles, plans or invite codes decide which features exist for which account.

The line is simple. Switches may stage the rollout of a feature Apple has reviewed, adapt the layout for the app or protect admin areas you describe in your notes. They must never turn on functionality the reviewer couldn't see, or turn something off only while the app is under review.

Stripe paywalls, generated claims and the shadcn/ui look

Stripe. v0's Stripe integration lets your app "accept payments and manage subscriptions", and on the first publish, Commerce mode asks whether to claim the Stripe test sandbox v0 created. Make sure the checkout your users and App Review see is the one you actually operate. Inside an iOS app, digital features and subscriptions fall under Guideline 3.1.1 and need In-App Purchase – and hiding the Stripe paywall only while Apple reviews the app is the textbook hidden feature. Our 3.1.1 article for WebView apps covers the compliant options.

Generated claims. v0 is quick to produce landing sections with testimonials, customer logos and usage numbers. If they aren't real, they break the customer-trust promise of 5.6 and the marketing rules of 2.3.1 – in the app, on the website and in your App Store description.

The default look. shadcn/ui is a great starting point, which is exactly why so many v0 and Next.js apps share its defaults. Apple says its systems "analyze app similarity", and in 2025 it rejected over 371,000 submissions for copying other apps, spam or misleading users (Apple Newsroom). Give your app its own theme tokens, icon, typography and screens – and read our 4.3 article for WebView apps if several of your apps share a template.

Branding. Free-plan v0 deployments can carry a "Built with v0" badge; a Vercel staff member wrote in 2025 that paid tiers can remove it. Remove it before you submit.

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

Reconstruct the review window from Vercel and GitHub records

Pin the dates from App Store Connect: submission, start of review, rejection.
List production deployments in that window in the Vercel dashboard – every Publish Changes, merged pull request, redeploy and rollback.
Read the merged pull requests from v0's working branches if the project is connected to GitHub. Each one is a precise diff.
Check environment variables under Project menu → Settings → Environment Variables in v0 and in the Vercel project: what changed, and for which environment?
Review the flag history in Global Config and in any flag provider you use.
Search the code for userAgent, geo, cookies(), rewrite and role checks in the proxy file, server actions and route handlers.
Scan the runtime logs for errors during the review window – a failing server action looks like a missing feature to a reviewer.
Confirm the start URL in the iOS project. If it isn't your production domain, you may have found the cause already.

The result is a list of differences between what the reviewer saw and what users get. Fix each one and keep the list – it becomes your reply.

Fix, freeze and wrap: getting the v0 app approved

Point the app at production: your custom domain, with Deployment Protection limited to previews so production stays public.
Freeze feature releases during review. Content updates and bug fixes are fine; new functionality, flag flips and rollbacks wait for the approval.
Remove reviewer-dependent logic. Proxy rules, flags and server checks must not depend on anything that could identify a reviewer.
Prepare a review account with a password, every relevant role and realistic seed data in your Supabase or Neon database.
Settle digital purchases: In-App Purchase for digital features, applied to every iOS user.
Delete invented claims, customize the look and remove the badge.
Add native value. WebViewGold, the website-to-app solution built by our team, wraps your production URL in an Xcode project. It adds Apple's native rating dialog in place of web "rate us" prompts, which Guideline 5.6.1 disallows, plus push notifications, a native offline screen with Reconnect, Face ID, universal links and StoreKit purchases (Extended license). Its custom user agent – useragent_iphone and useragent_ipad in Config.swift – lets your Next.js app switch to an app layout. Use it for layout only.
Ship a new build, test it through TestFlight and describe every feature in the Notes for Review.

No tool can promise an approval. If you want a second opinion before resubmitting, appsubmitter.io combines an AI-powered pre-submission check with an App Specialist who reviews the app, writes the review notes and handles the conversation with App Review in your own developer account. Code changes are quoted separately. Book the iOS submission or start with a free consultation call.

Replying to Apple about a v0 app – and when to escalate

Upload the new build, then reply under the rejected submission in App Store Connect – up to 4,000 characters, attachments allowed. Spell out three things Apple can verify: the exact URL the app loads, how releases work (production deployments with new features follow an approved build) and every flag or environment variable you removed or locked. Add the demo account, a feature list and a screen recording, and politely ask which screen raised the concern if the letter didn't say. With appsubmitter.io, an App Specialist drafts this reply with you and handles the follow-up with App Review.

If messages go in circles, request a 30-minute App Review appointment through Meet with Apple. Appeal to the App Review Board only if Apple misunderstood the app; there is one appeal per rejected submission. Don't resubmit the same build, and don't open a new developer account: Apple terminated 193,000 accounts over fraud concerns in 2025, and a workaround account makes a 5.6 case worse. For the full iOS setup, see converting a v0 app to iOS; for Google Play, the v0 Android guide.

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.

Our app shows our web app, built with v0 (Next.js) and hosted on Vercel, from [https://app.yourdomain.com]. We checked every way the app could differ between review and release and changed the following in this build:

1. Start URL: the app loads only our production domain. [It previously loaded a preview deployment.]
2. Release process: production deployments that add features now happen only after the build describing them has been approved. Content updates and bug fixes continue as usual.
3. Feature switches: we removed [flag / environment variable / proxy rule] that controlled [feature]. All users now get the same functionality.
4. [Digital purchases in the iOS app now use In-App Purchase.]

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

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

A screen recording is attached. If a particular 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

The iOS app loads the production custom domain – no preview, branch or generated deployment URL.
Deployment Protection leaves the production domain publicly reachable.
No Publish Changes with new features, flag flips or rollbacks happened while the build was in review.
Production environment variables match what the reviewer saw, and no secret uses the NEXT_PUBLIC_ prefix.
Proxy rules, flags and server checks never depend on anything that could identify a reviewer.
The review account signs in with a password and has realistic data and every role.
Digital features use In-App Purchase, and the Stripe checkout is never hidden from reviewers only.
Invented testimonials, logos and numbers are gone, and the design no longer looks like an untouched template.
The wrapper adds native value – for example WebViewGold's rating dialog, push and offline screen – and app detection only changes the layout.
The Notes for Review list every feature, the start URL and the release process.

Frequently asked questions

Why was my v0 app rejected under Guideline 5.6 if I hid nothing?

Because something looked hidden from App Review's side. The most common v0 causes are an app pointed at a preview deployment, a Vercel login on a protected deployment, a feature flag or environment variable that changed after review, a production deployment during review and a Stripe paywall for digital features. Trace the review window, fix the difference and reply with specifics.

Can I keep deploying to Vercel while my app is in review?

Yes, for content and bug fixes. Hold back production deployments that add or remove features, flip flags or roll back to an older build until Apple has approved the build that describes the change. Preview deployments are fine at any time, as long as the app never loads them.

Are feature flags allowed in an App Store app built with v0?

Yes, if you use them honestly. Flags can stage the rollout of a feature Apple has already reviewed, run experiments within reviewed functionality or protect admin areas you describe in your notes. They may not switch on features App Review never saw, or switch features off only while the app is being reviewed.

Can my iOS app load a Vercel preview URL?

It shouldn't. Preview deployments contain unreviewed work from v0's working branches, generated deployment URLs freeze an old build, and both are often protected by Vercel Authentication, so the reviewer may only see a login. Use your production custom domain, which always serves the current production deployment.

Will a shadcn/ui design get my v0 app flagged as spam?

Using shadcn/ui is fine – plenty of excellent apps do. The risk comes from leaving every default untouched, because Apple compares apps for similarity and rejects mass-produced copies under Guideline 4.3. Your own colors, typography, icon, copy and screens built around your use case make the app recognizably yours.

Does WebViewGold prevent a 5.6 rejection for a v0 app?

No tool can promise an approval, and Apple judges your conduct, not the wrapper. WebViewGold, made by our team, gives your v0 app the native layer reviewers expect – Apple's rating dialog, push, an offline screen, Face ID and StoreKit. Deployment discipline and honest flags are still up to you.

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.

v0 App Rejected Under Guideline 5.6: How Deployments, Flags and Paywalls Trigger It – and the Fix