LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

UIKitとSwiftUIの違い — 命令的UIと宣言的UIが分ける開発パラダイム

UIKitからSwiftUIへの移行外注とは、既存のiOSアプリをUIKit（命令的UIフレームワーク）で構築された状態から、SwiftUI（宣言的UIフレームワーク）へ段階的または全面的に書き換える開発作業を、外部の開発パートナーに委託する取り組みを指します。

UIKitはiOS 2.0（2008年）から使われてきた命令的UIフレームワークです。「ボタンをタップしたらこの処理を実行する」「ラベルのテキストをこの値に書き換える」というように、画面状態の変更手順をコードで逐一記述します。

SwiftUIはAppleが2019年のWWDCで発表した宣言的UIフレームワークです。「データがこの状態のとき、画面はこう表示される」という状態と表示の対応関係を宣言するだけでUIを構築できます。iOS 13以降で動作し、Appleは現在もSwiftUIへの機能追加を継続しています。

命令的と宣言的の違いは、開発者の思考方法そのものを変えます。UIKitではView Controllerが画面の状態管理・ライフサイクル管理・レイアウト指示をすべて担います。SwiftUIでは状態（@State・@ObservedObject・@EnvironmentObjectなど）とビューを分離し、状態が変わればビューが自動再描画されます。

移行を判断する3つの理由：保守性・開発速度・Appleの方向性

UIKitで動いているiOSアプリをSwiftUIへ移行するかどうかは、3つの観点から判断できます。

1つ目は保守性の向上です。UIKitの画面は、View Controllerにレイアウト・ロジック・状態管理が混在しがちで、コードが肥大化するにつれて読解・改修コストが上がります。SwiftUIに移行すると、状態とビューが分離されたシンプルな構造になり、機能追加や不具合修正の工数を抑えやすくなります。

2つ目は開発速度の改善です。SwiftUIはプレビュー機能（Xcodeのキャンバスでのリアルタイム確認）を標準で備えており、レイアウト調整のサイクルが短縮されます。またiOS・macOS・watchOS・tvOSで共通コードが使えるため、マルチプラットフォーム対応が必要なアプリでは特に恩恵が大きくなります。

3つ目はAppleの技術方向性です。AppleはWWDCにおいて毎年SwiftUIへの新機能追加を続けており、新しいAPIの多くはSwiftUI向けに先行提供される傾向が続いています。長期的な機能追加・メンテナンスを見越すと、早期に移行の計画を立てることが将来の技術的負債を抑えることにつながります。

一方、移行すべきでない状況もあります。iOS 12以前のサポートが必要な場合（SwiftUIはiOS 13以降が必須）、または既存のUIKit実装が安定しており追加開発の予定がない場合は、コストに見合わないこともあります。移行を判断する前に、アプリの将来ロードマップと対象iOSバージョンを明確にすることが重要です。

段階移行が現実解：UIHostingController/UIViewRepresentableによる相互運用

既存のiOSアプリをUIKitから一気にSwiftUIへ全面書き換えることは、リリース停止リスクと開発工数の観点から現実的ではないケースがほとんどです。Appleはこの課題を想定しており、UIKitとSwiftUIを共存させるための相互運用APIを公式に提供しています。

UIHostingController — UIKitアプリにSwiftUIビューを埋め込む

UIHostingControllerはSwiftUIのビューをUIKitのView Controllerとして扱うためのクラスです。既存のUIKitベースのナビゲーション（UINavigationController・UITabBarControllerなど）はそのままに、特定の画面だけをSwiftUIで新規実装して差し込むことができます。

例えば「設定画面を新しいSwiftUIデザインに刷新したい」という要件なら、設定画面のView ControllerをUIHostingControllerでラップしたSwiftUIビューに置き換えるだけで対応できます。他の画面には一切手を加えないため、既存機能のリグレッション（意図しない動作変化）リスクを局所化できます。

UIViewRepresentable / UIViewControllerRepresentable — SwiftUIからUIKitを使う

