【ITニュース解説】How I Mastered SwiftUI After Years of Jetpack Compose: Tips for Android Devs

Android開発の経験を持つエンジニアが、Jetpack Composeでの知識を活かしてAppleのUIフレームワークであるSwiftUIを習得した過程が示されている。長年Androidアプリ開発に携わり、XMLレイアウトからJetpack Composeへの移行を経験してきた筆者は、UI開発に関して深い理解を持っていた。Jetpack Composeは、UIの見た目を記述し、データ（状態）の変化に応じて自動的に更新される「宣言型UI」という考え方でAndroidアプリ開発に革新をもたらし、再利用可能な部品（コンポーザブル関数）やデータの変化にリアルタイムで対応する仕組みを提供した。

しかし、クライアントからのクロスプラットフォームアプリ開発の要望をきっかけに、筆者はSwiftUIの学習を決意した。SwiftUIもまた宣言型UIであり、部品ベースで構築される点でComposeと多くの共通点があると感じたが、実際に学習を進める中でApple独自の思想や細かな違いに直面した。単にiOSアプリを作れるようになるだけでなく、iOS開発者として思考できるようになることを目標に、半年間かけて複数のプロジェクトを構築し、公式ドキュメントを読み込み、試行錯誤を繰り返したという。

SwiftUIとJetpack Composeは、どちらもUIの見た目を記述する宣言型UIのフレームワークである点で共通している。Composeでは「@Composable」という特別なアノテーションを付けた関数でUIを記述し、SwiftUIでは「View」というプロトコルに準拠した構造体でUIを定義する。どちらもデータ（状態）が変化すると、手動でUIを更新することなく、自動的にUIが再描画される仕組みを持つ。しかし、ComposeがKotlin言語と非同期処理にコルーチンやFlowを使用するのに対し、SwiftUIはSwift言語とasync/await、Combineフレームワークを使用するといった違いがある。また、Composeはサードパーティライブラリとの連携が柔軟である一方、SwiftUIはAppleのエコシステムに深く統合され、より厳密な設計思想を持つ。簡単なボタンの例を見ると、両者とも軽量で部品化しやすいが、SwiftUIのViewは必ず一つの「body」プロパティを持ち、その中にUIの構造を記述する必要があるという特徴がある。Composeでは複数のUI要素を直接並べられる場合もあり、より柔軟だが、時に複雑な構造になり得る。

学習における大きな課題の一つは、UIのレイアウト（配置）と修飾子（見た目の調整）の考え方の違いだった。Composeでは「Row（横並び）」「Column（縦並び）」「Box（重ね合わせ）」といったUI部品を使って配置を決定し、その部品に対して「.padding（余白）」「.background（背景色）」といった修飾子をチェーンのように連結して適用する。SwiftUIでも「HStack（横並び）」「VStack（縦並び）」「ZStack（重ね合わせ）」といったスタックコンポーネントが同様の役割を果たすが、修飾子はビューそのものに適用される。どちらのフレームワークでも修飾子の適用順序は重要だが、初期の学習ではこの違いが混乱を招いたという。例えば、Composeの.fillMaxSize()と.align(Alignment.Center)を組み合わせて要素を中央に配置するのに対し、SwiftUIでは.frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center)のように、.frame修飾子一つでサイズと配置をまとめて指定できる点など、異なるアプローチがある。

