flutter_inappwebviewとは？6.1系の停滞とJS連携・Cookie制御の判断【2026年8月時点】

flutter_inappwebviewは、Flutterで作ったアプリの中にWebページを埋め込み、その読み込みや通信を細かく制御するためのパッケージです。2026年8月時点の安定版は6.1.5で、公開からおよそ22か月が経過しました。一方でprereleaseの6.2.0-beta.3はLinux対応まで進み、要求するFlutter SDKも3.32系へ上がっています。流通する解説記事の多くは、この分断が起きる前の6.0〜6.1系の使い方で止まったままです。本記事では表示形態とcallHandlerによるJavaScript連携、Cookieの引き継ぎ、公式webview_flutterとの線引き、入れないほうがよい場面を一次情報から整理します。

まとめ：埋め込み要件の広さと版の停滞を突き合わせて採否を決める

選ぶ理由になるのは「WebページをFlutter側から操作する必要があるか」の一点です。読み込みの進行度、リソース単位の横取り、ダウンロードの受け止め、独自スキームの処理まで求められる案件では、公式のwebview_flutterでは届きません。逆に、ヘルプや利用規約をただ表示するだけなら公式パッケージで足ります。

導入前に押さえる数値は3つ。安定版6.1.5が要求するのはDart 3.5系とFlutter 3.24系、Androidの最低条件はminSdkVersion 19とcompileSdk 34、公開は約22か月前で更新はprerelease側に寄っています。6.2.0-beta.3はDart 3.8系とFlutter 3.32系を求める仕様です。新しいFlutterで動かしたい要求は、beta系を取るかの判断と直結します。

受託で載せるなら版の選択を先に決め、根拠を引き継ぎ資料へ残してください。安定版で固定するなら、周辺のFlutter更新も止める前提になります。

flutter_inappwebviewが提供する4つの表示形態と対応プラットフォーム

このパッケージは単一のウィジェットではなく、埋め込み方の異なる複数の入り口を持つ構成です。どれを選ぶかで、Flutter側から届く制御の深さと画面の見え方が変わります。

InAppWebViewとHeadlessInAppWebViewが担う役割の違い

InAppWebViewは、Flutterのウィジェットツリーの中に置く埋め込み型のWebViewです。レイアウトへ組み込めるため、上部に自前のツールバーを置き、下部にネイティブのボタンを並べる作りができます。読み込みの開始や終了、進行度、エラーはイベントとしてFlutter側へ流れます。

HeadlessInAppWebViewは画面に出さないWebViewです。表示を伴わないままページを読み込み、JavaScriptを実行して結果だけを受け取る用途に向きます。ログイン処理を裏で走らせてCookieを取得する、対象ページのDOMから値を拾う処理が代表例です。ユーザーには何も見えないため、通信の失敗を伝える経路は別途用意してください。

InAppBrowserとChromeSafariBrowserを外部表示に回す条件

InAppBrowserは、アプリの上に別ウィンドウとしてWebViewを開く形態です。アドレスバーや進む戻るを備えた画面が用意され、外部サイトを一時的に見せる用途に向きます。制御の深さはInAppWebViewとほぼ同じで、実装は短く済みます。

ChromeSafariBrowserは、Androidのカスタムタブ、iOSのSFSafariViewControllerを呼び出す形態です。ここだけは性質が異なり、ページの中身をアプリ側から触れません。その代わり端末のブラウザとCookieを共有します。決済やOAuthの同意画面のように、アプリ側が介入すべきでない画面はこちらへ回すのが安全です。

Android・iOS・macOS・Windows・Webで変わる実装の土台

pub.devの表示では、6.1.5の対応プラットフォームはAndroid・iOS・macOS・Web・Windowsです。ただし内部の土台は同じではありません。AndroidはシステムのWebView、iOSとmacOSはWKWebView、Windowsは埋め込み用のWebView環境を使い、Webではiframeへ落ちます。同じコードでも使えるAPIと挙動は土台に引きずられます。

最低条件はAndroidがminSdkVersion 19かつcompileSdk 34、iOSが12.0以上、macOSが10.14以上。compileSdkの下限が34である点は確認しておきたい箇所です。Web向けビルドの制約はFlutter Webとは？CanvasKitとWasmの描画差・SEO制約・採用条件と合わせて判断してください。

6.1.5で止まった安定版と6.2.0-beta系が抱える版の判断

この節が、他の解説記事と最も食い違う部分です。使い方だけを追うと見落としますが、採用判断では版の状況が先に来ます。2026年8月時点でpub.devが示す事実をそのまま並べます。

