flutter_inappwebview is an Apache-2.0 Flutter plugin, distributed on pub.dev as flutter_inappwebview, that lets Dart developers embed an inline webview, run a headless webview, and open an in-app browser window across Android, iOS, macOS, Windows, Linux, and web targets.

What it is

flutter_inappwebview lives in the Flutter and Dart ecosystem, published as the flutter_inappwebview package with documentation hosted at inappwebview.dev. It is a webview library rather than an application: the source is written in Dart, licensed under Apache-2.0, and the repository carries 3,773 stars, 2,137 forks, and 214 open issues, with the most recent push on 10 February 2026. The project is split into platform packages — flutter_inappwebview_platform_interface, flutter_inappwebview_android, flutter_inappwebview_ios, flutter_inappwebview_macos, flutter_inappwebview_windows, flutter_inappwebview_linux, and flutter_inappwebview_web — so that each target is implemented behind a shared interface.

The concrete problem it solves is putting web content inside a Flutter app and controlling it from Dart, without hand-writing a separate webview integration for every target platform. It replaces that per-platform wiring with one package surface. The plugin covers three distinct shapes of web surface: an inline webview rendered inside the widget tree, a headless webview for work that needs no visible UI, and an in-app browser window for opening pages without leaving the application. It also exposes the machinery those surfaces depend on — a cookie manager, web storage, and configurable webview options — so an app does not have to reach into native code for routine session and rendering control.

Key capabilities

• Inline webview: render web content directly inside a Flutter widget tree.
• Headless webview: run a webview with no visible surface, for background loading and processing.
• In-app browser window: open pages in a browser surface contained within the app.
• Cookie manager: read and control cookies from Dart.
• Web storage support, handled alongside cookie handling.
• Configurable webview options exposed to Dart rather than locked to native defaults.
• Per-platform implementations, including WKWebView on Apple platforms and WebView2 on Windows, with dedicated packages for Android, iOS, macOS, Windows, Linux, and web.

Who uses it and how

• Mobile Flutter teams building Android and iOS apps that embed web content rather than sending users to an external browser.
• Desktop Flutter projects, which are served by the macOS, Windows, and Linux packages, including the WebView2-backed Windows target.
• Teams shipping to the web, covered by the separate flutter_inappwebview_web package.
• Applications that need in-app browsing, such as account, checkout, or content flows that must stay inside the app shell.
• Projects that need a headless webview for loading and inspecting pages without rendering them.
• A broad contributor base and a public showcase page of open-source projects, which indicate adoption beyond a single team.

Getting started

Add the flutter_inappwebview package from pub.dev to a Flutter project and follow the guides at inappwebview.dev/docs. Full API documentation is published on pub.dev, and working examples live in the flutter_inappwebview_examples repository and the plugin's own example/integration_test/ directory.

How it compares

Among the tools named in these facts, flutter_inappwebview sits above the platform engines rather than beside them: its topic list points to WKWebView on Apple platforms and WebView2 on Windows, which are the native layers the plugin wraps. No paid products or direct alternatives are listed in the supplied facts, so on the axes of licence, self-hosting, data ownership, and cost model this entry stands alone in this registry.

When to use it — and when not to

A self-hoster operates nothing beyond a normal Flutter build: the facts mention no database, object storage, SMTP service, or server component to run. Teams not working in Flutter or Dart should look elsewhere, since the plugin is a Dart package bound to the Flutter framework. The signs of strain are worth weighing honestly — 214 open issues, a README excerpt dominated by badges and link lists rather than a structured feature guide, and no release information in the supplied facts — so plan on reading the external documentation at inappwebview.dev rather than relying on the repository front page.