FlutterFlow App Store Rejected? Causes and Fixes (2026)

Your FlutterFlow app was almost certainly not rejected for being built in FlutterFlow. Apple and Google review the app you ship, not the tool you built it with, and FlutterFlow ships a real compiled Flutter binary. Rejections come from a short list of concrete causes: Apple guidelines like 4.2, 4.3, 3.1.1, 4.8, and 5.1.1, a missing privacy manifest, a missing demo account, or a launch crash. On Google Play the usual blocker is the closed-testing rule for new accounts and signing errors. Every one of them has a specific fix, and the table below sends you straight to yours.

TL;DR - FlutterFlow itself is not the reason. Apple and Google review the binary, and yours is a standard Flutter app. - The rejections that hit FlutterFlow apps most are the ones its default auth and permission widgets create: no in-app account deletion (5.1.1(v)), social login without Sign in with Apple (4.8), and vague permission strings (5.1.1(ii)). - Other common Apple causes: 4.2 minimum functionality, 4.3 design spam, 3.1.1 in-app purchase, a missing privacy manifest, no demo account (2.1(a)), and launch crashes. - Google Play's usual blockers: the 12-tester / 14-day closed test for new personal accounts, plus keystore and signing errors. - Some rejections are a settings toggle. Others mean the default build pattern will keep getting flagged, and a rebuild is faster than fighting review. The last section shows how to tell which one you have.

Find your rejection code and jump to the fix

Apple and Google name a specific guideline or reason in the rejection message. Match yours to the table, then read the section for the fix.

Is FlutterFlow the reason Apple rejected my app?

No, FlutterFlow is not banned from the App Store and is not a rejection reason on its own. It compiles your project to a native Flutter binary, and App Review judges that binary against the same guidelines as any other app. It is the same platform we work with on FlutterFlow rescue and support projects, and approved apps built with it are common. The reason so many FlutterFlow builders hit the same walls is narrower than the tool: the default auth, permission, and template widgets generate the exact patterns several guidelines target. The sections below name each one.

The guidelines Apple rejects FlutterFlow apps under

Apple rejects FlutterFlow apps under a recurring set of guidelines, and the most common ones are not about design at all, they are the account, login, and permission rules that FlutterFlow's default widgets set up incompletely. Find your guideline number below.

Guideline 5.1.1(v): Account Deletion

This is the most common FlutterFlow rejection tied to how the platform builds auth. Apple's rule is short: "if your app supports account creation, you must also offer account deletion within the app." FlutterFlow's Firebase Auth widgets drop in a sign-up and login flow, but they do not add a delete-account path, so an app that lets users register and never lets them delete gets rejected. The fix is to add a Settings action that deletes the Firebase Auth user, removes that user's database rows, and confirms the deletion in the app. If you offer Sign in with Apple, Apple also requires you to revoke the token through its REST API on deletion, not just deactivate the account; for Google or Facebook login, clear the stored credentials. Social logins count the same as email sign-up for the deletion requirement itself.

Guideline 4.8: Sign in with Apple

If your app offers a third-party or social login, Apple requires an equivalent private option next to it. The guideline covers "apps that use a third-party or social login service (such as Facebook Login, Google Sign-In... or WeChat Login) to set up or authenticate the user's primary account," which "must also offer as an equivalent option another login service." In practice that means Sign in with Apple. FlutterFlow makes it a one-click job to add Continue with Google and ship, which is a direct 4.8 rejection. The fix is to enable Sign in with Apple in FlutterFlow's auth settings and add the Sign In with Apple capability to your App ID, so it sits alongside the social option. Apps that use only their own email and password account system, or only education or enterprise accounts, are exempt.

Guideline 5.1.1(ii): Permission purpose strings

Apple rejects apps that ask for a permission without clearly saying why. The guideline requires that you "ensure your purpose strings clearly and completely describe your use of the data." FlutterFlow apps trip this when a widget that needs the camera, location, photos, or microphone ships with a generic usage string, or when a permission-requiring widget was added and half-removed and left its NSUsageDescription behind. The fix is to write a specific purpose string for each permission you actually use ("used to attach a photo to your profile," not "needs camera access"), and delete any permission whose feature is no longer in the app. This is a different thing from the privacy manifest below: purpose strings explain a prompt the user sees, the manifest declares required-reason APIs to Apple.

Guideline 2.1(a): Give the reviewer a way in

