出来事の日付：2026年8月2日。 AppleがSwiftUIを発表してから7年がたち、開発者のヤコフ・マンシンは、このフレームワークが本番環境向けインターフェースの予測可能な基盤というより、依然としてベータ版のように振る舞うと論じる、厳しく批判的な評価を公表した。彼の批判は、パフォーマンス、レイアウトの一貫性、変化し続けるデータフローの仕組み、そして旧バージョンのプラットフォームをサポートするために必要な作業に焦点を当てている。
SwiftUIは2019年、Appleの各プラットフォームにまたがってインターフェースを構築する労力を減らすことを目的とした宣言的モデルとして登場した。マンシンは、信頼できる唯一の情報源、組み込みのアニメーション、即時プレビュー、再利用可能なクロスプラットフォームコードなどが約束されていたと振り返る。このアプローチはまた、AppleのツールをReact NativeやFlutterなどのフレームワークに代表されるリアクティブかつ宣言的な方向性に合わせるものでもあった。
しかし、マンシンの経験では、データモデルは複雑さを増してきた。SwiftUIは`@State`、`@Binding`、監視対象オブジェクトなどのプロパティラッパーから始まり、その後Observationフレームワークと`@Observable`マクロを追加した。ビューがなぜ再描画されたのか、何回更新されたのか、あるいは関連する変更がなぜ無視されたのかを、開発者はいまだに理解できず苦労する場合があると彼は主張する。彼はこの挙動を、確実に内部を調査できるリアクティブシステムではなく、ブラックボックスだと評している。
レイアウトは2番目の大きな不満だ。SwiftUIはビュー間でサイズを調整する方式を採用しているが、フローティングビューやカスタムサイドバーなどの標準的でないコンポーネントでは制御が難しくなるとマンシンは述べている。彼はApple自身のチュートリアルプロジェクトを例に挙げ、最新のXcodeでビルドし、最新のmacOS上で実行すると、その標準サイドバーが正しく描画されないと主張する。この問題は2年以上続いているという。
マンシンはまた、高機能なアプリケーションであるUTMでさえ、そのSwiftUIインターフェースが初期段階のプロトタイプのように見える場合があると指摘している。彼の説明によれば、レイアウトが予期しない形で機能しなくなると、開発者はしばしば`GeometryReader`のラッパーやその他の回避策に頼る。これらの例は、ある実務者によるレビューでの所見であり、SwiftUIアプリケーション全体の不具合発生率を立証する独立した測定結果ではない。
この批判は、そうした技術的問題を、より広い競争の歴史の中に位置付けている。企業がウェブとモバイルで共有するコードベースをますます検討するようになる中、Appleには、より取り組みやすいクロスプラットフォーム向けインターフェースフレームワークが必要だったとマンシンは主張する。またSwiftUIには、ブラウザーアプリケーションやElectronベースのラッパーではなく、Macネイティブのソフトウェアを増やすよう促す意図があったとも示唆している。これらの説明は、Appleの戦略についての彼の解釈である。
マンシンの報告は、SwiftUIに有用な機能がないと主張するものではない。状態の変化やレイアウトの結果を予測しにくければ、利便性が損なわれるという主張だ。したがってエンジニアリングチームにとっての実務的な問題は、宣言的な構文によって単にサンプルが短くなるかどうかではなく、選択したSwiftUIの設計が、製品でサポートしなければならない各OSバージョンにわたって、安定し、説明可能で、保守可能な状態を維持できるかどうかである。
