Skip to content
Back To School Sale from $619, until 31st October 2026 Book now
appsubmitter.io
AI-built apps: Guidelines 5.6 & 2.3.1 iOS · App Store

Framer App Rejected Under Guideline 5.6: Why Wrapped Framer Sites Get Flagged and How to Resubmit

A Framer app rejected under Guideline 5.6 is rarely about fraud and almost always about mismatch: the site App Review saw isn't the site your users get now, a plugin login kept the reviewer out, or the app repeats promises the landing page made. Framer is built for marketing sites, so App Review also asks what the app actually does. Lock what the app shows during review, give the reviewer full access, cut unprovable claims and add app value before you reply.

By the appsubmitter.io App Specialist Team, updated , 12 min read

Recommended solution: WebViewGold – native iOS and Android apps from your web app, made by our team.

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

  1. Fix the time window. Note the submission date and the rejection date from App Store Connect.
  2. 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.
  3. 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?
  4. 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.
  5. 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

GoalWhat to change in FramerWhat to change in the app or listing
StableConnect your custom domain; while a build is in review, work in staging (Pro plans) or hold publishes until the decisionPoint the build at the custom domain, never at framer.app; ship new features with a new build
ReachableCreate an Outseta demo account with email and password and the plan that unlocks every protected pageImplement 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))
HonestRemove unprovable testimonials, counters, ratings, countdowns and "coming soon" features from app-visible pagesAlign description and screenshots with the app; sell digital access through In-App Purchase
UsefulDecide which content justifies an app: an editorial CMS, a catalog, a members' library, a venue programAdd 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-association through 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.

Hello App Review Team,

Thank you for your feedback on [App name] (version [x.y], build [build number]) under Guideline 5.6. The app displays our website, which we build with Framer. We have reviewed everything a user can reach in the app and want to explain what changed.

1. Website changes during review: on [date] we published [describe change]. [We reverted it / It is part of this submission and described below.] New functionality is now published only together with a reviewed build.
2. Domain: the app now loads [https://www.example.com] directly. Previously it loaded [project].framer.app.
3. Access: protected pages use [Outseta]. Demo account with full access: [email] / [password]. No Google login or one-time code is needed.
4. Claims: we removed [testimonials / user numbers / "coming soon" features] that the app does not offer.

What the app does and how to test it:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]
- Push notifications for [new articles / events] – [how to trigger a test]

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

Best regards,
[Your name], [Company]

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?
Most likely because App Review found something it couldn't verify or that looked hidden: a site that changed while the build was in review, a switch from framer.app to a custom domain, pages behind a membership plugin the reviewer couldn't open, or landing-page claims the app doesn't keep. Find the mismatch, fix it, document it and reply with a complete feature list.
Can I keep editing my Framer site after the app is approved?
Yes – new articles, CMS items, events and design refinements are what a website-based app is for. Treat new functionality differently: new paid areas, collections that change the app's purpose or new data collection should arrive with a new build and review notes. On Pro plans with staging, prepare such changes in staging and deploy them once the build is approved.
Should my app load the framer.app address or my custom domain?
Your custom domain. It requires a paid Framer plan, but it is the address you can keep for the life of the app, it removes the "Made in Framer" badge once you republish, and it lets you host the files for universal links. Submitting with framer.app and switching later changes the app after review – exactly what you want to avoid.
My Framer site uses Outseta for members. What does App Review need?
A demo account that signs in with email and password inside the app and holds the plan that unlocks every protected page. Enter it in App Review Information, not only in the notes. If members also use Google login, either implement it natively in the app alongside Sign in with Apple, or keep Google on the website and let members use email and password in the app. Sign-up in the app also requires in-app account deletion.
Will WebViewGold get my Framer app through review?
No tool can promise an approval, and a 5.6 rejection is about conduct, not technology. WebViewGold, built by our team, gives your Framer site native features reviewers can test – push, offline handling, universal links and Apple's rating dialog. Stable publishing, open access and honest claims are still up to you.
Is a Framer landing page worth turning into an app at all?
Usually not. A landing page exists to send people somewhere else – a sign-up, a product, a waitlist – and Guideline 4.2.2 says apps shouldn't primarily be marketing materials. Keep it a website. If you have content people return to, or members, events or a catalog, an app can make sense, and appsubmitter.io can assess that with you in a free call.

Recommended solution

From WebView rejection to approval: WebViewGold + appsubmitter.io

  1. 1 Build with WebViewGold Turn your website into native iOS and Android projects.
  2. 2 Add native value Push, offline screen, deep links or scanning in your main flow.
  3. 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

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.

Talk to a real App Specialist

Turn your rejection into an approval

Book a free consultation call or let our App Specialists take over CI/CD, guidance on the fixes and the resubmission. Your app does not have to be 100% ready.

Back To School Sale prices until 31st October 2026. Prices in USD, excl. VAT.