WeWeb App Rejected Under Guideline 5.6: Causes and Fixes

Key takeaways

Apple has nothing against WeWeb. A 5.6 flag means the reviewer met features it could not reach, verify or rely on – usually because of conditions, roles or publishing timing.
Conditional Rendering, user-group page access and variables set by workflows decide what each account sees. Give the review account every role and remove reviewer-specific logic.
A production publish reaches your wrapped app at once. Test on staging and keep new features off production until the build that describes them is approved.
Wrap a custom subdomain instead of a weweb-preview.io or staging address, and use WebViewGold's native modules so the reviewer meets one consistent, app-like product.

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.

WeWeb app rejected under Guideline 5.6: what Apple is telling you

A WeWeb app rejected under Guideline 5.6 failed Apple's Developer Code of Conduct check: App Review believes the app it tested differs from what your users get, usually because features seemed hidden. In WeWeb projects the cause is nearly always a condition, a user role, the sign-in flow or publishing timing – all of which you can fix before you resubmit.

Developers who received this rejection in 2026 report wording about "a pattern of unusual behavior" that is "commonly associated with fraudulent activity", and about features "that appear to have been intentionally hidden during the review process". The letter rarely names the screen. Behind it sits a sentence from Guideline 2.3.1(a) that every WeWeb builder should know:

Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review.

Apple enforces this at scale. In 2025 it rejected more than 22,000 submissions for hidden or undocumented features, and it says machine learning helps it "flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026). Our overview of 5.6 rejections for AI-built apps explains the general pattern, and the WebView 5.6 article covers appeals and wrapper-specific triggers. This article stays inside your WeWeb project.

Why WeWeb apps look like they hide features

WeWeb describes itself as a full-stack AI application builder for internal tools, portals and dashboards. Those apps revolve around permissions: who sees which page, which button and which record. That is precisely what makes them look suspicious to a reviewer who signs in with the wrong account. Four mechanisms are behind most cases.

Conditional Rendering that depends on the user

An element with Conditional Rendering isn't hidden with CSS – WeWeb doesn't build it into the page at all until its condition is true. Bind that condition to a role, a subscription field, a date or a variable that a workflow sets on page load, and a reviewer without the matching state gets a page without the button, tab or chart your screenshots show. A feature that exists for some users but never for the reviewer is, from Apple's side, a hidden feature.

Pages restricted to user groups

Private pages can be limited to authenticated users or to user groups, with AND logic inside a group and OR logic between groups. A demo account that lacks one role in a group is quietly redirected. WeWeb's own documentation calls page gating "more of a UX feature than a security measure", so check the data side as well: an account with every group but no records still shows the reviewer empty screens.

Publishing straight to production

Every publish builds a new version of your Vue.js app and puts it online. Your wrapper loads that address, so a production publish during review changes the app the reviewer is testing without a new binary. If they opened the app before and after your publish, they saw two different products. WeWeb's staging environment, available on some plans, exists to test a published version before it reaches production.

A sign-in the reviewer can't finish

WeWeb Auth supports email and password, one-time codes, magic links and social providers. Inside an iOS app, two of them fail easily. Social sign-in opens a provider window, and Google has refused OAuth requests from embedded WebViews since September 30, 2021 with the error disallowed_useragent. A magic link to /magic-link?token=… opens in Safari rather than in your app unless universal links are configured. A reviewer stuck at the door experiences everything behind it as hidden.

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 →

Audit your WeWeb project: where each trigger lives

Open the editor next to a fresh install of the rejected build on an iPhone, sign in with the account from your review notes and compare. The table follows the order in which the triggers usually surface:

Where in WeWeb	Question to answer	What the reviewer experienced	Fix
Element settings – Conditional Rendering	Does any formula check a role, plan, date, URL parameter or the user agent?	Buttons, tabs or sections missing	Tie conditions to real user state and give the review account that state
Page access – authenticated users and user groups	Which groups unlock which pages?	Silent redirects to a public page	Add the review account to every group your listing mentions
Workflows on app or page load	Does a workflow fetch a flag that switches features on or off?	Features that come and go between sessions	Remove remote switches for anything App Review hasn't seen
Publishing – staging and production	Did anything reach production after you submitted?	Two versions of the same app	Freeze production publishes while a build is in review
Wrapper start URL	Does it load an old `weweb-preview.io` address, a staging subdomain or the editor?	Redirects, lost parameters or an unreleased version	Load your production custom subdomain directly
Authentication settings in the Data and API area	Can the review account sign in with a password inside the app?	Stuck on the login screen	A password-based demo account; codes instead of magic links in the app
Stripe checkout	Does a web payment unlock digital features in the app?	Paid areas it couldn't open, or a payment flow Apple doesn't allow	In-App Purchase for digital content, shown the same way to every iOS user

