iOSの設計にMVVMを使わない理由

iOS の設計に MVVM を使わない理由 YUMEMI.grow Mobile #25 宇佐見公輔 2025-11-25

自己紹介 宇佐見公輔（うさみこうすけ） • iOS テックリード 最近の執筆 •『組版ソフトウェア Typst を活用しよう』 （新刊：技書博 12 / 技術書典 19） •「パズルを解くためのコミュテーター」 （寄稿：月刊 I/O 2025 年 11 月号） iOS 関連もいずれ書く予定です。 1 / 20

今日のテーマ：iOS アプリ 開発における MVVM

iOS アプリ開発における MVVM MVVM とは • MVVM = Model-View-ViewModel • iOS アプリ開発では 10 年くらい前に人気を集めた設計 • 最近は使われなくなっている ゆめみの採用担当において • 採用課題やポートフォリオなどで、MVVM 使用事例がまだある • しかし妥当な選択とは思えない 今日のテーマ：iOS アプリ開発における MVVM 3 / 20

そこで今日の話は • なぜ iOS アプリ開発で MVVM が人気を集めたか • なぜ最近は使われなくなっているか 当時の自分自身もその流れの中にいたので、改めて振り返ります。 注意事項 • 今日の話はあくまで個人的な見解です • 事実と異なる点などあれば、ご指摘いただけると助かります • 別の見解などもあれば、参考にします 今日のテーマ：iOS アプリ開発における MVVM 4 / 20

MVVM が人気だった理由

当時の課題 MVVM が人気を集めたのは 10 年くらい前のことです。 • 当時の主流は MVC アーキテクチャ ‣ MVC = Model-View-Controller • UIKit による ViewController という概念は一定の成功をおさめた • しかし ViewController の肥大化が課題となっていた MVVM が人気だった理由 6 / 20

MVVM の登場 • MVVM はもともと Windows / C# の世界で登場した ‣ MVVM = Model-View-ViewModel • それを参考に、iOS アプリ開発者たちが MVVM を採用しだした ‣ ただし、iOS 向けにアレンジされた形になることが多かった ‣ そのため、ひとくちに MVVM といっても界隈によって話の解釈 が違ってしまうので注意 MVVM が人気だった理由 7 / 20

MVVM の利点 • ViewController からロジックを分離して ViewModel へ ‣ ViewController の肥大化の解決 • View と Model のデータバインディング ‣ RxSwift との相性の良さ • テスタビリティの向上 ‣ ViewModel の単体テストが可能 MVVM が人気だった理由 8 / 20

MVVM の問題点

ViewModel の肥大化 • ViewController の代わりに ViewModel が肥大化 ‣ ViewController の役割の一部の肩代わりはできた ‣ しかし、肥大化箇所が移動しただけで根本的な改善にはならず • ViewModel の責務が曖昧になりがち ‣ ViewController の責務が曖昧だったのと同様の問題 MVVM の問題点 10 / 20

過剰な Reactive コード • RxSwift による実装が技巧的になりがち ‣ Rx でスマートな実装ができるが、やりすぎは良くない ‣ 多くのボイラープレートが発生 • データフローが複雑化しがち ‣ 複数のストリームの結合が絡むと、複雑になりやすい MVVM の問題点 11 / 20

ViewModel のテストが複雑に • ViewModel の単体テストは、実際に書いてみると複雑 ‣ ViewModel が肥大化していることも関連 ‣ テスト用の Mock がたくさん必要 MVVM の問題点 12 / 20

ライフサイクルの扱いが複雑に • UIKit のライフサイクルは ViewController の役割 ‣ ViewModel ではライフサイクルを意識しないですむ想定 • しかし実際に書いてみると、そううまくはいかない ‣ ViewModel でもライフサイクルを意識した実装が必要になる ‣ ライフサイクルの二重管理状態に MVVM の問題点 13 / 20

SwiftUI 登場による変化

SwiftUI の登場 • MVVM は、問題点はありつつも標準的な設計のひとつ • しかし、SwiftUI の登場で話が変わってきた • MVVM の利点が、SwiftUI によって別の形で解決される SwiftUI 登場による変化 15 / 20

データバインディングの仕組みがある • データバインディングの仕組みが SwiftUI フレームワークにある ‣ Observation など • データバインディングを RxSwift に頼る必要がない ‣ サードパーティーライブラリへの依存の解消 SwiftUI 登場による変化 16 / 20

View が肥大化しにくい • ViewController や ViewModel が肥大化していたのは次の理由 ‣ 責務があいまいになりやすい ‣ データバインディングが冗長になりやすい • SwiftUI の View は責務がわかりやすい ‣ プレゼンテーションの実装に集中しやすい ‣ ロジックも書けてしまうけど、分離はしやすい • データバインディングもシンプルになった SwiftUI 登場による変化 17 / 20

ViewModel は不要に • View の肥大化の解決 • データバインディング手法の解決 これらにより、ViewModel の利点の多くが不要になり、むしろ冗長 な存在になった。 SwiftUI 時代に MVVM は適切なアーキテクチャとはいえない。 SwiftUI 登場による変化 18 / 20

ではどうするのか？

どんな設計がよいか ここでは、どれが良いかの結論は明言しないでおきます。 ただ、いったん ViewModel という考えを手放してみると良いです。 • シンプルな Model と View の構造でも十分足りる ‣ Model と View の分離は意識しておく • PointFree の TCA は解決案のひとつ ‣ ただし、これも万能ではない ではどうするのか？ 20 / 20