1. SwiftUIは「UIKitの代替」ではなく「抽象レイヤー」

SwiftUIはしばしばUIKitの後継として語られますが、構造的にはまったく別の位置にあります。

SwiftUIのViewは struct であり、それ自体は描画もイベント処理も行いません。

実際に起きているのは以下の流れです。

1. SwiftUI Viewが状態から生成される
2. 内部で差分が計算される
3. UIKitのView階層へ反映される

つまりSwiftUIはUIKitを操作するための記述DSLであり、UIKitを置き換えてはいません。

2. View再生成モデルが設計にもたらす実際の制約

SwiftUIでは、Viewは「保持されるもの」ではなく「評価されるもの」です。

このモデルがもたらす現実的な影響は大きく、

・Viewのライフサイクルが明示できない

・初期化が何度呼ばれるか保証されない

・再生成コストを正確に見積もれない

という状態になります。

UIKitではViewの生存期間が明確だったため、

・いつ生成され

・いつ破棄され

・どこで状態を持つか

を設計で固定できました。

SwiftUIではこの前提が崩れるため、設計可能な領域が意図的に狭められていると言えます。

3. 差分計算とレイアウト責任は誰が持っているのか

SwiftUIは状態変更時に差分更新を行いますが、

・差分の粒度

・再描画の境界

・レイアウト再計算の範囲

これらは公開されていません。

結果として、

・パフォーマンス劣化の原因が追えない

・あるOSでは問題が出て、別のOSでは出ない

・回避策が存在しない

という状況が発生します。

UIKitでは、レイアウトと描画の責任が明確に分かれていたため、問題の切り分けが可能でした。

4. イベント・ライフサイクルは今もUIKitの領域

iOSのUIイベントは現在もUIKitが管理しています。

・タッチイベント

・レスポンダチェーン

・ViewControllerのライフサイクル

・画面回転・マルチタスク対応

SwiftUIはこれらを直接制御できません。必要になった瞬間に、UIKitへ戻るしかありません。

これは「未成熟」ではなく、設計上の意図的な制限です。

5. UIHostingControllerが示す構造的な限界

SwiftUIの画面は、必ずUIHostingControllerに包まれます。

これは非常に重要な事実です。

・SwiftUIは画面管理を担えない

・UIViewControllerモデルが前提

・ナビゲーションの最終責任はUIKit

つまりSwiftUIは、UIの中身しか担当していない。

この構造が変わらない限り、UIKitが不要になることはありません。

6. OSアップデートと長期運用で露呈する差

長期運用されるアプリでは、OSアップデート直後の挙動が致命的になります。

• UIKit：過去事例が多く、回避策が見つかる
• SwiftUI：内部実装変更の影響を直接受ける

SwiftUIは抽象度が高い分、不具合が起きたときに「何もできない」ケースが存在します。

7. 他言語UIフレームワークと比較して見える本質

共通点はすべて、制御を捨てて生産性を取る設計です。

SwiftUIだけが特殊なのではなく、その代償がiOSでは特に目立つ、というだけです。

SwiftUI時代とは、UIKitが不要になる時代ではありません。SwiftUIはUI表現を高速に記述するための抽象レイヤーであり、イベント処理やライフサイクル管理といった責任は今もUIKitが担っています。現場でSwiftUIを使うという判断は、「UIKitを理解した上で、制御をどこまで手放すか」を選ぶ行為です。この前提を共有できたとき、SwiftUIは初めて安全に使える技術になります。