もう一つの大きな課題は、UIのデータ管理、つまり「状態管理」だった。宣言型UIの核となるこの部分で、Composeの知識が役立つと同時に、SwiftUIとの違いに戸惑う原因にもなった。Composeでは「@State」や「remember」「MutableState」を使って局所的な状態を管理し、共有する状態にはViewModelとLiveDataやStateFlowを使う。SwiftUIでは、局所的な状態には「@State」、親から子へ状態を渡すには「@Binding」、さらに複雑なモデルの状態には「@ObservedObject」や「@StateObject」、そして新しい「@observable」マクロを使用する。Android開発者がComposeのViewModelを直接SwiftUIに当てはめようとすると、かえって複雑にしてしまうことがある。SwiftUIには「@EnvironmentObject」という仕組みがあり、ComposeのCompositionLocalのように、複数のビューをまたいで状態を共有できるため、手動で状態をバケツリレーのように渡す手間を省くことができる。カウンターの例では、Composeが変数とrememberを使って状態を保持し、SwiftUIでは@Stateプロパティラッパーを使って状態を宣言する記述方法が比較されている。アプリ全体の状態管理やデータの永続化については、ComposeがRoomとViewModelを組み合わせるのに対し、SwiftUIはSwiftDataやCore Dataと連携したり、「@AppStorage」で簡単なデータの保存を行うことが可能である。

開発効率を大きく高めるツールとして、両フレームワークに共通して「プレビュー機能」が挙げられる。Android StudioのCompose Previewは、コンポーザブル関数を即座にレンダリングし、複数の設定でUIの確認ができる。XcodeのSwiftUI Previewも同様に、コードを記述しながらリアルタイムでUIの変更を確認できる。Xcodeのプレビューは、特にUIコンポーネントをコードと同時に確認しながら開発を進める際に非常に役立つ。

これらの学びを定着させるため、筆者はToDoリストアプリを両フレームワークで構築した。タスクの表示、追加、完了チェック、データ永続化という基本的な要件を実装することで、実践的な違いを理解した。リスト表示については、ComposeのLazyColumnが柔軟なカスタムアイテムに対応する一方、SwiftUIのListはセクション分けや編集機能が組み込まれている点が挙げられる。また、テキスト入力フィールドのデータバインディングや、チェックボックスのトグル処理など、細かい実装の違いを通して、両者のアプローチを比較し、最終的にはどちらのフレームワークでも効率的にプロトタイプを作成できるようになった。データ永続化に関しても、ComposeのRoomとSwiftUIのSwiftData/Core Dataというそれぞれのプラットフォームに最適化された仕組みがある。

学習を加速させるために役立ったツールも紹介されている。Xcodeの拡張機能である「SwiftUI Inspector」は、ComposeのLayout Inspectorのように、ビューの階層や修飾子、フレームサイズなどをライブで確認できるため、レイアウトの問題解決に大きく貢献した。さらに、Reveal appのようなツールも深いデバッグに活用された。公式ドキュメントに加え、Point-FreeやHacking with Swiftといった外部のリソースも、高度なトピックの理解に役立ったという。

基本的な理解が進むと、アニメーション、ナビゲーション、パフォーマンス最適化といった高度なトピックに取り組んだ。Composeのanimate*AsStateのような明示的なアニメーション制御に対し、SwiftUIでは.animation(.default)を適用すると状態変化に合わせて自動的にアニメーションが適用される。ナビゲーションも、ComposeのNavControllerとSwiftUIのNavigationStackで、それぞれ宣言的に画面遷移を定義する。パフォーマンスに関しては、XcodeのInstrumentsやAndroid StudioのProfilerといったツールで、それぞれのフレームワークにおけるUIの再描画やメモリ使用量を詳細に分析できる。また、Android開発者がSwiftUIに取り組む上で、Swiftのオプショナル型やEnum（列挙型）のようなAppleの慣習を積極的に受け入れることで、よりスムーズな学習が可能となるという。RedditやStack Overflowなどのコミュニティも、疑問解決の重要な資源となった。

最終的に、Jetpack Composeの経験はSwiftUIの学習を加速させたが、モディファイア、状態管理、プレビュー機能といった核となる部分に焦点を当て、実践的なプロジェクトを構築することが習得の鍵となった。これらのヒントを活用すれば、Android開発者もSwiftUIへの移行をよりスムーズに進め、クロスプラットフォーム思考のエンジニアとしての能力を向上させることができるだろう。