If your whole app sits behind a login, and most FlutterFlow apps with Firebase Auth do, the reviewer needs a way past it. Guideline 2.1(a) asks you to "provide App Review with full access to your app," with "either an active demo account or fully-featured demo mode... e.g. login credentials." No credentials means the reviewer is stuck at your login screen and rejects under 2.1. The fix is to put a working demo login in the App Review notes in App Store Connect, confirm that account is not rate-limited or expired, and if there is a phone or one-time-code step, provide a bypass or explain it.

Guideline 4.2: Minimum Functionality

Apple rejects apps that do not do enough. The App Review Guidelines state that "your app should include features, content, and UI that elevate it beyond a repackaged website" and that if an app "doesn't provide some sort of lasting entertainment value or adequate utility, it may not be accepted." A related clause, 4.2.2, says apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." FlutterFlow apps trip this when they are mostly a WebView, a feed with little interaction, or a thin wrapper over a website. The fix is to add genuine native capability: push notifications, offline behavior, device features like camera or location, or account-specific functionality a user could not get by opening your site in a browser.

Guideline 4.3: Design Spam

Guideline 4.3 targets duplication and templated sameness. Apple tells developers not to "create multiple Bundle IDs of the same app" and, under 4.3(b), not to "submit apps that are indistinguishable from what's already widely available," because "opportunistically creating variants of existing app categories or popular apps degrades App Store discovery." This hits low-code apps hard because starter templates produce a recognizable look, and saturated categories such as dating, wallpapers, or simple utilities draw extra scrutiny. If you are cited under 4.3, generic UI and a common concept are the problem, not your build tool. Move the visual identity off the template default, sharpen what makes the app distinct, and in the appeal explain the concrete features and audience that set it apart. This is the rejection that traps builders longest, because cosmetic edits do not change the concept the guideline is actually judging.

Guideline 3.1.1: In-App Purchase

If your app unlocks digital content or subscriptions, Apple requires its own in-app purchase system. Guideline 3.1.1 is explicit: "if you want to unlock features or functionality within your app... you must use in-app purchase," and apps "may not use their own mechanisms to unlock content or functionality, such as license keys" or other payment methods. FlutterFlow's Stripe integration is fine for physical goods and real-world services, but using it to sell digital subscriptions or premium features is a 3.1.1 rejection. Route digital purchases through Apple in-app purchase and reserve Stripe for physical or in-person transactions. One caveat for 2026: after the 2025 US court ruling in Epic v. Apple, the rules for linking out to external purchases in the US are a narrow and still actively litigated carve-out, not a default you can assume. Treat Apple in-app purchase as the safe path everywhere unless you have deliberately set up and confirmed an external-purchase option.

Missing Privacy Manifest (ITMS-91053)

Since May 1, 2024, Apple requires a privacy manifest that declares why your app uses certain protected APIs, and a missing declaration returns the error ITMS-91053: Missing API declaration. FlutterFlow builds a manifest for you, but you have to configure the reasons. In FlutterFlow, open App Settings and find Privacy Manifest Configuration (the exact menu path can vary by FlutterFlow version), then:

1. Activate the required-reason API categories your app uses.
2. Select the appropriate reason for each from the dropdown.
3. Rebuild and resubmit.

This follows FlutterFlow's own deployment documentation. Note that the privacy manifest also declares data collection and tracking domains, so if you see a related manifest error rather than 91053, check those sections too, not just the required-reason APIs. Separately from the manifest, App Review also checks that the App Privacy details you fill in on App Store Connect match what the app actually collects and that you have a working privacy policy URL, and a mismatch there is its own rejection under 5.1.1(i).

Crashes on launch

Apple cannot review an app it cannot open, and a launch crash returns a message that the app could not be reviewed because it crashed on launch. For FlutterFlow apps the frequent culprit is a startup failure that reviewers hit but you did not: a Firebase configuration that works on your test device but fails in the review environment, the GoogleService-Info.plist not bundled into the release build scheme, or a permission requested before the feature that needs it is set up. Because Firebase is often the trigger, and misconfigured auth is a common form of it, our FlutterFlow Firebase auth fix guide covers that failure in depth. Reproduce the crash on a clean device using the exact release build, check your crash logs, and confirm every backend and config dependency is present in the production build, not just in debug.

In-app purchase bugs

Even when you use Apple in-app purchase correctly, a broken purchase flow gets rejected because it creates a poor user experience. The common failure is a subscription screen that loads forever or errors when the reviewer taps to buy. Test the entire purchase path in the sandbox environment, including restore purchases, before you resubmit, and make sure products are approved and available in App Store Connect.

Why Google Play rejects FlutterFlow apps (and why your Play Store submission failed)

