ハクソク

世界を動かす技術を、日本語で。

Windowsネイティブアプリ開発は混乱しています

2026年3月22日原文(domenic.me)

概要

  • 著者は 長年Windowsユーザー として開発経験を重ねてきた経緯を持つ
  • Display Blackout というユーティリティを開発し、現代Windowsアプリ開発の難しさを体感
  • UIフレームワークや配布方式の 複雑な進化 と混乱を指摘
  • P/Invoke など旧APIとの相互運用が依然として不可避である現状
  • Microsoftの開発エコシステムの課題 と、その影響について考察

Windowsアプリ開発の現状と混乱

  • 著者は 幼少期からWindowsとVisual C++ に親しみ、.NETの登場も体験
  • 初就職先も.NET系 だったが、プロとしてネイティブWindowsアプリは未経験
  • 趣味では Web開発を選択 しがちで、Windowsアプリは思い出補正が大きい
  • Display Blackout はゲーム時に左右モニターを黒くするユーティリティ
    • 既存のAutoHotkeyやMicrosoft Storeアプリの類似機能も存在
    • 著者は よりモダンなUIと学習目的 で独自実装を選択
  • 必要要件：
    • ディスプレイ情報の取得
    • 枠無し・非アクティブ黒ウィンドウの配置
    • グローバルショートカットの取得
    • スタートアップ起動オプション
    • 永続設定の保存
    • トレイアイコンとメニュー表示

Windows UIフレームワークの歴史

  • Win32 API（C言語） が出発点で、今も現役
  • MFC（C++） によるオブジェクト指向ラッパーの登場
  • .NETとC# による新時代の幕開け
    • Windows Forms ：Win32のラッパー
    • WPF （.NET 3.0）：XAMLによる宣言的UI、GPU描画
  • Windows 8/10のWinRT・UWP
    • サンドボックス型・クロスデバイス対応
    • 一部OS機能はUWP/WinRT専用
    • Windows App SDK/WinUI 3 で再統合を目指すも混乱継続
  • UI進化の流れ：
    • Win32 → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

開発手法の選択肢と課題

  • WinUI 3 + Windows App SDK が推奨だが、実装方法が三択
    • C++ ：軽量だがメモリ安全性に課題
    • C#/XAML（フレームワーク依存） ：.NETの最新バージョンがOSに標準搭載されておらず、配布時にユーザーへ追加インストールを強要
    • .NET AOT ：ランタイムごとバイナリ化、9MiB超の肥大化
  • Rust対応 も頓挫
  • 配布形式 も混乱
    • MSIX 推奨だが、コード署名証明書が高額（$200～$300/年）
    • 未署名配布 はユーザー体験が劣悪
    • Microsoft Store も独自価値がないとリジェクト
  • .NETの配布やMSIXの依存関係管理 が十分に整備されていない

旧APIとの相互運用とその限界

  • 新APIだけでは機能が不足
    • 例：ディスプレイ監視やグローバルホットキー取得はP/Invoke必須
    • トレイアイコンやコンテキストメニュー も標準化されていない
  • UI自動リサイズ機能 などもフレームワーク進化の過程で消失
  • P/Invoke技術自体も過渡期
    • CsWin32 など新しいラッパーツールも未成熟
    • C#言語仕様の限界も露呈
  • 最新フレームワーク採用の意義が薄れる現状

Microsoft開発エコシステムの課題

  • 頻繁なフレームワーク刷新 による技術的負債の蓄積
  • サンドボックス化や機能制限 による開発者体験の悪化
  • C#とWindows APIの親和性不足
  • Electron等Web技術への流出 の背景
  • 根本的な改善策の不足 と「中途半端」な現状

このように、著者は モダンWindowsアプリ開発の現実 を実体験を通じて詳細に分析し、 Microsoftのエコシステム全体の課題 を浮き彫りにしています。

Hackerたちの意見

