Webflow App Rejected Under Guideline 5.6: Find the Trigger in Your Site and Resubmit

Webflow app rejected under Guideline 5.6: what the letter means

A Webflow app rejected under Guideline 5.6 has been judged on conduct, not on code. App Review decided that something about the app looked untrustworthy – usually a feature that seemed hidden during review, or a website that no longer matched the build Apple approved. The native wrapper is rarely the culprit. The trigger sits in your Webflow project, so that is where the fix starts.

Guideline 5.6 is the Developer Code of Conduct in the App Store Review Guidelines (last updated June 8, 2026). Developers who received it in 2026 report wording about "a pattern of unusual behavior" that is "commonly associated with fraudulent activity", often without a pointer to the screen concerned. For a website inside an app shell, three passages matter most:

• Customer trust: apps must never "charge for features or content that are not delivered" – and a pricing table on your site makes promises the app now repeats.
• 5.6.2 Developer Identity: "Your representation of yourself, your business, and your offerings on the App Store or alternative distribution must be accurate."
• 2.3.1(a), the review-side twin: no hidden, dormant or undocumented features, and new functionality must be "described with specificity in the Notes for Review section of App Store Connect".

Apple enforces this at scale. In 2025 it rejected more than 22,000 submissions for hidden or undocumented features, and it says its machine learning helps it "flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026). A site that can be republished at any moment invites that kind of attention. The pattern across all AI and no-code builders is covered in our pillar article on 5.6 rejections of AI-built apps – here we stay with Webflow.

Why a wrapped Webflow site attracts a Developer Code of Conduct flag

Webflow is a website platform. Its Designer, CMS, Ecommerce and hosting produce websites that run in the browser, and neither Webflow's help center nor its pricing page documents an app export or store publishing. Every Webflow app in the App Store is therefore a native shell around a live website – and three properties of that website collide with 5.6:

1. Publishing is instant. One click on Publish updates the staging domain, your custom domain or both – and whatever reaches the domain your app loads reaches every installed copy at once. No build, no review, no trace in App Store Connect.
2. The CMS decides what exists. Collection items can be drafted, scheduled, unpublished or archived, and conditional visibility shows or hides elements depending on CMS fields. A section can be empty on review day and full a week later.
3. The copy was written to sell. Hero promises, testimonials, client logos and pricing tables are normal on a marketing site. Inside an app, they turn into claims you make to App Store customers.

There is a second problem behind the first. A marketing site in a frame is exactly what Guideline 4.2.2 describes: "Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." A thin purpose doesn't produce a 5.6 letter on its own, but it leaves the reviewer little to judge besides your claims and your consistency. Our Guideline 4.2 guide explains that side, and if your app has no job beyond the website, read how to convert Webflow to an iOS app that Apple accepts before you fix anything else.

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 →

Seven Webflow patterns that read as hidden features

Apple's letter rarely names the feature. These Webflow mechanisms are the ones that most often make a reviewer's session differ from a user's – check all seven before you reply.

The membership row deserves a second look if your app was approved while it still used Webflow's own memberships. Webflow sunset its native User Accounts on January 29, 2026 and now points site owners to Outseta or Memberstack. If an approved app's member area disappeared with the sunset, or moved to a new tool with a different login, the app your users have today is no longer the one Apple reviewed. Describe the change explicitly in your next submission.

Where to look in your Webflow project before you reply

Work through the project in this order and write down every difference between what the reviewer could have seen and what users see today. That list becomes the core of your reply.

Publish history

Reconstruct every publish between your submission date and the rejection, including single-page publishes. For the next review window, Webflow's site_publish webhook reports when each publish happened, which domains it went to and who triggered it (Webflow developer docs) – an easy way to keep a log your team can't forget to fill in.

CMS Collections

Go through each collection by status: scheduled items, items unpublished or archived recently, and items whose dates drive filtered lists such as "upcoming events" or "open offers". Then check elements with conditional visibility. A button that only appears when a CMS field is filled is invisible to a reviewer who opens an item where it is empty.

Pages panel

Look for draft pages, password-protected pages and pages that no navbar, footer or collection list links to. If the app opens one of them through its own menu, App Review needs to know it exists and how to get there.

Site settings and custom code

Check your 301 redirects, the custom code in head and footer (app-detection snippets, membership scripts, consent tools, chat widgets) and whether the Webflow badge is still switched on.

Your membership tool

In the Memberstack or Outseta dashboard, confirm which pages are gated, which plans unlock them, which login methods are active and whether the demo member still exists with the right plan.

Claims, badges and banners: what your Webflow site says inside an app

Most Webflow sites start from a template or an agency design, and both carry persuasion nobody re-reads: sample testimonials, "trusted by 2,000 teams" counters, award ribbons, five-star widgets. In Safari that is marketing. Inside an app distributed through the App Store, Guideline 2.3.1(a) treats "promoting content or services that it does not actually offer" as misleading, and under 5.6 promises the app doesn't keep become a conduct question.

• Testimonials and numbers: keep only those you can prove, from real customers who agreed to be quoted.
• Pricing tables: if a plan lists features that exist only on the web, say so, or leave the table out of the app view.
• The "Made in Webflow" badge: it is on by default, shows on webflow.io and on custom domains and links to Webflow. Remove it with a paid Site plan instead of covering it with CSS.
• Cookie banners: a website consent bar inside an app looks like a browser. Ask for consent once, in the app's style, and keep honoring it – if tracking scripts still run, Guideline 5.1.2 and App Tracking Transparency may apply.
• Store badges: a "Get it on Google Play" badge in your footer is the classic Guideline 2.3.10 problem of WebView apps – hide it when the page runs in the app.