逆方向の相互運用も可能です。UIViewRepresentable（UIViewのラッパー）とUIViewControllerRepresentable（UIViewControllerのラッパー）を使うと、SwiftUIのビューツリーの中に既存のUIKitコンポーネントを組み込めます。

例えば高機能なカスタム地図ビュー・WebView・複雑なカスタムUIKitコンポーネントは、そのままUIViewRepresentableでラップしてSwiftUI側から呼び出すことができます。全てを書き換えるのではなく、SwiftUI側のコードベースを拡大しながら必要に応じてUIKit資産を再利用するアプローチです。

段階移行の進め方

実務上は「画面ごとのSwiftUI化」を単位として移行を進めます。優先度の高い画面（新機能追加が多い・頻繁に改修される・デザイン刷新対象）から着手し、UIHostingControllerで差し替えながら順次移行します。この方法であれば既存アプリのリリースサイクルを止めずに移行を継続できます。

ただし、段階移行を選んだ場合でも、最終的なアーキテクチャの方向性（状態管理の方針・ナビゲーション設計）を最初に決めておくことが重要です。場当たり的に画面だけ差し替えると、UIKit側とSwiftUI側で状態管理の方式が乱立し、後から統合コストが膨らむ原因になります。

移行で詰まる4つのポイント：対応OSバージョン・状態管理・ナビゲーション・テスト

SwiftUI移行を外注で進める際、技術的に詰まりやすいポイントが4つあります。これらは事前に外注先と方針を合意しておかないと、途中でスコープ拡大や手戻りが発生しやすくなります。

最低対応iOSバージョンの制約

SwiftUIのAPIはiOSバージョンアップのたびに大幅に追加・改善されています。例えばNavigationStack（従来のNavigationViewを置き換えるデータドリブンなナビゲーションAPI）はiOS 16で導入されました。iOS 15以前のサポートを維持する場合、NavigationViewという旧APIを使い続けるか、バージョン分岐コードを書く必要があります。

iOS 16/17の新機能を活用できるかどうかで、移行後のコードの簡潔さと保守性が変わります。移行前に「アプリとして対応するiOSの下限をいつ引き上げるか」を決定してから移行設計を進めることが重要です。

状態管理の刷新：Combine/Observationフレームワーク

UIKitではDelegate・KVO・NotificationCenterなどで状態変化を伝達するコードが多く含まれています。SwiftUIではCombine（リアクティブプログラミングフレームワーク）やiOS 17以降のObservationフレームワーク（@Observableマクロ）を使って状態管理を記述します。

既存のUIKitコードにCombine非依存のロジックが多い場合、状態管理の書き換えが移行工数の大きな部分を占めます。また@StateObject・@ObservedObject・@EnvironmentObjectなどSwiftUIの状態管理プロパティラッパーの使い分けを誤ると、意図しない再描画や状態の不整合が発生します。外注先がこれらの仕様を熟知しているかは事前の技術確認で見極める必要があります。

ナビゲーション設計の違い

UIKitのナビゲーションはUINavigationControllerによるスタック管理を中心とし、pushViewController / presentViewController というAPIで遷移を制御します。SwiftUIのナビゲーションはNavigationStackとNavigationLinkによるデータドリブンな遷移設計が基本です。

複雑なページ遷移（ディープリンク・タブ間遷移・モーダル多重表示）を持つアプリでは、ナビゲーションの設計変更が大規模になります。段階移行でUIHostingControllerを使う場合も、UIKit側とSwiftUI側でのナビゲーション状態の同期設計が必要です。

UIテストの整備

UIKitのアプリには既存のXCUITestが存在することがありますが、SwiftUI化に伴いアクセシビリティ識別子（accessibilityIdentifier）の体系が変わることで既存テストが動作しなくなるケースがあります。移行と並行してUIテストを整備するか、移行後に一度テストを再設計するかを外注先と合意しておく必要があります。