The URL row deserves a second look. On April 8, 2026, WeWeb moved free production addresses from <id>.weweb-preview.io to <id>-production.weweb.io and staging to <id>-staging.weweb.io. Redirects exist, but WeWeb's changelog warns that "issues may still occur if you rely on query parameters, hardcoded URLs, or external integrations". A wrapper configured before that date may be loading a redirect chain today.

Give App Review an account that sees the whole app

Guideline 2.1 asks you to "include demo account info (and turn on your back-end service!) if your app includes a login". For a role-based WeWeb app, that sentence has three parts:

Sign-in method. Create the account with email and password in WeWeb Auth, Supabase Auth, Xano or whichever provider your project uses. No one-time codes sent to your own inbox, no magic links, no Google-only account and no admin approval step.
Roles and groups. Give the account every role your listing and screenshots refer to. If admins and members really use different apps, provide one account per role and say which is which.
Data. Fill the account with realistic records in your WeWeb tables – the Postgres-based backend WeWeb launched on April 8, 2026 – or in your Supabase or Xano database, so dashboards and lists aren't empty.

Then test it the way Apple does: delete the app, install the build from TestFlight and sign in on the first try. If your WeWeb app is invite-only, explain in the Notes for Review who the users are and how they get access. Our guide to Guideline 2.1 information requests shows what reviewers ask when that context is missing.

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

The WeWeb fix sequence before you resubmit

Reconstruct the review window. List every production publish between your submission and the rejection. If a new feature went live in that period, either restore the reviewed state – WeWeb's Editor Backups include a Rollback Editor option – and republish, or keep the feature and describe it in the next build's review notes.
Remove reviewer-dependent logic. Conditions that compare the user agent, a URL parameter or an "in review" flag must not decide which features exist. App-mode detection is fine for layout: hiding your website footer is not the same as hiding your billing page.
Move the wrapper to one stable address. Connect a custom domain to your WeWeb hosting plan. WeWeb's domain documentation says naked domains like mydomain.com aren't supported, so use app.mydomain.com or www with the two CNAME records WeWeb asks for, plus a 301 redirect from the root domain.
Make sign-in work inside the app. Keep password sign-in for the review account. Google sign-in through WeWeb Auth can't run in the WebView, so either add it natively – ASWebAuthenticationSession or Google's iOS SDK as custom code in the Xcode project – next to Sign in with Apple, which meets Guideline 4.8's call for an equivalent login, or keep Google on the website and offer email and password plus Sign in with Apple in the app. Use codes instead of magic links in the app unless universal links are set up.
Settle payments. Stripe is fine for physical goods and services used outside the app. Digital content and features unlocked in the app need In-App Purchase, consistently for every iOS user – see Guideline 3.1.1 for WebView apps.
Write page-by-page review notes. Name each page, the role that sees it and how to test it. Guideline 2.3.1 says generic descriptions will be rejected.
Ship a new build. Raise the build number, test on a device via TestFlight, attach the build to the version and only then reply.

Wrap WeWeb with WebViewGold so the app stays consistent

A wrapper can't fix conditions inside WeWeb, but it decides how stable and app-like the result feels. WebViewGold, the website-to-app product our own team builds, is a ready-made Xcode project in Swift: you enter your custom subdomain in Config.swift, switch on native modules and publish in your own developer account. For a WeWeb app under 5.6 scrutiny, these modules matter most:

Custom user agent. WeWeb formulas can recognize the app and adjust layout – drop the site footer or the legacy PWA plugin's install prompt and restyle the consent notice – while every feature stays identical.
Native rating dialog. Guideline 5.6.1 disallows custom review prompts. Replace any "rate us" modal in WeWeb with Apple's native request, triggered from your web code.
Push notifications via OneSignal, Firebase or Pushwoosh for events your workflows already know: an approval waiting, a ticket assigned, a report ready.
Face ID for quick re-entry into a portal, and a native offline screen instead of a blank view.
Universal links, if your domain can serve the apple-app-site-association file, so links from emails open the app instead of Safari.

WeWeb does offer code export and self-hosting, but plugins that rely on WeWeb's servers – WeWeb Auth, Stripe, OpenAI and others – stop working when self-hosted, so wrapping the hosted app is usually cleaner. WebViewGold is a one-time purchase; without a Mac, the separately sold Cloud Builder builds the app in your browser, and appsubmitter.io takes over signing and submission. No tool can promise an approval, but a stable start URL and real native value remove two common reasons for doubt. Our guide to converting WeWeb to an iOS app walks through the full setup.

Replying to App Review – and moves that make a 5.6 case worse