If your FlutterFlow app was rejected on the Play Store, the cause splits into two groups: policy blocks that apply to your account before your app is judged on merit, and build or signing errors in the FlutterFlow output. The policy one surprises most first-time publishers, because it has nothing to do with your app at all.

The 12-tester / 14-day rule

If you created a personal Google Play developer account after November 13, 2023, you must run a closed test with at least 12 testers opted in for 14 continuous days before you can apply for production access, according to Play Console Help. This requirement started at 20 testers in November 2023 and was reduced to 12 on December 11, 2024, so older guides that say 20 are out of date. Organization accounts are exempt. This is not a FlutterFlow issue, it is an account-level gate, and the fix is simply to run the closed test with real opted-in testers for the full 14 days before requesting production.

Keystore, signing, and package name errors

FlutterFlow build output gets rejected by the Play Console when it is signed wrong or named wrong. Common cases are a bundle signed in debug mode instead of release, an Android App Bundle signed with the wrong key so the certificate fingerprint does not match what Google expects, or a package name in the wrong shape. An Android application ID needs at least two segments, each starting with a letter; stick to lowercase letters, digits, and underscores, which is Play's recommended convention. Fix the signing config so the release bundle is signed with your upload key, correct the package name in FlutterFlow before building, and re-upload.

"App loads but not responsive"

Google has its own version of minimum functionality. Apps get rejected when they load but show no content or do not respond, for example an entry screen with no text or a page that never becomes interactive. This usually points to a backend or data-loading failure in the release build rather than a design choice. Test the release build on a fresh device or emulator with a clean install, and confirm the first screen loads real content without a logged-in session or cached data.

Config fix versus full rebuild: how to tell

Most of the rejections above are a settings change: add the delete-account action, enable Sign in with Apple, write the purpose strings, activate the privacy manifest, provide a demo login, correct the signing config, run the closed test. Fix the specific item, resubmit, and you are through. The trap is treating a structural rejection as a settings change and resubmitting the same app over and over.

A rejection is structural, and a rebuild or partial migration is usually faster than fighting review, when the cause is baked into how the app was built rather than into a toggle. The clearest signals are: repeated 4.3 spam or 4.2 functionality rejections that survive cosmetic changes, because the concept and interaction model are the real problem; launch crashes you cannot reproduce or trace because the generated project hides the failure; or a feature you need that the platform cannot express, so you keep bolting on custom code that then breaks review. If that pushes you toward leaving the platform entirely, know that exporting FlutterFlow code has real caveats worth understanding before you commit. When two or three resubmissions do not move the outcome, the app is telling you the fix is not in the settings panel. That is the point to get a second opinion from someone who reviews the build itself, decides what is genuinely a config fix, and rebuilds only the parts that are blocking launch.

FAQ

Is FlutterFlow banned from the App Store?

No, there is no policy against FlutterFlow or no-code tools. Apple reviews the compiled binary against its guidelines, and FlutterFlow apps that meet those guidelines are approved. Rejections cite a specific guideline number that you fix.

Why does my FlutterFlow app keep getting rejected on iOS?

Because the same underlying cause is still there. The most common repeat rejections for FlutterFlow apps on iOS are missing in-app account deletion (5.1.1(v)), social login without Sign in with Apple (4.8), and vague permission strings (5.1.1(ii)), all of which come from default widget setups. Fix the specific guideline cited, not the surface wording, and confirm the fix is in the release build.

Can I appeal a 4.3 spam rejection?

Yes, use the Resolution Center to explain what makes your app distinct: its concept, audience, and specific features, not just visual tweaks. Many 4.3 appeals fail because they change the look but not the underlying sameness the guideline targets, so lead with genuine differentiation.

Will Apple reject my app just because it is no-code?

No, the build tool is not a rejection reason. What gets flagged is the pattern the default templates, auth, and permission widgets tend to produce, such as thin functionality, a missing account-deletion path, or a generic template look, all of which you can change.

Does Google Play's tester rule apply to my company account?

No, the 12-tester, 14-day closed-testing requirement applies to personal developer accounts created after November 13, 2023. Organization accounts are exempt, per Play Console Help.

How long does re-review take after I fix the rejection?

Apple and Google re-review a resubmission the same way as a new submission, usually fast, often within a day or two, though appeals under contested guidelines like 4.3 can take longer because they involve a human reviewing your written explanation.

Stuck on a rejection that will not clear no matter what you change? Get a free assessment of your stuck app from AppStuck. We look at the actual build, tell you what is a settings fix versus a structural one, and get you to launch.