内製でSwiftUI移行を担うには、Swift/SwiftUIの深い実装経験・Appleの最新APIへの継続的なキャッチアップ・Xcodeおよびシミュレータでの検証環境の整備が必要です。これらのスキルセットを持つエンジニアを確保・維持するコストと、外注費用を比較したうえで意思決定することをおすすめします。

外注費用の相場：移行範囲と既存コード品質が費用を決める

UIKit→SwiftUI移行の外注費用は、移行画面数・既存コードの品質・状態管理の刷新有無・テスト整備範囲によって大きく変動します。以下に示す費用レンジはあくまで市場参考値であり一次資料ではありません。実際の費用は複数の外注先へ個別見積もりを依頼して確認してください。

費用を大きく変動させる主な要因を以下に整理します。

• 既存コードの品質：UIKitのコードが特定の設計パターン（MVVMやClean Architectureなど）で整理されているか、View Controllerにロジックが集中しているかで調査・設計工数が変わります
• 状態管理の刷新範囲：CombineやObservationフレームワークへの移行が必要かどうか。既存のDelegate・KVOを引き継ぐかどうかで工数が変わります
• カスタムUIKitコンポーネントの数：複雑なカスタムコンポーネントはUIViewRepresentableでの対応か、SwiftUIで再実装するかの判断が必要です
• 最低対応iOSバージョン：iOS 15と16以降では使えるAPIが異なり、バージョン分岐コードの量が変わります
• テスト整備の範囲：XCUITestの再設計・ユニットテストの追加が含まれるかどうかが費用に影響します

「現状調査フェーズだけ先に外注する」という方法も有効です。移行費用を正確に見積もるには既存コードの詳細調査が必要なため、調査フェーズ（技術的負債の棚卸しと移行設計）を数十万円で先行委託し、その結果をもとに本移行の費用を判断する進め方がリスクを抑えます。

外注の進め方：現状調査→移行方針→段階移行→検証の4ステップ

UIKit→SwiftUI移行を外注で進める場合、以下の4ステップを基本フローとして押さえることで、スコープ拡大や手戻りを防げます。

ステップ1：現状調査 — コードベースと画面の棚卸し

最初のステップは既存のUIKitコードを外注先が調査するフェーズです。調査項目は①全画面数と各画面の複雑度、②カスタムUIKitコンポーネントの数と再利用範囲、③View Controllerへのロジック集中度（ファットVC問題）、④既存テストの有無と品質、⑤最低対応iOSバージョン、の5点が中心になります。

この調査結果が移行費用見積もりの根拠となります。コードレビューへのアクセス権限（GitHubなどのリポジトリ閲覧権限）を外注先に提供する必要があるため、NDA（秘密保持契約）の締結を先に行います。

ステップ2：移行方針の決定 — 全面移行か段階移行か、OS下限の確定

調査結果をもとに、外注先と以下の方針を合意します。まず「全面書き換えか段階移行か」を決定します。多くの場合は段階移行（UIHostingControllerを活用した画面単位の置き換え）が選ばれます。

次に「どの画面から移行するか」の優先順位を決めます。変更頻度が高い画面・新機能追加予定がある画面を優先すると、移行の投資対効果が得られやすくなります。あわせて「最低対応iOSバージョンをいつ引き上げるか」も確定します。iOS 16以降を最低バージョンに設定できれば、NavigationStackなどの新APIを活用でき、コードが簡潔になります。

ステップ3：段階移行の実施 — 画面単位のSwiftUI化

移行方針に従い、画面単位でSwiftUIへの置き換えを進めます。各画面の移行完了時にはUIテスト・手動テストでリグレッションがないことを確認してからマージします。UIKitとSwiftUIが混在する期間は、状態管理の一貫性（どちら側で状態を持つか）をアーキテクチャドキュメントで明文化しておくことが重要です。

移行と同時にCombine/Observationフレームワークによる状態管理の刷新を進める場合は、移行画面数だけでなく状態管理の書き換え工数も計上される点に注意が必要です。

ステップ4：検証・統合 — UI整合性の確認とテスト整備