Hiding these elements in the app is fine as long as you only change presentation. Hide a pricing page, a checkout or a feature only while the build is in review, and you have built precisely the pattern 5.6 describes.

Make the Webflow app worth reviewing – and keep it stable after approval

Clearing the triggers answers the 5.6 concern, but a reviewer who then finds your marketing site in a frame moves on to Guideline 4.2. Give the app a job Safari can't do. Webflow projects that can carry an app usually fall into a few groups: publishers whose CMS changes daily, catalogs, member areas run through Memberstack or Outseta, event and venue sites, and Webflow Ecommerce stores selling physical goods. A pure landing page doesn't belong in the App Store – keep it a website.

WebViewGold, the website-to-app solution made by our team, turns the published Webflow site into a native Xcode project: you set your custom domain in Config.swift and switch on modules instead of writing them. For a Webflow app, these matter most:

• Push that follows your CMS and store: OneSignal, Firebase or Pushwoosh, fed by a small automation that listens to Webflow webhooks such as collection_item_created for new articles or ecomm_order_changed for order updates.
• Offline behavior: a native offline screen plus locally bundled HTML for key pages, instead of a blank view.
• Universal links: host the apple-app-site-association file through Webflow's .well-known support, which needs a Premium Site plan or higher and a custom domain – it isn't available on webflow.io.
• Native rating and sharing: Apple's rating dialog instead of a web "rate us" pop-up (5.6.1 disallows custom review prompts), and the native share sheet for articles or products.
• A custom user agent: lets your site hide navbar, footer, badge and cookie bar in the app – for presentation only.

WebViewGold is a one-time purchase, you own the project and you publish it in your own developer account. It can't promise an approval – no tool can – but it removes the "website in a frame" impression that makes every other question harder. Planning a Google Play release too? Our guide to converting Webflow to an Android app covers asset links and closed testing.

Reply, resubmit or appeal – and the moves that make it worse

1. Fix first, then upload a new build if anything in the app changes, such as the start URL or native features. Site-only fixes can go live before you reply.
2. Reply in App Store Connect. You have up to 4,000 characters plus attachments. Name the publishes that happened during review, what you changed in Webflow, the demo member's credentials and test steps per feature, and attach a short screen recording.
3. Ask for the screen concerned if the letter names none – politely, in the same reply.
4. Request a 30-minute App Review appointment through Meet with Apple if two rounds of messages haven't cleared things up.
5. Appeal to the App Review Board only if the reviewer misunderstood an app that hid nothing; Apple accepts one appeal per rejected submission.

What makes it worse: resubmitting the same build without explanation, publishing new features to the custom domain during the next review, removing the pricing page for the review account only, or creating a second developer account. In 2025 alone, Apple closed 193,000 developer accounts over fraud concerns, and a fresh account turns a fixable rejection into an identity question under 5.6.2. Our general guide to 5.6 rejections of WebView apps goes deeper into the reply.

If you'd rather not handle this alone, appsubmitter.io combines AI-powered pre-submission checks with an App Specialist who reviews the app, writes precise review notes and handles the conversation with App Review in your own Apple account. Changes to your site or code aren't included, but we quote them upfront if they are needed. Book the iOS service or start with a free consultation 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 have audited the Webflow website the app displays and want to be fully transparent about what you will see.

What we found and changed:
1. Publishing: on [date] we published [describe change] to our custom domain while the build was in review. [It has been reverted / It is now part of this build and described below.] Website changes that add functionality are now released only together with a reviewed build.
2. Content: [The events section was empty on review day because no collection items were scheduled. It now contains real upcoming events.]
3. Access: the member area runs on [Memberstack / Outseta]. Demo member with full access: [email] / [password]. No one-time code or third-party login is required.
4. Claims: we removed [testimonials / user counts / ratings] that the app could not substantiate.

Features and where to find them:
- [Feature 1] – [tab or screen] – [test steps]
- [Feature 2] – [tab or screen] – [test steps]
- Push notifications for [new articles / order updates] – [how to trigger a test]

The app loads [https://www.example.com] directly, without redirects. A screen recording of these flows is attached. If a specific 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

• Nothing was published to the custom domain between submission and decision – or every publish is documented with date and content.
• While a build is in review, new work goes to the webflow.io staging domain only.
• Scheduled, unpublished and archived CMS items have been checked against what the reviewer could see.
• The build loads the final custom domain directly – no webflow.io start URL and no 301 redirect.
• The demo member signs in with a password inside the app and holds the plan that unlocks every gated page.
• The "Made in Webflow" badge is removed via a paid plan; store badges and cookie bars are hidden or replaced in the app.
• Digital content sold through a web checkout follows Apple's In-App Purchase rules for every user, not just the reviewer.
• The Notes for Review list each feature with its location and test steps.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.6 Developer Code of Conduct
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
• Webflow Help – User Accounts (Memberships) sunset
• Webflow Help – The Webflow badge
• Webflow Help – Hosting .well-known files for deep linking
• Webflow Developers – Webhook events (site_publish, collection and ecommerce events)
• Google Developers Blog – OAuth changes for embedded webviews
• Apple – App Review: appeals and appointments

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.