SwiftUI 7年後：凡庸さの物語

2019年の発表から7年、SwiftUIはAppleプラットフォーム向けのクロスプラットフォームUI開発における、成熟したプロダクショングレードの未来となることが期待されていました。しかし、現在多くのシニアエンジニアは、それを精密なエンジニアリングを利便性の錯覚と引き換えにした、永続的なベータ状態にあるフレームワークと見なしています。

予測不可能なデータフローとリアクティビティ

SwiftUIのデータフローは、予測可能な動作を実現することがほぼ不可能な「ブラックボックス」として特徴付けられています。「単一の真実のソース（single source of truth）」という概念は、理論上は魅力的ですが、その実装はプロパティラッパーとマクロの混乱した配列へと進化してしまいました。

  • 状態管理の進化: フレームワークは @State、@Binding、ObservedObject で始まりました。パフォーマンスの問題と過剰な再レンダリングのため、Appleは Observation framework と @Observable マクロを導入しました。
  • 透明性の欠如: 開発者は、Self._printChanges() のような未公開のデバッグAPIを使用しても、ビューが正確に何回更新されるのか、あるいはなぜ特定の更新がトリガーされたのかを知ることがしばしば不可能であると報告しています。

レイアウトエンジンの脆弱性と GeometryReader の罠

サイズ交渉に基づくSwiftUIのレイアウトシステムは、特にカスタムサイドバーやフローティングビューのような複雑なインターフェースを構築する際、予測不能で脆弱であるとしばしば記述されます。

  • レイアウトの一貫性の欠如: Apple自身のチュートリアルでさえ、最新のmacOSバージョンで実行した際にレイアウトが崩れることが指摘されています。
  • GeometryReader による回避策: 宣言的なシステムが機能しないとき、開発者は座標を計算するために GeometryReader に頼らざるを得ないことがよくあります。これは、宣言的な利点を排除し、レガシーな Auto Layout システムよりも冗長性を増大させるため、「敗北の承認」と見なされます。

API の不安定さと機能の格差

SwiftUIは、UIKit や AppKit といったレガシーフレームワークと比較して、機能の同等性を維持することに苦戦し続けています。これにより、コードベースは、後方互換性を維持するための if #available チェックで埋め尽くされることになりました。

  • 機能実装の遅れ: スクロール時のキーボード非表示（iOS 16）や AsyncImage によるネットワーク画像の表示（iOS 15）といった基本的な機能が、レガシーフレームワークに数十年前から存在していたにもかかわらず、SwiftUIに導入されるまでには数年を要しました。
  • コンポーネントの置き換え: バグのあるコンポーネントを修正するのではなく、Appleは時折、それらを完全に置き換えることがあります（例：NavigationView を NavigationStack に置き換える）。これにより、開発者は異なるOSバージョンに対して個別のコードブランチを維持することを余儀なくされます。
  • キャッシュの制限: 2026年7月現在、画像キャッシュのための特定の重要なAPIはベータ版のままであり、開発者はカスタムのフェッチャーやキャッシュ層を構築する必要があります。

パフォーマンスの格差

直接比較を行うと、SwiftUIのパフォーマンスは、特にデータ量の多いビューにおいて、UIKitに遅れをとることが多いことが示唆されています。

  • スクロールのパフォーマンス: シンプルな画像ギャラリーや大きなグリッドにおいて、SwiftUIはハイエンドなハードウェア上であっても、UIKitの対応物と比較して滑らかさに欠けることがよくあります。
  • 最適化のオーバーヘッド: 受容可能なパフォーマンスを実現するには、しばしば難解な最適化の秘訣が必要となり、これはフレームワークの「シンプルさ」という約束に矛盾しています。

「一度学べば、どこでも使える」という神話

AppleはSwiftUIを「一度これらのツールを学べば、どこでも適用できる」方法としてマーケティングしていますが、現実は、6インチのスマートフォン向けのUIデザインは、27インチのデスクトップとは根本的に異なります。

  • プラットフォーム間の乖離: iOS向けに学んだ概念は、iPadアプリを移植したような「異質な」UIをもたらすことなく、macOSのレイアウトに直接適用できることは稀です。
  • 実装の一貫性の欠如: 同じビューがAppleの異なるプラットフォーム間で一貫性のない実装を持つことが多く、それがデバッグ作業の多いワークフローを生み出しています。「一度学んで、二度学び、どこかへ適用し、あらゆるところでデバッグする」という状態です。

「十分なほど良い」への哲学的な転換

SwiftUIは、Appleにおける妥協のない職人技から、「速度」と「十分なほど良い」製品へと向かうシステム的な転換を象徴しているのではないかという懸念が高まっています。

  • バグの常態化: この転換は、Apple Music のキューのジャンプ、ホーム画面のアイコンの重複、Logic Pro のローカライズ不足といった、Apple純正アプリにおける持続的なバグによって裏付けられています。

  • レガシー時代との比較: これは、初期の Cocoa や Aqua の時代とは対照的です。当時は、そのような視覚的な不具合や不安定さは、受け入れられないものと見なされていました。

コミュニティの視点と反論論点

開発者同士の議論では、SwiftUIを失敗と見なすか、それとも不完全ながらも強力なツールと見なすかで見解が分かれています。

"SwiftUIは、簡単なことはより簡単に、難しいことはより難しくするタイプのフレームワークです。初心者向けの罠です。"

"SwiftUIを大きなパフォーマンス問題なしで使用してきました... プロファイリングと必要に応じた修正を行っています。私が以前働いていたスタジオの一つでは、プロトタイプとしてすべてのゲームをUIKitで書いていました... パフォーマンスが低下したときは、適切なツールに切り換えるという形でした。"

"SwiftUIは、仕事の90%において非常に有用ですが、残りの10%ではAppKitが必要です。私のアプリでは... リストに大量のチャットアイテムを表示・ロードするためにSwiftUIを使いましたが、それは本当に苦手です。"

一部の開発者は、この不満は「UIKit への固執」というメンタリティから生じているものであり、単純なアプリであれば、SwiftUIはボイラープレートの多いレガシーフレームワークよりも大幅に生産性が高いと主張しています。

Sources