安定版6.1.5が要求するFlutter 3.24系とSDKの下限条件

安定版の最新は6.1.5で、pub.devの表示では公開から約22か月。内容は複数のFlutterウィンドウへの対応、callAsyncJavaScriptがJSONオブジェクトを扱う際の修正、独自スキームのリソース読み込みイベントの修正でした。要求はDart 3.5系以上、Flutter 3.24系以上です。

問題は、下限ではなく上限が保証されていない点です。22か月前の実装が新しいSDKでそのまま通るとは限りません。導入前に、案件で使うFlutterのバージョンでビルドと実機確認まで通す手順を挟んでください。SDKを固定する方法はFlutterの環境構築｜Windows・macOS別のSDK導入とflutter doctor診断で扱っています。

6.2.0-beta.3で入ったLinux対応と要求Flutterの引き上げ

prereleaseの6.2.0-beta.3は、pub.devの表示で公開から約6か月です。この系列ではLinux対応が追加され、要求がDart 3.8系以上、Flutter 3.32系以上へ引き上げられました。機能面では、対応状況を実行時に確かめるisClassSupported系の判定、状態を保存して戻すsaveStateとrestoreState、全画面表示の要求、faviconの取得、Web通知を扱うコントローラが加わりました。

破壊的変更も入りました。6.2.0-beta.1で、Ajaxの横取り設定interceptOnlyAsyncAjaxRequestsの既定値がtrueへ変わっています。同期リクエストがプラットフォームチャネルの非同期性で止まる問題を避ける変更で、同期Ajaxまで横取りしていた実装は挙動が変わります。6.1系から上げるなら、この設定の明示が最初の確認箇所です。

6.2.0-beta系を本番の受託案件に載せてよいかの判断基準

beta系を選んでよいのは、次の3つが揃うときだけだと考えています。第一に、案件のFlutterが3.32系以上で固定されていること。第二に、beta.4以降で再び破壊的変更が入っても追随できる保守契約があること。第三に、Linux対応やsaveStateのように、beta系にしかない機能が要件そのものであること。

逆に、納品後の改修予定がない一括請負でbeta系を選ぶのは避けたほうが無難です。prereleaseはpub.devの依存解決でも明示指定が要り、後任の開発者が意図を読み違えやすくなります。

JavaScript連携をcallHandlerで組み立てる手順と初期化の順序

このパッケージが選ばれる理由の中心が、Flutterと埋め込みページの双方向通信です。公式パッケージとの差が最も大きい部分でもあります。手順そのものは短いのですが、初期化の順序を外すと呼び出しが届きません。

addJavaScriptHandlerを登録する位置と初期化の順序

Flutter側では、コントローラのaddJavaScriptHandlerにハンドラ名とコールバックを渡して登録します。コールバックはJavaScript側の引数を受け取り、戻り値はJSONへ変換されて返ります。登録の位置はonWebViewCreatedの中が基本です。

ページが読み込まれた後に登録すると、その時点で走っているスクリプトからは呼べません。登録はWebViewが生成された直後に済ませる順序を守ってください。ブリッジ自体はjavaScriptBridgeEnabledで制御され、既定値はtrue。対応はAndroid・iOS・macOS・Windowsで、Web向けビルドでは同じようには動きません。

callHandlerが返すPromiseと戻り値をJSONで受ける

JavaScript側からの呼び出しは、window直下に生えるブリッジオブジェクト経由で行います。呼び出し式はwindow.flutter_inappwebview.callHandler(handlerName, ...args)で、第1引数がハンドラ名、以降が任意の引数。この呼び出しはPromiseを返すため、thenで結果を受け取れます。

戻り値がJSONへ変換される点は設計に影響します。Dart側で返せるのはJSONで表現できる値に限られ、独自クラスをそのまま返す実装は成立しません。日時や金額は文字列や数値へ落とす形式を先に決めておくと取り違えが減ります。ブリッジ名はsetJavaScriptBridgeNameで置き換えられます。

Androidで初期化の完了イベントを待つ必要が出る条件と回避策

Androidには、ブリッジの準備が整う前にJavaScriptが動き出す条件があります。WebViewFeature.DOCUMENT_START_SCRIPTに対応していない端末では、読み込みの最初の時点でブリッジがまだ差し込まれていません。この場合、JavaScript側はflutterInAppWebViewPlatformReadyの発火を待ってから呼び出す必要があります。

