Meta、Windows 11向けWhatsAppネイティブアプリを終了し、Webラッパー（WebView）に置き換え

 (windowslatest.com)
2 ポイント 投稿者 GN⁺ 2025-11-14 | 1件のコメント | WhatsAppで共有
  • Windows 11向けWhatsAppがWebView2ベースのWebラッパー形式に移行し、従来のWinUI/UWPネイティブアプリは終了
  • 新バージョンはweb.whatsapp.comをWebView2コンテナで読み込み、ログイン画面でも最大300MBのRAMを使用
  • ログイン後はメモリ使用量が2GBまで増加し、平均してバックグラウンドで1.2GBのRAMを継続的に占有
  • 性能低下、遅い読み込み、通知の遅延などの問題が報告されており、Windows 11の通知機能およびおやすみモードとの互換性も低い
  • Microsoft Store経由の自動更新で配布中で、既存のネイティブアプリ利用者もまもなく強制移行される予定

WhatsAppのWindows 11版の変更

  • Windows 11向けWhatsAppがネイティブアプリからWebView2ベースのWebラッパーに移行
    • 新アプリはweb.whatsapp.comをWebView2コンテナで読み込む構造
    • 以前はElectronベースで始まり、その後UWP/WinUIネイティブアプリへ発展したが、再びWebベースへ回帰
  • この変更により性能低下と高いメモリ使用量が発生

メモリ使用量の比較

  • テスト結果では、新しいWebView2版はログイン画面で約300MBのRAMを使用
    • ログイン後にすべてのチャットを読み込むと最大2GBのRAM、平均して1.2GBのRAMをバックグラウンドで維持
  • 一方、従来のネイティブアプリは平均190MBで、アイドル時には100MB以下まで低下
    • 活動量が多い場合でも最大300MB程度にとどまる
  • 複数の会話ウィンドウを開くと新バージョンは3GBのRAMに達する可能性がある

性能および機能の問題

  • 新しいWhatsAppは反応速度の低下と長い読み込み時間を示す
    • 会話の切り替え時に遅延が発生
  • Windows通知システムとの連携が不安定で、
    おやすみモード（Do Not Disturb）およびActive Hours機能との互換性の問題が存在
  • 通知遅延の問題も報告されている

更新と回避可能性

  • WhatsAppバージョン 2.2584.3.0がMicrosoft Storeを通じて配布中で、
    既存のネイティブアプリを自動的に置き換える
  • 利用者が更新を先延ばしにすれば一時的に従来アプリを使えるが、
    すべての利用者がまもなくログアウトされ、WebView2版へ強制移行される予定

その他の文脈

  • この変更はApple Watch向けWhatsAppネイティブ体験の提供開始時期と重なっている
    • Apple Watchは1億1,500万人の利用者を抱える
    • Windowsは10億台を超えるアクティブデバイスを抱えるが、
      MetaとMicrosoftの双方がWindows向けネイティブアプリ開発を縮小する傾向にある
  • 原文ではMetaがコスト削減のため、Webコードベースの維持へ移行した可能性に触れているが、
    具体的な理由は明示されていない

関連記事

