Figma Make App Rejected Under Guideline 5.6: What to Fix

Q: Is the figma.site address fine for an App Store app?

It works technically, but a random three-random-words.figma.site address doesn't connect the app to your business, and on the Starter plan public web publishing requires publishing the file to the Figma Community. Use a custom domain on a paid plan, or export the code and host it yourself.

Key takeaways

Apple has no rule against Figma Make. A 5.6 rejection means the reviewer found a prototype where it expected a product: features that don't work, data that isn't real, promises not kept.
Sample data, no-op buttons and a mock login read as fabricated or hidden functionality. Replace them with a real Supabase backend, a password demo account and honest empty states.
Publish settings can hide the whole app from review: password protection, an internal-only audience or an update to the published version mid-review. Check them before you reply.
Pin what the reviewer sees – a custom domain without mid-review updates or a deploy from Git – and wrap it with WebViewGold so native features carry the app.

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.

Figma Make app rejected under Guideline 5.6: what Apple objects to

A Figma Make app rejected under Guideline 5.6 was judged under Apple's Developer Code of Conduct, usually because App Review met features that seemed hidden or didn't work as presented. Figma Make is built to turn ideas into functional prototypes fast; submitted as an app, a prototype's gaps look like deception. The way out is to turn the prototype into a working product, freeze what reviewers see and explain the changes.

The rejection letters developers reported in 2026 talk about "a pattern of unusual behavior" commonly associated with fraudulent activity and about features "that appear to have been intentionally hidden during the review process". For a Make app, one phrase from the guideline's customer-trust paragraph matters even more: apps should never "charge for features or content that are not delivered". A mocked-up premium screen that leads nowhere does exactly that, whether anyone meant it or not.

Apple has also said plainly where prototypes belong. Guideline 2.2 reads:

Demos, betas, and trial versions of your app don't belong on the App Store – use TestFlight instead.

Expect scrutiny. In 2025 Apple rejected over 371,000 submissions for copying other apps, spam or otherwise misleading users and over 22,000 for hidden or undocumented features, and it says machine learning helps it "analyze app similarity" (Apple Newsroom, May 20, 2026). Our overview of AI-built apps under 5.6 covers the general pattern and the WebView 5.6 article covers appeals; this article focuses on what is specific to Figma Make.

Seven prototype signals App Review picks up in Figma Make apps

Signal	How it typically gets there	How a reviewer reads it	Ship this instead
Sample data that looks real	Generated names, revenue charts or reviews you asked for so the prototype felt alive	Fabricated activity or social proof	Real data from your backend, or clearly labeled samples and honest empty states
Controls that do nothing	Buttons and menu items in the generated UI that were never wired up	Features promised but not delivered – or hidden	Wire them up or remove them from this version
A login screen without real accounts	The interface exists, but nothing checks credentials	Nothing behind it can be verified	Working authentication and a password demo account
Premium screens without a purchase	A pricing page or "Pro" badge mocked into the flow	Charging for content that isn't delivered	In-App Purchase that unlocks something real, or no pricing yet
A look shared by many generated apps	Default component styling and stock layouts	Similarity to other apps – Guideline 4.3 territory	Your own Figma design system, icon and copy
Listing claims the build can't back	Marketing copy written for a pitch deck	Misleading metadata under Guideline 2.3.1	Describe only what works today
Device prompts without context	Published Make apps can request camera and microphone access	Data access without a clear purpose	Specific purpose strings and a feature that obviously needs the device

None of these require bad intent, and that is the frustrating part. A reviewer can't tell an unfinished feature from a hidden one, so the burden is on the build to show that every visible promise is kept. Our guide to Guideline 2.1 App Completeness explains the closely related completeness standard.

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 →

Publish settings that hide a Figma Make app from the reviewer

Some 5.6 cases have nothing to do with the code. Figma Make's publish options make perfect sense for prototypes and quietly lock a reviewer out of an app:

Password protection. Visitors need a password before they see anything, including the page title. Inside a wrapper, the reviewer meets a password field instead of your app.
Internal-only audience. On Organization and Enterprise plans you can restrict a published app to logged-in members of your organization. App Review isn't one of them.
Updates to the published version. Edits reach the live app only when you update the published version – and then within a minute or two. One update during review, and the reviewer may have seen two different apps.
The foundation upgrade. Figma says older Make files must be upgraded to its new foundation, which becomes required in late October 2026, and that published files have to be republished afterwards. Do it before you submit, never while a build is in review.
A random figma.site address. Published apps get a URL like three-random-words.figma.site. Fine for testing, but a store app should load a domain that belongs to the business behind your developer account.
Starter-plan publishing. Starter users can only publish to the public web if they also publish the file to the Figma Community. For a commercial app, that makes your Make file publicly available – move to a paid plan before a store app depends on it.

A 15-minute diagnosis on a real iPhone

Before you change anything, reproduce what the reviewer saw. Apple rarely names the screen, so walk the whole app:

Delete the app, install the rejected build from TestFlight and open it without a saved session.
Open the start URL in a private Safari window as well. A password prompt or an internal-only notice there explains the rejection on its own.
Sign in with the account from your review notes. If it needs a code from your inbox or a Google account, the reviewer probably never got in.
Tap every control on every screen and note each one that does nothing, shows a placeholder or says "coming soon".
Read your App Store description and screenshots side by side with the app and mark every claim the build doesn't back.
Compare the date you last updated the published version with your submission date.
Trigger each camera or microphone feature and read the permission prompt as a stranger would.

The resulting list is your fix plan – and 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.

Discover WebViewGold Let us submit your WebViewGold app

Hardening the Make file: the fix plan in order

Cut scope honestly. Anything that doesn't work end to end gets built now or disappears from this version. Unfinished features hidden behind a flag are what 5.6 punishes; features you removed are not.
Connect a real backend. Figma Make's Supabase integration provides a Postgres database, secret storage and compute, and Figma describes working authentication flows such as a login screen. Use it – or your own backend – so accounts, data and permissions are real.
Create the review account. Email and password, no codes, no Google-only sign-in, filled with realistic data you created for it.
Replace generated sample content. Remove invented testimonials, user counts, ratings and charts. Where a list can be empty, show an empty state that explains the next step.
Add the unhappy paths. Prototypes assume everything works. Real apps need messages for failed requests, expired sessions, denied permissions and lost connections.
Bring your own design. Make can start from existing Figma designs, so build on your design system rather than default styling – a distinct look also lowers the similarity risk Apple screens for.
Disclose AI features. If the app sends user content to an AI model through your backend, Guideline 5.1.2(i) requires you to disclose sharing with third-party AI and obtain explicit permission first.
Keep secrets out of prompts and client code. Figma itself warns against pasting API keys into prompts; keep them in your Supabase secrets.

Pin the version App Review sees – then wrap it

A wrapper that loads your Make app always shows the latest published version. Pick one of two ways to keep reviewers and users on the same app.

Option A: publish discipline on Figma hosting

Connect a custom domain – Professional plans can connect ten, shared with Figma Sites, and Organization and Enterprise plans as many as they need – switch password protection off, publish to the open web and stop updating the published version while a build is in review. Content and fixes can follow after approval; new features ship with a new build and review notes.

Option B: deploy from Git

Push to GitHub, which works on all plans as a one-way push to the default branch, or download the code as a .zip with a Full or Dev seat, then deploy from a release branch to hosting you control. A deploy becomes a deliberate step with a commit history, and you can serve files under /.well-known/ for universal links. Since July 2026 Make stores its code in Git anyway and supports any web framework, not only React.

Then wrap the pinned address with WebViewGold, the website-to-app product built by our own team. The Xcode project loads your URL from Config.swift and adds what a prototype never had: push notifications via OneSignal, Firebase or Pushwoosh, a native offline screen, Face ID, a QR scanner, haptic feedback and Apple's native rating dialog in place of any "rate us" pop-up. For camera or microphone features, you write the purpose strings in the project. WebViewGold is a one-time purchase; the separately sold Cloud Builder works without a Mac, and appsubmitter.io can take over signing and submission. No tool can promise an approval, but a stable URL and native value answer the "is this a real app?" question before the reviewer asks it. Our guide to converting Figma Make to an iOS app has the full setup.

What to tell App Review – and what not to do

Reply in App Store Connect after the new build is attached. Don't argue that the app was "only a prototype" – Guideline 2.2 already answers that. Describe what changed instead: which placeholder features you removed, which flows now work end to end, which backend holds the data, which demo account unlocks everything and that the published web app won't change during review. If the letter didn't name a screen, ask politely for one.