Reply under the rejected submission in App Store Connect once the new build is attached. Explain in plain words how your WeWeb app decides what users see: which roles exist, which pages each role reaches and that the review account now holds all of them. State that production publishing is frozen until the review ends. If you still can't tell what the reviewer meant, ask politely for the screen or flow, and request a 30-minute App Review appointment through Meet with Apple if the answer stays vague. Appeal to the App Review Board only if you're sure the app hid nothing.

Avoid these moves:

Resubmitting the same build. Apple warns that if an app is "repeatedly rejected for the same guideline violation", review "will take longer to complete".
Removing features for review and switching them back on later. That is the very pattern 5.6 describes, and Apple says it enforces guidelines that prevent apps from changing their behavior after review.
Opening a new developer account or letting an agency submit under its own account. Apple terminated 193,000 developer accounts over fraud concerns in 2025, and Guideline 4.2.6 expects the content provider to submit – see 4.2.6 for WebView apps.

appsubmitter.io can take this round off your hands: an App Specialist checks the WeWeb app with the review account, writes the review notes, replies to App Review and submits from your own Apple Developer account, backed by AI-powered pre-submission checks. Changes to your code or WeWeb project aren't included, but we quote them upfront if you need them. Book the iOS service or talk it through in a free consultation call. Shipping to Google Play as well? Read converting WeWeb to an Android app.

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 have checked the app against Guideline 5.6 and would like to explain how it decides what each user sees.

[App name] is a [client portal / internal tool / dashboard] built with WeWeb. Some pages and elements depend on the user's role. The demo account below now holds every role, so the complete app is visible:

Demo account: [email] / [password]
Roles included: [Admin], [Member], [Billing]

Changes in this build:
1. [Removed a condition that hid the [feature] section from accounts without the [role] role.]
2. [The app now loads our production domain app.[domain].com instead of a staging or redirect URL.]
3. [Replaced magic-link sign-in inside the app with email and password.]
4. No new features will be published to production while this build is in review.

Pages and how to test them:
- [Page] – [role] – [steps]
- [Page] – [role] – [steps]
- [Page] – [role] – [steps]

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

Kind regards,
[Your name]
[Company]

Checklist before you resubmit

Every Conditional Rendering formula has been checked for roles, dates, URL parameters and user-agent checks.
The review account belongs to every user group that unlocks a page mentioned in the listing.
The review account signs in with email and password inside the app and comes with realistic data.
No workflow fetches a remote flag that switches features on after review.
Nothing new was published to production between submission and the review decision.
The wrapper loads your production custom subdomain, not weweb-preview.io, staging or the editor.
Google sign-in never runs inside the WebView: it is native next to Sign in with Apple, or it stays on the website.
Digital content uses In-App Purchase; Stripe only sells physical goods or services used outside the app.
Custom rating pop-ups are replaced by Apple's native review request.
The Notes for Review list every page, the role that sees it and how to test it.

Frequently asked questions

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

Because a feature the reviewer can't reach looks exactly like one you hid. In WeWeb, Conditional Rendering, user-group page access and workflows that set variables decide what each account sees. Add a review account with every role and real data, check what you published during review and describe each page in the Notes for Review.

Is Conditional Rendering in WeWeb against Apple's rules?

No. Showing different content to different users is normal for portals and internal tools. It becomes a problem when conditions keep the reviewer away from features regular users get, or when they react to the review itself. Make sure the review account matches the conditions and explain role-based areas in your notes.

Can I keep publishing my WeWeb app after it is approved?

Yes. Content updates and bug fixes through WeWeb's publish button are normal for a wrapped web app. New features, purchase flows or changes to what the app is for should go out together with a new app build whose review notes describe them – and never while a build is in review.

Should my iOS app load the weweb.io subdomain?

Better not. Since April 8, 2026, free addresses follow the pattern <id>-production.weweb.io, and older weweb-preview.io links depend on redirects. Connect a custom subdomain such as app.yourdomain.com to your WeWeb hosting plan – WeWeb's docs rule out naked root domains – and point the wrapper there.

Will WebViewGold prevent a 5.6 rejection of my WeWeb app?

No tool can promise an approval, because Apple judges how your app behaves. WebViewGold, built by our team, gives the wrapped WeWeb app a stable start URL, a custom user agent for layout tweaks, a native rating dialog, push, Face ID and an offline screen. Conditions and roles inside WeWeb remain yours to fix.

Should I open a new Apple developer account after a 5.6 rejection?

No. Guideline 5.6 is about trust in you as a developer, and a fresh account to get around a rejection undermines it further – Apple terminated 193,000 developer accounts over fraud concerns in 2025. Fix the cause, reply transparently and, if you're stuck, ask for a 30-minute App Review appointment.

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.

WeWeb App Rejected Under Guideline 5.6: Find What App Review Couldn't See and Resubmit