Jetpack Compose と SwiftUI の相互乗り入れチャンス：宣言的 UI の「共通言語」を武器にする

モバイルアプリ開発の主戦場は、完全に「宣言的 UI（Declarative UI）」にシフトしました。Android の Jetpack Compose と iOS の SwiftUI。これらは単に似ているだけでなく、設計思想の根幹が驚くほど共通しています。

「片方の OS しかやらない」のはもはやもったいない。今回は、両者の似ている点と、実際に触れてみて分かったそれぞれの強み・弱みをエンジニア視点で深掘りします。

まずは、両者がどれだけ似ているかを見てみましょう。基本的な構造はほぼ 1 対 1 で対応しています。

このように、概念さえ理解していれば、文法を「翻訳」するだけでコードが書けてしまいます。これが今、エンジニアが「相互乗り入れ」すべき最大の理由です。

いいとこ：柔軟性とロジックの書きやすさ

Kotlin の恩恵: 単なる関数（Function）なので、UI の中に if や for などの標準的なロジックを非常に自然に記述できます。
プレビューの強力さ: MultiPreview などの機能により、複数のデバイス設定やテーマを一度に確認できるのが強力です。
後方互換性: OS のバージョンに依存せず、ライブラリの更新で新機能が使える（Android 5.0+ 等）のは、ビジネスサイドから見ても大きな利点です。

わるいとこ：ビルド速度と環境構築

コンパイル時間: Kotlin Symbol Processing (KSP) や Compose コンパイラの処理により、プロジェクトが大きくなるとビルド時間が課題になりがちです。
プレビューの不安定さ: 依然として、複雑なプロジェクトではプレビューがビルドエラーで止まることがあり、ストレスを感じる場面もあります。

いいとこ：簡潔さと OS との一体感

Modifier の直感性: .padding().background().cornerRadius() とドットで繋いでいく記述（メソッドチェーン）は、Compose の Modifier よりも直感的で、記述量が少なく済みます。
プレビューの速さ: Xcode の Previews（Canvas）は、シミュレータを立ち上げ直さずにコード変更を即座に反映する「Canvas プレビュー」が非常に軽快です。
デフォルトの美しさ: 最小限のコードで「iOS らしい」アニメーションや挙動が手に入ります。

わるいとこ：OS バージョンの壁

「iOS 15 以前」の壁: 新しい SwiftUI の機能を使いたくても、サポート対象の OS バージョンによって使えないことが多々あります。これが開発者の最大の悩みどころです。
ブラックボックス: 内部実装が隠蔽されている部分が多く、標準から外れた挙動をさせようとすると、途端に難易度が上がります（Introspect などのハックが必要になることも）。

今、この両方を触るメリットは「両方のプラットフォームでアプリが作れる」ことだけではありません。

「UI 設計の抽象化」が身につく: 実装の詳細に振り回されず、「状態をどう定義し、どう UI に流し込むか」という設計の本質に集中できるようになります。
KMP (Kotlin Multiplatform) への布石: Compose を知っていれば Compose Multiplatform で iOS UI も書けますし、SwiftUI を知っていれば KMP の UI 層を SwiftUI で書く選択がスムーズになります。
Action and Simple: 複雑な理論をこねくり回すより、まずは両方の環境で簡単な Todo アプリを作ってみる。この「Action」こそが、モバイルエンジニアとしての視野を一気に広げてくれます。