ハクソク

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

7年後のSwiftUI

2026年8月3日原文(ykvm.com)

概要

  • SwiftUI は2019年の発表から7年経っても 成熟したUIフレームワーク になっていない現状
  • パフォーマンス や レイアウト予測性 の問題が解決されず、開発者の フラストレーション が増大
  • データフロー や APIの非互換性 によるワークアラウンド地獄
  • Apple公式チュートリアルや現場アプリでの 具体的な問題事例
  • Appleの開発姿勢の変化に対する 業界全体の懸念

SwiftUIの現状と開発者の失望

  • 2019年発表 時の期待と現実のギャップ
  • 宣伝された利点 （宣言的構文・単一ソース・アニメーション・クロスプラットフォーム）の未達成
  • Auto Layout からの解放という約束は実現せず
  • 7年経過 しても「若いフレームワーク」という言い訳は通用しない現状
  • バグやレイアウト崩壊 が頻発するため、現場では言い訳や回避策に追われる日々

SwiftUI登場の背景

  • React・Flutter など競合の台頭によるAppleの危機感
  • ネイティブ開発離れ や Mac App Store の低迷への対応策
  • 開発者囲い込み と 移植性向上 がSwiftUIの狙い
  • リアクティブなデータフロー と 宣言的UI がセールスポイント

SwiftUIのデータフロー問題

  • @State, @Binding, ObservedObject から Observationフレームワーク と @Observableマクロ への変遷
  • パフォーマンス問題 や 再描画の予測不能性 が解決しない現実
  • ブラックボックス化 したリアクティブ性
  • ドキュメント非公開API を使っても全容把握困難
  • 意図しない再描画 や 無視される変更 による予測不能な挙動

SwiftUIのレイアウトシステムの課題

  • サイズ交渉 ベースのレイアウトエンジンによる 不安定なUI配置
  • GeometryReader 多用による宣言的記述の放棄
  • バージョンアップごとの座標計算やり直し の苦行
  • Apple公式チュートリアル ですらバグが残る現状
  • 生産アプリ （例：UTM）でもSwiftUI依存部分が脆弱

APIの安定性と機能パリティの欠如

  • if #available の乱用によるコードの複雑化
  • 基本機能の遅すぎる実装 （例：AsyncImageやツールバーカスタマイズ）
  • NavigationView のバグ放置と NavigationStack への置き換えによる混乱
  • APIの頻繁な変更 で複数バージョン対応が必須
  • Jetpack Compose のようなAndroid的後方互換性の欠如
  • AppleのQA作業を開発者が肩代わり する現状

SwiftUIのパフォーマンス問題

  • 最新ハードウェア 前提のデモと現実の乖離
  • UIKitとの比較 でSwiftUIが一貫して劣る事例
  • 古いiPhone での画像ギャラリー表示で顕著なパフォーマンス低下
  • パフォーマンスチューニング必須 で初期の「手軽さ」が消失
  • 高性能チップ依存 の設計は本質的な品質問題

クロスプラットフォーム対応の神話

  • 宣伝されたクロスプラットフォーム性 の実態と限界
  • iOS・macOS間の移植の難しさ や細かな差異
  • 本質的な一貫性の欠如

Appleの開発文化の変化

  • CocoaやAqua時代 の職人精神から 「十分良い」プロダクト 志向への転換
  • 品質よりもスピードや話題性重視 の現状
  • 開発者がAppleの未完成品を補完 する構図
  • 現場エンジニアのモチベーション低下

まとめ

  • SwiftUI は依然として 本番運用レベルに達していない 現実
  • パフォーマンス・レイアウト・API安定性 の課題が山積
  • Appleの開発姿勢 に対する業界の不信感
  • 現場の開発者 が被るコストと負担の増加
  • 根本的な改善や方向転換 が求められる状況

Hackerたちの意見

複雑なシステムの問題は、自分が死んでいることに気づく前に、すでに死んでいる可能性があることだよね。過去の良い決断や構築されたインフラのおかげで、しばらくの間「結構いい感じ」に見えることがある。ちょっとしたほころびや亀裂は見えるけど、根本的には大丈夫そうに見える。だけど、そうじゃなくなるまで気づかない。Appleが前のUIフレームワークよりも優れた新しいものを展開できないのは心配だよ。ToolboxからCarbon、Cocoaに移行した会社なのに、どれも前のものより良かったのに。もしMacOS XやCocoaが今存在しなかったら、Appleはそれを作れるのかな？MicrosoftがWin32の真の後継を20年も出せていないのを見ると、Microsoft（少なくともOS部門）はずっと前に死んでしまったのかもしれない。10年後にAppleについても同じことを言うことになるのかな。

└

主な問題は関数型アプローチだと思う。状態に関する関数型アプローチはかなりエレガントだけど、結局コンピュータは関数型では動かないんだよね。パフォーマンスを少し上げるために多くのプラミングを実装しなきゃいけない（Clojureみたいに）、あるいは本質的には普通の状態マシンの上に関数型のベールをかける（Emacsみたいに）必要がある。Reactはうまく機能するけど、実際のDOMの抽象化に過ぎない。Reactはアプリの状態だけを扱う。でもDOMのメカニズムはまだ非常にパフォーマンスが良く、命令型なんだよね。だから、Reactのようなものはモバイルアプリではうまくいかないと思う。iOSやmacOSではUIツリーが非常にシンプルなことが多いから。

