Why might App Review reject a Flutter app that is mostly one webview_flutter WebViewWidget showing your website, and what helps it pass?
answer
- minimum functionality guideline
- a repackaged website adds nothing
- reviewers judge behaviour, not framework
- native value: offline, notifications, device features
- placeholder screens read as incomplete
basics
~20 sApple's minimum-functionality rule rejects apps that are little more than a repackaged website. A Flutter shell around one WebViewWidget looks exactly like that; building core flows as Flutter screens with app-only value such as offline use or notifications helps it pass.
solid answer
~40 sApp Review judges what the app does, not what it is built with. Apple's minimum-functionality guideline turns away apps that merely repackage a website, and Google Play has a comparable spam and minimum-functionality policy. A Flutter app whose `home` is a single `WebViewWidget` driven by a `WebViewController.loadRequest` to your site fits that description, whatever framework hosts it. What helps is value the website cannot give: core flows built as Flutter screens, offline access to data the user already loaded, push notifications, camera or other device features, and navigation that behaves like an app. Keeping a WebView for specific content, such as help pages or a legacy checkout, is fine. Placeholder screens, broken links and 'coming soon' tabs draw a separate incompleteness rejection.
go deeper
Recall that a website shown in one WebView can be rejected as too thin, whatever framework hosts it.
Explain which app-only features reviewers look for and how to keep a WebView for secondary content without failing the rule.
Show how you would reshape a WebView-first app into a reviewable product and respond to a rejection with concrete features.
Weigh building core flows natively against a web-first strategy, including what store policy makes a wrapper app cost.
## What the rule is about Both stores want apps to offer something beyond a bookmark: - Apple's **App Store Review Guidelines** include a **minimum functionality** section (4.2) that rejects apps that are not very useful, not app-like, or simply a website packaged as an app. - Google Play's **Spam and Minimum Functionality** policy covers apps with limited functionality or content in a similar spirit. Neither rule mentions frameworks. The Flutter FAQ is explicit that Flutter apps are published and approved like any other app, provided they comply with these policies. So the question is never "is it Flutter" but "does it do more than the website". ## Why a Flutter WebView shell looks like a website wrapper A common shortcut is an app whose root widget is one `WebViewWidget` from `webview_flutter`, with a `WebViewController` that calls `loadRequest` on the company site and maybe `addJavaScriptChannel` for a bridge. To a reviewer that app: - shows the same pages as mobile Safari; - has web navigation chrome, web forms and web loading spinners; - fails with a blank page or browser error when offline; - offers no feature that uses the device. That is precisely the pattern the guideline describes. ## What helps it pass | Signal | Example in a Flutter app | |---|---| | Core flows built natively in Flutter | browsing, search and account screens as widgets calling your API | | Offline behaviour | recently viewed items cached locally and shown without a connection | | Push notifications | order or reminder alerts through a messaging plugin | | Device features | camera scanning, location, biometrics, sharing sheets | | App-like navigation | a bottom navigation bar and back behaviour that follow platform conventions | A WebView still has a place: help articles, terms, a rarely used legacy flow. The problem is an app that is **only** a WebView. ## Where Flutter's rendering fits in Flutter draws its own widgets rather than wrapping platform ones, which sometimes leads teams to assume reviewers cannot tell a Flutter shell from a native app. That misses how review works. Inside a `WebViewWidget` the page is rendered by the platform web view, so it looks and behaves like the website, links and all. The reviewer does not inspect rendering technology; they use the app and compare it with what a browser offers. Flutter only changes the picture when the flows themselves are built as Flutter screens, because then the app has behaviour the website does not. ## Related rejections that hit early versions 1. **Incomplete apps.** Placeholder text, empty tabs, "coming soon" screens and dead links read as an unfinished product under Apple's app-completeness rules. 2. **Crashes and blank screens.** A WebView that loads nothing because the reviewer's network blocks your domain, or because of a missing Android `INTERNET` permission in a release build, looks broken. 3. **Login walls.** A WebView login with no demo account is unreviewable. ## How to argue the case If an app is rejected under minimum functionality, the reply in App Store Connect should list concrete app-only features, not the framework. Saying "it is built with Flutter, not a web wrapper" misses the point: reviewers never see the framework, only the behaviour. Adding one or two substantial native features is usually more persuasive than any explanation.
- The rejected Flutter app does use Flutter widgets for its tab bar, with a WebView in each tab. Does that satisfy the minimum-functionality rule?Probably not by itself. A native tab bar around web pages still delivers the website's content and behaviour. Reviewers look for value the site cannot offer, such as core flows built as screens, offline access, notifications or device features, so move at least the main flows out of the WebView.
saying these in an interview costs you the question
- Because Flutter draws its own pixels, reviewers cannot tell it wraps a website.
- Stores reject Flutter apps more often simply because they are not native.
- Any WebView in a Flutter app triggers a minimum-functionality rejection.
- Explaining the tech stack to App Review overturns the rejection.