俺が見る限り、ほとんどの開発者もそうだと思う。Hacker Newsのコメント欄では、ネイティブアプリの死を嘆く声が多いけど、Windowsアプリプラットフォームの混乱を考えると、俺はウェブスタックを選ぶよ。ElectronやTauriを使って、OS統合のために必要なWin32 APIに繋げるしね。ユーザーとしては、パフォーマンスの面でネイティブアプリが好きだけど、この記事が示すように、ネイティブアプリの開発は明らかに混乱してる。でも、ユーザーとしてはその問題は感じないかな。ただ、アプリがどんどんひどくなってるのは感じる。新しいOutlookやTeamsの完全な混乱っぷりとかね。

└

マイクロソフト自身がElectronを使ってアプリを開発してるのに、他の開発者に何を期待できるんだろう？

└

Electronの話だけど、自分の小さなツールにはTypeScript+BunとElectrobunを使ってるよ。https://github.com/blackboardsh/electrobun

└

新しいOutlookとTeamsが混乱してるのは皮肉だね。だって、あれはネイティブアプリじゃなくてウェブアプリだから。ウェブアプリは、ちゃんとしたネイティブの見た目や感触をエミュレートするのが難しくて、フォーカスやキーストロークナビゲーションに関して変な問題がよく起こるんだ。Javaアプリのダメな問題はそのままで、Javaじゃない以外の改善もなく、しかも遅くてメモリを多く使うしね！

俺は組み込みプログラマーで、たまに組み込みデバイスとインターフェースするためにWindowsプログラムを書く必要があるんだけど、純粋なWin32とC++でネイティブGUIプログラムを書くのは楽勝だよ。最近、XP時代に最後に更新された古いプログラムに新機能を追加しなきゃいけなかったんだけど、2つのポイントがある。1. プログラムはVista、7、10、11で動くように更新する必要がなかった。ずっと動き続けてたんだ。2. プロジェクトをVisual Studio 2022に読み込んだら、VC6から変換されて問題なくコンパイルできたし、新機能を追加して新しい.exeを顧客に送ったら、そのまま動いた。他のプラットフォームにこんな互換性の成功ストーリーがある？

└

Winforms？まだ彼らがベストオプションだなんて笑っちゃう。置き換えようとする努力が無駄すぎる。

└

大きなレガシーWin32/C++コードベースでの一番の課題は、32ビットから64ビットに完全に移行することだね。複雑なGUIコントロールや構造体に関するノウハウやドキュメントが失われてるか、ほんとにバラバラになってる。それ以外は、そこを乗り越えれば、ほんとに全部うまくいくよ。

└

どう見えるの？ウィジェットはどんな感じ？

└

俺にとって、この「何も変える必要がない」っていうのは安定性を示唆してるけど、週ごとに何かが変わるのに慣れてる若い開発者たちがいて、1週間以上古いものは「メンテされてない」って思ってバグだらけだと考えてるんだよね。

└

俺は、世界で唯一「エレガント」や「よく構造化された」Cocoaコードベースに触れるくらいなら、醜いWin32のジャンクを書く方がいいと思ってる気がする。Win32ではボタンが欲しいときは関数を呼んでハンドルを渡すだけだけど、Appleの世界ではまず7つのインターフェースをサブクラス化して、読みづらいSmalltalk風の構文で書かなきゃいけなくて、ドキュメントにアクセスしないことを祈るしかない。そしてもちろん、彼らは常に何かを変えるから、後方互換性を壊すのがAppleの趣味なんだよね。

└

APIによって文字列を定義する方法が12通りもあるんだって。

└

それ、あんまりうまくいかないこともあるよね。運が良かったんじゃない？高DPIを加えると、すぐに厳しくなるし。あと、共通コントロールには変な入力の問題があるよ（Editコントロールでctrl+backspaceを試してみて）。2026年に何かをちゃんと動かすためには、そういう小さな問題を丁寧に修正する必要があるよ。

Hacker Newsで議論の続きを見る