└

SwiftUIの問題は、ある意味でCocoaがあまりにも良すぎたことだと思う。少なくとも私の意見では、置き換える必要はなくて、改善するだけでよかったんだよね。でもAppleは若いウェブ開発者にアピールしたかったのか、彼らが慣れているものに近いものを提供しようとした気がする。

└

iPhone 17を見れば、Appleはもう終わってるってわかるよ。

└

複雑なだけじゃなくて、他の理由で「成功している」こともあるよね。そしてもちろん、Appleの場合、RDFは特に強い。これらは相互に関連していて、過去に成功したのはフィードバックや外部のアドバイスを無視していたからだけじゃなく、しばしばそれが理由でもあった。

└

AppleはMacOS XとCocoaを今日作れるのかな？もしそれらが存在しなかったら。Appleはずっと前にNeXTの人たちを追い出しちゃったし、Tim CookがScott Forstallを裏切ったから、答えはノーだね。

└

Swift UIはリリースから7年、Swiftは12年。これは7年の開発じゃなくて、リリースからの7〜12年だよね。ほとんどの人にとって、この7〜12年は進行中のベータ開発みたいなもん。未完成で、磨かれてなくて、終わりが見えない。最初からずっと批判的だったけど、問題はもっと深いんだ。技術が問題なわけじゃないし、開発者が作ってるわけでもない。最初からこれが許可された理由を決めた人が問題なんだよね。なぜこれがリリースされたのか、もっと言えば、なぜこれらのアイデアの開発にリソースが使われたのか。全ての「はい」の裏には千の「いいえ」がある。Appleのソフトウェア開発は、履歴書やKPIボーナスを狙った開発に要約できる。GoogleやMicrosoftほどひどくはないけど、Appleにもこの問題があるのは明らかだよね。ジョブズ時代のAppleのソフトウェアを振り返ると、（ソフトウェアだけじゃなくて）Appleはほとんどのことを半分のリソースで2倍良くやってた。今のAppleは膨れ上がってる。なのに、みんなクレイグ・フェデリギを称賛してるのが面白い。これらの7〜12年のほとんどの間、HNやTwitterで非常に懐疑的だったのは私だけだったから、SwiftやSwift UIの開発者たちのネガティブな感情が出る前に、書くのをやめちゃった。毎回同じ質問をしてたんだよね、もし彼らがCやObjective-C、Cocoaを改善するためにリソースの1/5を使ったらどうなるんだろうって。Swiftやそれに関連する全てのリソースは、他のところにもっと良く使われたはずだ。ジョン・ターナスに高い期待を持ってるけど、彼が政治的なゲームをうまくやって、Appleのソフトウェアの方向性を変えてくれることを願ってる。

└

10年後にAppleについても同じことを言うのかな。10年待つ必要はないと思う、今日言えるよ。

└

根本的な問題は、プログラミング業界がObjective-Cの教訓を学ぶことに完全に抵抗していることだよ。 「NeXTがそれを売ろうとしたときも嫌がってたし、今もそうだ。CocoaはObj-Cなしでは成り立たないし、少なくともその哲学を持った言語とランタイムが必要なんだ。Appleのソフトウェアは長い間明らかに衰退していて、ほぼ完全にApple Siliconの成功と、Microsoftがどうにかさらにひどくなったことで支えられている。」

└

ObjCの問題は主に構文で、Cのコアの上に何年もかけてボルトで固定されてきたものだ。 「設計されたのではなく、成長してきたもので、それが見える。でもランタイム自体には問題はない。Swiftはその同じランタイムの上に大幅に改善された構文であるべきだった。そうすれば、たくさんの頭痛を避けられたはずだ。例えば、戻り値のオーバーロードを持つというひどい決定を下して、型チェックのパフォーマンスを完全に台無しにすることもなかっただろう。SwiftUIは、UIKitやAppKitの上に便利でリアクティブなラッパーであるべきだったのに、開発者がどうしても落ち込まざるを得ないような非推奨の実装詳細として扱われている。これらの決定は、自分のレガシーを切り開こうとするエゴに起因している。昇進を望むならいいけど、開発者が構築するための長続きするエコシステムを作ろうとしているなら、あまり良くない。少なくともSwiftとSwiftUIは過去との相互運用性のストーリーがある。MicrosoftのUIフレームワークの墓場については同じことは言えない。」

みんなが反対するかもしれないけど、純粋な宣言型リアクティブが万能なネイティブUIフレームワークの「正しい」形だとは思えない。私の経験では、Kotlin+Composeも同じような欠点が多い…主な利点は、Android Framework（ほとんどの場合）よりはマシってことだけど、それはクリアするのが簡単なハードルだよね。このフレームワークにはいくつかの良いアイデアがあるけど、必ずしも高品質な従来の命令型フレームワークを超えるようには組み合わさっていないと思う、特に複雑なアプリに関しては。SwiftUIやその類は、超シンプルなタブやフラットリストのアプリには最適だけどね。

└

オープンソースが正しい選択だと思う。Flutterの素晴らしいところは、宣言型UIで多くの標準画面を簡単に作れるけど、常に低レベルに降りて、標準コンポーネントを調べたり、自分の実装と組み合わせたりできるところだよね。UIKitとSwiftUIを混ぜることもできるけど、SDKのクローズドな性質のせいで、かなりの摩擦がある。

Hacker Newsで議論の続きを見る