実装は、埋め込むページ側でこのイベントを購読し、発火後に初回の通信を行う形へ寄せます。裏を返せば、ページのコードを自社で触れない案件では待ち合わせを仕込めません。他社管理のページで双方向通信まで行う要件は、着手前に「ページ側へスクリプトを追加できるか」を確認してください。

Cookieと認証情報をWebViewへ引き継ぐ実装と壊れる条件

ログイン済みの状態をアプリからWebViewへ渡す要件は、業務システムの案件で繰り返し出てきます。このパッケージはCookieを直接扱うAPIを備えていますが、プラットフォームごとに使えるメソッドが違います。

CookieManagerのsetCookieとgetCookiesで扱える項目

Cookieの操作はCookieManagerのシングルトンを取り出して行います。設定側はsetCookieで、対象のURL、名前、値に加え有効期限やセキュア属性を指定できます。取得側はURL単位のgetCookies、名前まで絞るgetCookieの2つ。削除はdeleteCookie、deleteCookies、deleteAllCookiesが用意されています。

WindowsでカスタムのWebView環境を使う場合は、シングルトンを取り出すときにその環境を渡します。渡し忘れると参照先が食い違い、設定したはずのCookieが読めません。

iOS 11未満とWeb実装でJavaScript経由になる制約

公式ドキュメントは、iOS 11未満とmacOS 10.13、Web向けビルドでは、ほとんどのメソッドがJavaScriptで実装されていると明記しています。そのうちdeleteAllCookiesとgetAllCookiesは非対応。JavaScript経由では、ブラウザがスクリプトへ見せない情報に手が届きません。

実務で影響が出るのはHttpOnly属性の付いたCookieです。サーバー側がセッションIDにHttpOnlyを付けていると、JavaScript実装へ落ちる環境では読み取れません。対応OSの下限を引き上げられる案件なら、iOS 11以上を前提にしてこの分岐を消すほうが実装は安定します。

WebViewへログイン状態を引き継ぐ設計とトークンの置き場所

Cookieを直接書き込む方式は手軽ですが、認証情報をアプリ側のどこに保管するかという問題は残ります。埋め込みページへ渡すトークンを平文で持ち回ると、端末を解析された時点で成りすましが成立します。保管先の選び方はflutter_secure_storageとは？11.0系の暗号方式とトークン保存の判断の基準に沿って決めてください。

もう1つは、Cookieを書かずリクエストのヘッダへ認証情報を載せる方式です。初回のURLRequestにヘッダを付ければ、WebView側のCookieストアには何も残りません。ただしページ内の画面遷移にはヘッダが引き継がれないため、単一ページで完結する画面に限られます。

webview_flutterと選び分ける基準を機能と保守の両面で決める

比較記事の多くは「公式は機能が少ない」という前提で書かれています。ただし2026年8月時点の公式パッケージは、その説明が一律には当てはまらない段階です。数字と機能の両方を突き合わせて線を引き直します。

公式パッケージwebview_flutter 4.14系が埋めた機能の範囲

webview_flutterの最新は4.14.1で、pub.devの表示では公開から約6週間。publisherはflutter.dev、pub pointsは160、週あたりのダウンロードは286万件です。対応はAndroid SDK 24以上、iOS 13.0以上、macOS 10.15以上の3つに絞られています。

Cookie操作は、WebViewCookieManagerがclearCookiesとsetCookieに加えgetCookiesを備える構成です。ドメイン指定で一覧を取る形なので、「公式ではCookieを読めない」と書いた古い比較記事は実態と食い違います。表示と読み込み制御、Cookieの読み書きで要件が閉じるなら公式側で足ります。

postMessageとcallHandlerで変わる双方向通信の作りやすさ

差が残るのはJavaScript連携の方式です。公式のaddJavaScriptChannelは、チャンネル名と受信コールバックを登録する片方向の仕組みで、JavaScript側はPrint.postMessage('Hello')のように文字列を送ります。戻り値は返りません。返答が必要なら、Dart側からスクリプトを実行して結果を書き戻す実装を自分で組みます。

flutter_inappwebviewのcallHandlerはPromiseを返すため、呼んで待って受け取る流れをそのまま書ける仕組みです。埋め込みページからネイティブの機能を呼び、結果に応じて表示を変える設計では、この差が実装量に直結します。公式側にはチャンネルの登録変更が次の読み込みから有効になる制約もあります。React Native側で同じ連携を組む場合はreact-native-webviewとは？postMessage連携と版が三つに割れた導入判断を参照してください。

対応プラットフォームの広さと更新頻度から見る採用判断の分かれ目