Moves that make a 5.6 case worse:

Resubmitting the same build with a cheerful note. Apple says review takes longer when an app is repeatedly rejected for the same violation.
Switching features on after approval by updating the published version – exactly the behavior change after review that Apple says its guidelines are there to prevent.
A second developer account or a friend's account. Guideline 5.6.2 requires an accurate developer identity, and Apple terminated 193,000 developer accounts over fraud concerns in 2025.
Several near-identical apps from one Make file. That invites a spam rejection – see Guideline 4.3 for WebView apps.

appsubmitter.io handles this as a service: an App Specialist checks the hardened app with AI-powered pre-submission checks, prepares the listing and App Privacy details, writes the review notes and the reply and submits from your own Apple Developer account. Changes to the Make file or code are quoted separately upfront. Book the iOS package or start with a free consultation call. If Google Play comes next, read converting Figma Make 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. We reviewed the app screen by screen and found parts that looked unfinished or unreachable. Nothing is hidden in this build, and everything users see works.

Changes in this build:
1. Removed controls and screens that were not functional yet: [list].
2. Sign-in now uses a working backend. Demo account: [email] / [password] – no code required.
3. Replaced sample content with real data; empty lists now explain the next step.
4. [The premium area now uses In-App Purchase / was removed until it is ready.]
5. The app loads our domain [app.domain.com]; the published web app will not change while this build is in review.

Features and how to test them:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]
- [Camera or microphone feature] – [screen] – [why it needs access]

We also updated the description and screenshots so they match the current build. A screen recording is attached. If a specific screen raised the concern, we would appreciate a pointer so we can address it directly.

Kind regards,
[Your name]
[Company]

Checklist before you resubmit

Every control in the app does something real, or it was removed from this version.
No generated testimonials, user counts, ratings or sample records are presented as real.
Sign-in runs against a working backend, and the demo account uses email and password without codes.
Password protection is off and the app isn't restricted to your organization's internal audience.
The wrapper loads a custom domain or your own hosting, not a random figma.site address.
The published version was not updated between submission and the review decision.
Older Make files were upgraded and republished before you submitted.
Description and screenshots only show features the build contains today.
Camera and microphone prompts come with specific purpose strings.
AI features disclose data sharing with third-party AI and ask for permission first.

Frequently asked questions

Why was my Figma Make app rejected under Guideline 5.6?

Most likely because the reviewer met prototype behavior: controls that do nothing, sample data presented as real, a login without a working backend or a published version that changed during review. To Apple, unfinished or unreachable features can look hidden or undelivered. Make every flow work end to end, pin the published version and describe each feature in the Notes for Review.

Can I submit a Figma Make prototype to the App Store?

Not as a prototype. Guideline 2.2 says demos, betas and trial versions belong in TestFlight, not on the App Store, and Guideline 2.1 expects final versions without placeholder content. Share the prototype with testers through TestFlight and submit once the app has a real backend, real accounts and features that work.

Do I have to tell Apple that my app was built with Figma Make?

No guideline requires you to name your tools. What you must disclose is what the app does: every feature in the Notes for Review, accurate metadata and, under Guideline 5.1.2(i), any sharing of personal data with third-party AI, together with explicit permission from your users.

Is the figma.site address fine for an App Store app?

It works technically, but a random three-random-words.figma.site address doesn't connect the app to your business, and on the Starter plan public web publishing requires publishing the file to the Figma Community. Use a custom domain on a paid plan, or export the code and host it yourself.

Will WebViewGold get my Figma Make app approved?

No tool can promise an approval – Apple judges the app and your conduct. WebViewGold, made by our team, gives the hardened Make app a native shell with push, Face ID, an offline screen, scanners and Apple's rating dialog. Placeholder features and mock logins still have to be fixed in the Make file itself.

Can I keep editing in Figma Make after approval?

Yes. Updating the published version with content and bug fixes is normal for a wrapped web app. New features, purchases or changes to what the app does should ship with a new app build and review notes – and the published version should never change while a build is in review.

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.

Figma Make App Rejected Under Guideline 5.6: From Convincing Prototype to Reviewable App