1件のコメント

 
GN⁺ 2025-11-14
Hacker Newsのコメント

  • 自分が直接設計し、見守ってきたアプリがこんなふうに変わってしまって、少しほろ苦い気持ちになった
    以前のネイティブアプリは完璧ではなかったが、生産性ツールとして環境を尊重しようとする姿勢が感じられた
    結局のところ、大企業にとってネイティブデスクトップアプリは現実的ではないと思う。理由は調整コストだ
    複数のプラットフォームで同時に機能を出そうとすると、複雑さは幾何級数的に増えていく。ゆっくりした開発ペースなら可能だろうが、素早い実験と反復を求めるなら、結局はWebのコードを一度書くほうがよいという結論に至る
    最近ではMicrosoftでさえこうしたやり方で開発している。皮肉なことに、小さな会社ほどネイティブアプリをうまく維持できる

    • その話は理解できない。自分と同僚2人でwxWidgetsを使ってオーディオ信号処理向けのクロスプラットフォームGUIを作ったが、macOSとWindowsで問題なく動いた
      大企業がテキストバブルや絵文字をネイティブで描けないというのは納得できない。昔のMSN Messengerでもその程度はできていた
    • 問題の核心は人員数ではなく調整コストだ
      ウォーターフォール方式なら問題ないが、今どきの“Agile”式開発では完全な混乱になる
      AndroidやiOSはネイティブ体験が重要だから受け入れられるが、WindowsはAPIが変わり続け、ネイティブらしさもほとんど失われている
      いっそTelegramのようにQtで作ったほうがよかった気がする
    • 以前FacebookとMessengerのWindows版を作っていたが、Web版に対して利用率が1%にも満たず、経営陣は失敗と見なしていた
    • WindowsでDBキーの秘密ストレージの場所を教えてもらえないだろうか。DBが近いうちに塞がれる前にエクスポートしたい
    • 最近のアプリはユーザーよりも開発者中心に最適化されている
      最初は職人芸で作られたネイティブアプリが人気を得るが、会社が大きくなると実験、テレメトリ、高速な反復が優先される
      独占的地位のおかげで品質は重要でなくなり、結局巨大なElectronアプリになっても誰にも止められない

  • 置き換えの理由は明確だ。Web版で新機能を素早く出していたが、ネイティブクライアントはそれに追いつくのが難しかった
    そのため結局Webラッパーへ移行したのだ
    最近の「ネイティブWindowsアプリ」という概念自体が曖昧で、性能やオフライン対応もWebで十分実現できる
    ただ、GPUプロセスが400MBまで膨らむのは少し笑ってしまう。それでもMetaのような大企業だからこそ可能なことだと思う

    • もはやWindowsでさえネイティブ感がほとんどなくなったように思える
    • 実際、以前のネイティブクライアントのほうが機能面では先を行っていた。ビデオ通話のような機能もあった
      MetaがWebクライアントを主軸にしたことで、モバイル以外のプラットフォームはすべてWebへ統合したようだ
    • 自分はいつも「全部Webでやろう」と言う開発者たちと戦っている
      「Firefoxが対応していない。Chromeは使わない」が自分の最後の切り札だったが、最近はSafariも言い訳に使わないといけない。Reactのせいだ
    • 2012年にFacebookがHTML5アプリを捨ててiOSネイティブコードへ書き直したことを思うと、今回の決定は逆行のように見える
      関連記事: Making News Feed Nearly 50% Faster on iOS
    • 最近は誰もネイティブアプリを作りたがらないか、そう主張できる立場にいないようだ
      経営陣からすると、複数のプラットフォーム向けに同じ機能を開発するのは無駄に見えるので、数字中心の開発へ流れていく
      パフォーマンスやメモリ使用量は考慮されず、「Webアプリでも十分速い」という認識が広まっている

  • 自分はWhatsAppの旧ネイティブWindowsアプリは本当にひどかったと思う
    入力がよく止まったり、アクセント付き文字が壊れたりして、再起動が必要だった。新しいElectronアプリは重いが、少なくともちゃんと動く

    • 自分も同じバグを見た。最近はチャットアプリを作るのが不可能な科学みたいに感じる。ICQの時代にはできていたのに、その技術が失われたようだ
    • 「動く」という表現は誇張かもしれない。Linuxへ移ってからは、むしろせいせいした
    • 自分もヘビーユーザーだが、今回の変化にはむしろ期待している。Electronでも以前よりはましだと信じている
    • 実はElectronではなくWebView2ベースだ
      Microsoft WebView2公式ページ
    • Metaにあれほど人材がいると言われながら、こんなアプリを出してきたのは信じがたい

  • 昔は128MB RAMとシングルコアCPUでも音声・ビデオ通話ができたのに、今は効率が後退したように思える

    • これは実際にはジェボンズのパラドックスの一例だ。効率が上がるほど資源消費も増える
      JSとWebの性能向上は、結局より多くの広告とコードの配布につながった
      Jevons paradox Wiki
    • もちろん昔は解像度もビットレートも低く、暗号化もなかったが、それでも今より効率的だったのは事実だ
    • 自分も32MB RAMのThinkPadで何でも問題なくやっていた記憶がある

  • WhatsAppがWebラッパー → ネイティブ → 再びWebへ戻ったのは興味深い循環だ
    ネイティブ維持コストが高いとはいえ、こんなふうに数年ごとにリライトするほうが、むしろ無駄ではないかと思う

    • 社内政治の結果かもしれない。誤った技術判断をした人が昇進しただけだ
    • Web開発者たちは、たいていの時間を依存関係の更新やフレームワーク論争（特にReact叩き）に費やしている
    • 「アプリをまた書き直さないようにしよう」と言って昇進した人は誰もいない
    • Windowsのネイティブフレームワークがあまりにもめちゃくちゃで、Microsoftでさえ使わない。
      バグや欠けている機能が多く、Chromeはこうした問題を抱えていない
    • 結局は昇進インセンティブの問題だ。うまく動いているアプリを維持しても報われない

  • 自分はよく旅行するので、複数のスマートフォンで同時にWhatsAppを使えたらいいのにと思う
    旅行用のスマホを初期化するたびにバックアップと復元が面倒だ

    • 今は最大4〜5台までインストールできる。メイン端末以外でもクライアントが独立してメッセージをやり取りできる
    • 自分はWhatsAppは使わないが、Telegramは複数デバイス間で完璧に同期される。最近はみんなTelegramを使っている
    • 初期化したスマホにはどんなアプリを入れているのか気になる

  • MetaのAIコーディングエージェントは、ネイティブアプリ1本すらまともに維持できなかったのかと思ってしまう

    • でもAIで作ったネイティブアプリでも、大して変わらなかった気がする

  • こうしたWebベースへの移行トレンドは今後も続きそうだ
    MicrosoftのNew Outlookも実質的にはWebクライアントをEXEで包んだ形だ
    そのせいでCOM Add-in、VBA、MAPI、.PSTサポートのような重要機能が失われた
    こうした流れは、もしかすると文明崩壊の兆候なのかもしれない
    関連記事: Collapse of Civilization

    • New Outlookでは検索機能がまともに動かない。自分自身に送ったメールでさえ数件しか出てこない
    • 自分たちの組織でも全員が旧Outlookのほうがはるかに良いと不満を言っている

  • Flutterは良い折衷案になれたかもしれない
    クロスプラットフォームのデスクトップアプリを効率的に作れただろうし、リソース消費もはるかに少なくできたはずだ

  • 実際にはメモリを大量に使っているのではなく、V8が予約しているだけかもしれない
    Windowsでは256MB単位で予約するため、複数プロセスがあると1GBまで確保しているように見える
    タスクマネージャーに表示されるのは実使用量ではなく、Chromiumの予約メモリだ
    WhatsAppの問題というより、Chromiumの構造的な問題だ

    • それでもそういうプラットフォームを選んだ以上、責任はある
      メモリを食うと分かっていながらElectronを選んだのは、結局彼らの判断だ
      以前のiOS版WhatsAppや2018年のWindows版と比べても機能差はほとんどないはずなのに、わざわざ作り直す理由があったのか疑問だ