判断軸は2つ。1つは対応範囲で、WindowsやWebまで含めるならflutter_inappwebview、モバイルとmacOSで足りるなら公式。もう1つは更新頻度で、公式が約6週間前なのに対し、flutter_inappwebviewの安定版は約22か月前です。

ダウンロード数の差は、公式が既定の選択肢になっている実態を示します。それでも109万件を保つのは、公式では届かない制御を要する案件が一定数あるためです。要件が「表示＋α」に収まるかを設計段階で言い切っておくと迷いが減ります。

flutter_inappwebviewを採用しない判断が正しくなる場面

機能が多いパッケージは、要件に対して過剰になりやすい性質を持ちます。ここでは、あえて選ばない判断が案件の総コストを下げる場面を挙げます。

Webページを表示するだけの画面でこのパッケージを見送る基準

利用規約やヘルプセンターのように表示して戻るだけの画面しかないなら、公式のwebview_flutterで完結します。ここでflutter_inappwebviewを選ぶと、使わない設定項目とイベントの分だけコードが読みにくくなり、更新の止まった依存を1つ抱え込みます。

目安は、Flutter側から埋め込みページへ「命令」を出す必要があるかどうか。読み込むだけならイベントの購読で足り、命令が要るならブリッジが要ります。

WebView中心の設計に寄せた案件で後から生じる作業の量と費用

既存のWebシステムをそのまま包んでアプリ化する設計は、初期の見積もりが小さく出ます。ただし後から生じる作業が読みにくい。プッシュ通知からの画面遷移、オフライン時の表示、戻る操作とページ履歴の整合、ファイルの送受信は、いずれもWebView側で個別に組む必要があります。

加えて、埋め込むWebシステムが更新されるたびにアプリの挙動確認が発生します。保守の担当が分かれていると、この確認が抜けたまま公開されて不具合につながります。どこまでをWebに任せるかの線引きに迷う場合は、Flutter / React Nativeによるクロスプラットフォーム開発で扱っている設計段階の相談としてご検討ください。前提となるFlutter自体を選び続けてよいかはFlutterの将来性を数値で判断する｜リリース実績・国内案件数・競合の現在地で数値から整理しています。

よくある質問

flutter_inappwebviewは商用のアプリで無料で使えますか？

pub.devで公開されているオープンソースのパッケージで、商用利用に追加の費用は発生しません。publisherはinappwebview.devとして認証済みの表示です。ライセンス条項と依存コンポーネントの条件は、納品前に自社で確認してください。

安定版が約22か月更新されていないのは危険な兆候ですか？

そのまま危険とは言い切れません。開発はprereleaseの6.2.0-beta系で続いています。判断すべきは、案件で使うFlutterのバージョンで安定版が動くかどうか。動作確認が取れるなら安定版で固定し、取れないならbeta系か公式パッケージへ切り替える形になります。

webview_flutterから乗り換えるときの作業量はどれくらいですか？

ウィジェットの置き換えとイベント名の対応付けが中心のため、表示だけの画面なら短時間で済みます。手間がかかるのはJavaScript連携で、postMessage前提の片方向の作りをcallHandlerの往復へ組み替える設計変更が入ります。埋め込むページ側の書き換えも見積もりへ含めてください。

埋め込んだページからネイティブの機能を呼び出せますか？

addJavaScriptHandlerで登録したハンドラをJavaScript側から呼べば実現できます。呼び出しはPromiseを返すため、処理結果を待って表示を切り替える流れが書けます。ただし埋め込むページへスクリプトを追加できることが前提です。

Web向けビルドでも同じように動きますか？

Webでは内部がiframeへ落ちるため、動作は同じになりません。Cookie操作もJavaScript実装となり、deleteAllCookiesとgetAllCookiesは使えない旨がドキュメントに明記されています。ブリッジの対応もAndroid・iOS・macOS・Windowsのみで、Webを含む案件では機能の可否を個別に確認してください。

関連記事

• flutter_secure_storageとは？11.0系の暗号方式とトークン保存の判断：WebViewへ渡す認証情報の保管先の決め方
• Flutter Webとは？CanvasKitとWasmの描画差・SEO制約・採用条件：Web向けビルドで生じる制約の前提
• Flutterの環境構築｜Windows・macOS別のSDK導入とflutter doctor診断：SDKの版を固定して検証する前段の手順
• Flutterの将来性を数値で判断する｜リリース実績・国内案件数・競合の現在地：Flutter自体を続けるかどうかの判断材料
• React Nativeとは？仕組みとNew Architectureの構造・採用判断を実装目線で解説：もう一方のクロスプラットフォーム候補