全移行対象画面のSwiftUI化が完了したら、アプリ全体のUI整合性（デザイントークンの統一・スペーシング・フォント）を確認します。SwiftUIとUIKitが混在している段階では、デザインの細部が一致しないケースが発生しやすいため、デザインシステムと照合するレビューを実施します。

最終的にApp Storeへの審査・リリースまでを外注先が担うかどうかも、契約時に明確にしておく必要があります。Appleの審査ガイドラインへの準拠確認・プロビジョニングプロファイルの管理・審査却下時の対応まで含めて外注できるかどうかは、委託先選定の重要な評価ポイントです。

外注先の選び方：SwiftUI実績・段階移行経験・リリース管理体制で見極める

UIKit→SwiftUI移行を外注する場合、一般的なiOSアプリ開発会社ではなく、移行プロジェクトの経験を持つ外注先を選ぶことが重要です。新規開発と移行では求められるスキルセットが異なります。

確認すべき5つのポイント

外注先を選定する際は、以下の5点を確認します。

• SwiftUI・Swift実績：iOS 15以降を対象とした実案件（可能であればSwiftUIを採用したリリース済みアプリ）を持つかどうか。ポートフォリオまたはApp Storeで確認できるか確認します
• UIHostingController/UIViewRepresentableを使った段階移行の経験：既存UIKitアプリのリプレイスやSwiftUI化の実績があるかどうか。新規開発のみの会社とは経験が異なります
• 既存コードの調査・読解能力：他社が書いたUIKitのコードを読み解き、移行リスクを評価できるか。コードレビュー能力は提案段階で「現状調査メモ」の提出を求めることで見極められます
• 状態管理の知見：Combine・Observationフレームワーク・SwiftUIの状態管理プロパティラッパーを正確に使い分けられるか。設計提案書にこれらの記述があるか確認します
• Appleの審査・リリース管理体制：App Store Connectの操作・プロビジョニングの管理・審査却下時の対応まで一気通貫で対応できるかどうかです

契約形態の選び方

UIKit→SwiftUI移行のような改修プロジェクトは、要件定義前にスコープが確定しないことが多く、準委任契約（工数精算型）での契約が適することがあります。一方で現状調査〜移行方針決定フェーズは固定費用の請負契約で切り出し、本移行フェーズを準委任で進めるというハイブリッド契約も有効です。

いずれの場合も、進捗報告の頻度・成果物の定義・品質基準（テストカバレッジ・コードレビュー体制）を契約書または別紙の業務仕様書に明記することで、完成物の品質リスクを管理できます。

内製チームとの協業形態も検討に値します。自社でプロダクトオーナーがいる場合、外注先にはSwiftUI実装の専門知識を担ってもらい、ビジネスロジックや要件の確認は内製で行うスタイルも有効です。この形でも、外注先が元請（プライムベンダー）として開発全体を統括できるかどうかで、プロジェクト管理コストが大きく変わります。

まとめ：UIKit→SwiftUI移行外注を成功させる3つの判断軸

本記事では、既存iOSアプリをUIKitからSwiftUIへ移行する外注の進め方・費用・技術的ポイントを整理しました。要点を3つに集約すると次のとおりです。

第一に、段階移行（UIHostingController/UIViewRepresentable活用）が現実的な選択です。全面書き換えはリリース停止リスクが高く、既存資産の損失期間が生じます。画面単位でのSwiftUI化を段階的に進める方法が、リスクを抑えながら移行できる現実解です。

第二に、最低対応iOSバージョンの決定と現状調査が費用を左右します。SwiftUIはiOS 13以降で動作しますが、NavigationStackなどの機能強化はiOS 16以降です。移行前に対応OS下限を確定し、外注先による既存コードの詳細調査を最初のフェーズとして設けることで、見積もり精度と移行品質が上がります。

第三に、外注先の選定はSwiftUI実案件の実績と段階移行経験で見極めることが重要です。新規開発実績だけでなく、既存UIKitコードの移行経験・状態管理の知見・Appleの審査管理まで一気通貫で対応できるかを確認することが、プロジェクト失敗リスクの低減につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

Tweet