Key takeaways
- Guideline 5.6 flags conduct: features that look hidden, promises the app doesn't keep and apps that change after review. A Framer site in a shell can trip all three without any bad intent.
- Framer-specific triggers: publishing or "Deploy Latest" during review, a framer.app URL that later becomes a custom domain, Outseta-protected pages and template copy full of unprovable claims.
- Framer positions itself for marketing sites and recommends Lovable for builds that need accounts or payment flows – so a reviewer will ask what your app does beyond the website.
- Freeze production during review, give the reviewer a password login, remove unprovable claims and add native features with WebViewGold before you reply.
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.
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.
Framer app rejected under Guideline 5.6: what Apple is really saying
A Framer app rejected under Guideline 5.6 has run into Apple's Developer Code of Conduct, and in almost every case the problem is a mismatch rather than fraud. The site the reviewer opened inside your app, the site your users see today and the promises on both don't line up – or part of the app was out of the reviewer's reach. That is fixable, but only once you have found it.
Apple frames 5.6 around one sentence: "Customer trust is a cornerstone of the App ecosystem." Guideline 2.3.1(b) puts it more bluntly – "if you’re dishonest, we don’t want to do business with you." The rejections developers describe in 2026 mention "a pattern of unusual behavior" and features that "appear to have been intentionally hidden during the review process", usually without naming a screen. Apple decides by pattern, so you have to find the pattern yourself.
The volume behind these decisions is large. In 2025 Apple rejected more than 371,000 submissions for copying other apps, spam or otherwise misleading users, and over 22,000 for hidden or undocumented features (Apple Newsroom, May 20, 2026). For the general mechanics, read our overview of 5.6 rejections in AI-built apps and the WebView-specific 5.6 guide. This article covers what is specific to Framer.
Why a Framer site is an unusual App Store candidate
Framer is an AI website builder and design platform. You design pages, manage content in the Framer CMS and publish to Framer's hosting, which takes care of pre-rendering and server-side rendering. There is no app export, and Framer states plainly that it "does not offer HTML export for self-hosting" – your app can only ever be a shell around the live, hosted site.
Framer is also candid about what it is for. Its comparison with Lovable recommends Framer for "Brand, campaign, editorial, and product-marketing sites" and says Lovable "is more appropriate when the build needs accounts, transactional data, server functions, application state, or payment flows beyond a marketing site" (Framer). App Review comes from the other side: Guideline 4.2.2 says apps shouldn't primarily be "marketing materials, advertisements, web clippings, content aggregators, or a collection of links".
That is why 5.6 hits Framer apps in a particular way. A marketing site is full of statements – "AI-powered", "join 40,000 founders", "start your free trial" – that point to a product living somewhere else. Wrapped as an app, those statements describe features the app doesn't contain. Guideline 2.3 starts from the expectation that "Customers should know what they’re getting when they download or buy your app", and 5.6 forbids charging "for features or content that are not delivered". If your Framer project is a startup landing page or a portfolio, the 5.6 letter is a symptom: the app has no job of its own.
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.
Six ways a Framer app drifts away from what the reviewer saw
1. A publish during review
Publishing in Framer takes one click, and on Pro plans with staging enabled, "Deploy Latest" moves the staging version to production just as quickly. Framer's AI tools and agents make sweeping edits fast, too. If a rewritten hero, a new pricing page or a changed navigation reached production between submission and decision, the reviewer and your users saw two different apps.
2. framer.app today, custom domain tomorrow
Every published Framer site gets a framer.app address; your own domain needs a paid plan. Many teams submit with the framer.app URL and switch to the custom domain after launch – for App Review, that is a different site. Even the look shifts: the "Made in Framer" badge disappears only after you connect a domain or upgrade, and then republish.
3. Pages behind a membership plugin
Framer has no built-in user accounts. Plugins such as Outseta add sign-up, login and protected pages or folders, with email and password or Google as login options. A reviewer without a working account meets locked pages – and Google login fails inside an embedded web view, because Google blocks its OAuth pages there (disallowed_useragent). From the outside, an area nobody can reach looks exactly like a hidden one.
4. A checkout only some people see
Framer has no native payments, so paid plans run through plugins such as Outseta or StripeKit, with Stripe behind them. Selling digital access inside an iOS app generally requires In-App Purchase under Guideline 3.1.1. Hiding the web checkout during review – or showing it only to members the reviewer can't become – is the textbook pattern behind a 5.6 letter.
5. CMS collections that change what the app is
Adding a collection in the Framer CMS – deals, job listings, templates for sale – makes new pages appear in the app overnight. New content is fine. A collection that changes the app's purpose or adds a business model is a new feature and belongs in a new build with review notes.
6. Claims inherited from the landing page
Marketplace templates and AI-generated copy often arrive with testimonials, client logos, star ratings, "used by thousands" lines, countdowns and waitlist forms for products that don't exist yet. Inside an app, each of these is a promise. Keep what you can prove and remove the rest from every page the app can reach.
Reconstruct the review session in five steps
- Fix the time window. Note the submission date and the rejection date from App Store Connect.
- List every change inside that window: production publishes, staging deployments, CMS edits, plugin settings and anything collaborators touched. Ask everyone with editor access, not just yourself.
- Open the build's exact start URL on a clean iPhone. Which domain loads, does it redirect, is the badge visible, and what does the first screen promise?
- Walk the reviewer's path with the demo credentials from your App Review Information: which pages are protected, which plan the demo account holds, and whether sign-in works inside the app rather than in Safari.
- Compare promises with reality: hero copy, pricing, testimonials, the App Store description and the screenshots against what the app really does.
The outcome is a list of differences. Every item on it gets fixed – and the list itself becomes the backbone of your reply.
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.
Make the Framer app stable, reachable and honest
| Goal | What to change in Framer | What to change in the app or listing |
|---|---|---|
| Stable | Connect your custom domain; while a build is in review, work in staging (Pro plans) or hold publishes until the decision | Point the build at the custom domain, never at framer.app; ship new features with a new build |
| Reachable | Create an Outseta demo account with email and password and the plan that unlocks every protected page | Implement Google login natively (ASWebAuthenticationSession or Google's SDK) with Sign in with Apple next to it (Guideline 4.8) – or keep Google on the website and offer email and password in the app; add in-app account deletion if users can sign up (5.1.1(v)) |
| Honest | Remove unprovable testimonials, counters, ratings, countdowns and "coming soon" features from app-visible pages | Align description and screenshots with the app; sell digital access through In-App Purchase |
| Useful | Decide which content justifies an app: an editorial CMS, a catalog, a members' library, a venue program | Add native features that serve that content (next section) |
If the honest answer in the last row is "nothing", stop here. A Framer landing page is better off as a website – or as a home-screen web app through a third-party service such as Progressier, which offers a Framer integration – than as an app that keeps getting rejected.
Give the Framer app a native layer App Review can test
WebViewGold is the website-to-app solution our own team builds. It wraps your hosted Framer site in a native Xcode project – you set the custom domain in Config.swift – and provides the native parts as modules you switch on:
- Push notifications via OneSignal, Firebase or Pushwoosh when a new CMS item goes live – an article, an event, a menu change.
- Offline handling. Without an export, your content exists only on Framer's servers. A native offline screen and locally bundled HTML for key pages keep the app useful without signal.
- Universal links. Upload
apple-app-site-associationthrough Framer's well-known files support (Static Files, Pro plans and above) so shared links open the app. - Apple's rating dialog in place of any "rate us" pop-up – 5.6.1 disallows custom review prompts.
- A custom user agent so your site can switch off heavy scroll effects, the cookie bar and waitlist forms in app mode. Framer sites lean on animation, and effects that look great in desktop Chrome can stutter in a WebView on older iPhones.
WebViewGold is a one-time purchase, and you publish in your own developer account. It doesn't make a 5.6 problem disappear – no tool can promise an approval – but it gives the reviewer something real to test. The complete setup is in our guide to converting Framer to an iOS app.
Answering App Review – and what never to do
Upload a new build if the app itself changed, for example its start URL. Then reply in App Store Connect – up to 4,000 characters, with files attached if useful – in four parts: what changed on the site during review and what you did about it, the domain the app now loads, the demo account and the claims you removed, and finally every feature with its test steps. If the letter names no screen, ask for one politely.
When messages go in circles, a 30-minute App Review appointment through Meet with Apple is often quicker. An appeal to the App Review Board is for genuine misunderstandings, and Apple accepts one per rejected submission.
Never open a second developer account, resubmit the identical build, add a "reviewer mode" through custom code or switch domains again right after approval. Each of these confirms the pattern Apple suspects.
appsubmitter.io can carry this for you: an App Specialist checks app and site with AI-powered pre-submission checks, rewrites the review notes, submits in your own Apple account and handles the follow-up with App Review. Changes to your Framer site or code are quoted separately upfront. Book the iOS service or describe your case in a free consultation call. Releasing on Android as well? Google checks different things – see converting Framer 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.
Checklist before you resubmit
- You know every publish, staging deployment and CMS edit between submission and rejection.
- The build loads your custom domain directly – not a framer.app or framer.website address.
- The "Made in Framer" badge is gone: a custom domain or paid plan is active and the site was republished.
- The demo account signs in with email and password inside the app and unlocks every protected page.
- Google login, if offered in the app, runs natively instead of in the web view, with Sign in with Apple as an equivalent option.
- Testimonials, ratings, user counts, countdowns and "coming soon" features on app-visible pages are true or removed.
- Digital access sold in the app uses In-App Purchase, and the checkout is the same for every user.
- Content edits continue as usual, but new features wait for a new build and review notes.
- The app offers native value – push, offline handling, universal links – beyond the website.
Frequently asked questions
Why was my Framer app rejected under Guideline 5.6?
Can I keep editing my Framer site after the app is approved?
Should my app load the framer.app address or my custom domain?
My Framer site uses Outseta for members. What does App Review need?
Will WebViewGold get my Framer app through review?
Is a Framer landing page worth turning into an app at all?
Recommended solution
From WebView rejection to approval: WebViewGold + appsubmitter.io
- 1 Build with WebViewGold Turn your website into native iOS and Android projects.
- 2 Add native value Push, offline screen, deep links or scanning in your main flow.
- 3 We submit it Our App Specialists submit and talk to the review team.
WebViewGold is made by our team (jocapps GmbH). It is a tool, not a guarantee – approval decisions are made by Apple and Google.
Sources and further reading
- Apple – App Store Review Guidelines, 5.6 Developer Code of Conduct
- Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
- Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
- Framer – Framer vs. Lovable comparison
- Framer Help – Publishing your Framer website (framer.app, staging)
- Framer Help – Removing the "Made in Framer" badge
- Framer Marketplace – Outseta plugin (memberships, protected content, Stripe)
- Framer Help – Well-known files
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.