SwiftUIとは｜UIKitとの違い・できること・案件動向を解説

SwiftUIとは｜Appleが提唱する宣言的UIフレームワーク

SwiftUIは、Swift言語で書くApple純正のUIフレームワークです。2019年のWWDCで発表され、執筆時点ではAppleが提供する各プラットフォーム（iOS / iPadOS / macOS / watchOS / tvOS / visionOS）すべてに対応しています。最新の仕様はApple Developerの公式ドキュメントで確認できます。

宣言的UIという考え方

SwiftUIは「画面の最終状態を記述すると、その状態どおりに描画される」という宣言的（Declarative）な書き方を採用しています。UIKitのように「ボタンを生成し、配置し、タップされたらこのメソッドを呼ぶ」と命令を並べる手続き型ではありません。

具体的には、状態を表す変数（@State / @Binding / @ObservedObject など）が変わると、SwiftUIがビューの表示内容を再評価し、必要な差分を反映します。エンジニアは「状態が変わったらUIをどう変えるか」をコード上で逐一記述しなくて済むため、画面遷移や状態管理の記述量が大きく減ります。

何が嬉しいのか

代表的な利点のひとつがXcodeのプレビュー機能との相性です。コードを書いた瞬間にデバイスシミュレーターより軽量なライブプレビューが描画され、ホットリロードに近い感覚でUIを試せます。UIKitでStoryboard・XIB・コードの3経路に分かれていた設計が、SwiftUIではSwiftコードに一本化されます。

Swiftとの関係

SwiftUIはSwift言語の機能（property wrapperやResult Builderなど）に強く依存しており、Swift本体の理解なしには扱えません。先にSwiftの基礎を押さえてからSwiftUIに入る順序が現実的です。

ミニFAQ｜SwiftUIの位置づけ

Q. SwiftUIを使えばUIKitは不要になりますか？

現時点ではNoです。UIKitでしか実装できない機能（細かいスクロール挙動、特殊な入力、既存ライブラリの取り込み）が残っており、UIKitとSwiftUIを橋渡しするAPIが公式に用意されています。

Q. Web開発の宣言的UI（React等）と同じ感覚で書けますか？

近い感覚はありますが、状態管理の仕組み（@State / @Bindingなど）はSwiftUI独自で、Reactのフックとは別物です。

SwiftUIとUIKitの違い｜思想・記述量・学習コストで比較

SwiftUIとUIKitは、対象プラットフォームが重なるだけで設計思想は別物です。UIKitは2008年から続く命令的（Imperative）なフレームワークで、SwiftUIは2019年に登場した宣言的なフレームワークです。

比較表｜思想と実装スタイル

互換性と橋渡し

SwiftUIとUIKitは相互に呼び出せる設計になっています。SwiftUIビューをUIKit側に埋め込む場合はUIHostingController、UIKitのビューをSwiftUI側に持ち込む場合はUIViewRepresentable / UIViewControllerRepresentableを使います。実務では「画面はSwiftUIで作り、特定のUI部品だけUIKit由来を使う」という併用構成が一般的です。

どちらが「正解」というよりプロジェクト要件次第

新規アプリでiOS 16以上を最低サポートに設定できるならSwiftUIファーストで設計しやすい一方、iOS 14・15のサポートが必須だとSwiftUIで使えないAPIが増えるため、UIKit中心または併用構成が現実的になりやすい領域です。SwiftUIは「OSバージョンごとに使えるAPIが大きく変わる」点が要注意で、サポートOSの設定値がSwiftUIで書ける範囲を直接左右します。

ミニFAQ｜UIKitからの移行判断

Q. 既存のUIKitアプリを丸ごとSwiftUIに置き換えるべきですか？

全画面の一斉移行は推奨されないケースが多い領域です。画面単位・機能単位で徐々に置き換える進め方が現実的で、特に新規追加の画面からSwiftUI化するパターンが目立ちます。

SwiftUIでできること・できないこと

SwiftUIは年々できることが増えていますが、すべてのUIで万能なわけではありません。プロジェクト判断のために「得意領域」と「現状苦手な領域」を分けて整理します。

SwiftUIで作りやすいもの

• 設定画面・プロフィール画面のようなフォーム系UI（Formコンポーネントが強力）

• リスト＋詳細画面のマスター・ディテール構成

• ダークモード・ダイナミックタイプ・ローカライズに対応した標準的なUI

• watchOSアプリ・widget・Live Activity・ロック画面ウィジェット（SwiftUI前提）

• visionOSアプリ（Apple Vision Pro向けは実質SwiftUI主体）

SwiftUIだけだと苦戦しやすいもの

• カメラ・複雑なカスタムジェスチャ・PDF描画などハードウェアやメディアに密接なUI

• 大量データを高頻度で更新する極端なパフォーマンス要件を持つリスト

• 既存のUIKitライブラリ（特に古い決済SDKや動画SDK）を組み込む画面

• Mapの細かい挙動制御（MapKit本来の機能を全部叩く場合）

• 標準UIのアクセシビリティ対応はSwiftUIでも進めやすい一方、細かなフォーカス制御や既存UIKit部品との整合が必要なケース

これらの領域は「SwiftUI内でUIKitラッパーを呼ぶ」「該当画面だけUIKitで作る」という対応が定石です。Apple Developerが公開しているSwiftUIサンプルを眺めると、得意領域のイメージがつかみやすくなります。

バージョンによる差を意識する

SwiftUIは「あるOSバージョンから一気に使い物になったAPI」が多く、サポートOSを下げると使えないAPIが急に増えます。iOS 16で追加されたNavigationStack、iOS 17で追加されたObservableマクロなど、案件のサポートOS設定で実装方針が大きく変わる点には注意が要ります。

SwiftUIのメリット・デメリットを実務目線で整理

技術記事の定番ですが、フリーランスエンジニアとして案件に入る判断軸として有効なため、整理しておきます。

メリット

記述量が減り、開発スピードが上がりやすい。状態管理が言語機能と統合されており、画面遷移・条件付き表示・アニメーションが短いコードで書けます。

プレビューでフィードバックループが短い。Xcodeのプレビュー機能と組み合わせると、UIの試行錯誤が数秒単位で回ります。デザイナーとの認識合わせも速くなる傾向があります。

Appleの新プラットフォームでファーストクラス。visionOS、ロック画面ウィジェット、Live Activityなど、近年Appleが追加した領域はSwiftUIが前提です。新規領域を取りに行きやすい構造になっています。

保守時にUI構造が読みやすい。UIの階層がSwiftコードの構造と一致するため、過去の自分や他人の書いたStoryboardを読み解く労力が減ります。

デメリット

OSバージョン依存が強い。新APIは新OS限定で、サポート対象を1〜2バージョン下げると使えない機能が急に増えます。

情報の鮮度が問われる。検索で出てくるSwiftUI記事はOSバージョンごとに正解が違うため、古いコードがそのまま動かないことがあります。Apple Developerの公式ドキュメント参照が前提になります。

複雑なカスタム描画では限界がある。CoreAnimation・CoreGraphicsの細かな制御が必要な領域は、UIKit側に逃がす設計が現実的です。

既存資産が比較的浅い。UIKitに比べてサードパーティライブラリの蓄積が少なく、UIKit前提のSDKと組み合わせるときは橋渡しコードが必要になります。

ミニFAQ｜デメリットへの実務対応

Q. OSバージョン依存が強いと聞いて不安です。どう対処しますか？

案件のサポートOS設定値をまず確認し、その範囲で使えるAPIだけで設計します。if #availableによる分岐や、OSごとの代替APIへの差し替えは実務で頻出するため、Apple Developerドキュメントの「対応OSバージョン表記」を読む癖をつけると安全です。

SwiftUI案件の動向と単価感｜フリーランス目線で見た現状

ここからはフリーランスエンジニア固有の関心領域です。この章で扱う数字は「主要フリーランスエージェント（フリコンを含む）の公開案件で観測できる範囲」に限定しています。クローズド案件・直案件は対象外で、案件のスキル要件や働き方によって幅があります。

公開案件で観測できる傾向

2026年6月時点でフリコンを含む主要フリーランスエージェントの公開案件を確認すると、SwiftUI単独の募集よりも「Swift / iOS開発経験」を必須スキルとし、SwiftUIを歓迎または必須要件に加える形式が目立ちます。新規開発・既存アプリのSwiftUI化案件の双方が見られ、iOS 16以上のサポートを許容できる新規プロダクトでSwiftUI採用例が増える傾向があります。

業種別では、公開案件と各社の技術発信ベースで見たときに、金融・ヘルスケア・小売・SaaS系の自社プロダクトでSwiftUI採用例が観測されます。受託系では既存UIKitアプリの追加画面をSwiftUIで実装する案件も見られます。

単価感（公開案件ベースの目安）

2026年6月時点で主要フリーランスエージェントの公開案件（週5・業務委託）を観測すると、iOSエンジニアの単価レンジはおおむね月額60〜100万円前後が中心帯です。公開案件の要件を見る限り、SwiftUIスキル単体よりもiOS開発全体の経験年数・要件定義への踏み込み・テスト/CI設計の経験が単価に反映されやすい傾向があります。

公開案件ベースでは、月額100万円を超える上位帯の募集はSwiftUIだけでなく以下のような複合条件を満たす人物像を想定して募集されているケースが目立ちます。

• iOS開発経験5年以上で、UIKit / SwiftUI双方を実務で扱える

• 設計（アーキテクチャ選定・モジュール分割）からリードできる

• TestFlight配信・App Store審査対応・CI/CDの構築経験がある

• iOSチームを横断するテックリード経験がある

単価レンジは案件ごとに大きく振れるため、現時点の最新情報はフリーランスエンジニアの単価相場もあわせて確認すると、自身のスキル帯の感覚をつかみやすくなります。

募集の特徴

• フルリモート可の案件が多めだが、初期キックオフは出社を求めるケースもあります

• 稼働日数は週3〜5日の選択肢がある案件と、週5固定の案件に二分されます

• 募集職種としては「iOSエンジニア（SwiftUI歓迎）」の表現が多く、SwiftUIだけを切り出した募集は限定的です

ミニFAQ｜案件への入り方

Q. SwiftUIだけ学べばiOS案件に入れますか？

入りにくい構造です。Swift言語・UIKit・iOSアプリのライフサイクル・配信フロー（App Store審査やTestFlight）の理解がセットで求められます。

Q. 案件はどこで探せますか？

フリーランスエンジニアの営業方法で整理している通り、複数のエージェントへの登録・直接の知人経由・コミュニティ経由の3経路が現実的です。フリコンでもiOS関連案件を取り扱っています。

SwiftUIとクロスプラットフォーム（Flutter/React Native）の違い

SwiftUIをFlutter・React Nativeと比較するシーンは多く、案件の技術選定で判断を求められるケースもあります。それぞれの立ち位置を整理します。

比較表｜思想とプラットフォーム対応

比較の前提

SwiftUIはiOSをネイティブUIで作り込むための選択肢、Flutter・React NativeはiOSとAndroidを単一コードで動かすための選択肢であり、本来は土俵が違います。SwiftUI vs Flutterというよりも「ネイティブ最優先か、クロス開発で工数を圧縮するか」の判断になります。

どんなプロジェクトでどれが選ばれるか

• Apple純正の新機能（Vision Pro対応、Dynamic Island、Live Activity等）を活用したい → SwiftUI

• iOSとAndroidの両OSに同じ機能・同じ見た目で展開したい → FlutterまたはReact Native

• 既存のWeb（React）チームでアプリも作りたい → React Nativeが有力

• iOSアプリの体験を最優先しつつAndroidは別チームで開発する → SwiftUI（あるいはUIKit）

それぞれの技術選定の詳細は、Flutterとは・React Nativeとは・Kotlinとはもあわせて読むと、クロスプラットフォーム3すくみの違いが見えやすくなります。

SwiftUIの学習ロードマップ｜Swiftからの最短経路

SwiftUIだけを単独で学ぶより、Swift言語の基礎を固めてから入る方が結果的に近道です。フリーランスとして案件に入ることを前提に、学習順序を提示します。

ステップ1｜Swift言語の基礎（推奨2〜4週間）

型システム・オプショナル・クロージャ・プロトコル指向プログラミングなど、Swift特有の文法を押さえます。SwiftUIで頻出するResultBuilder・property wrapper・キーパスは、Swift本体の機能であってSwiftUI固有ではありません。先にSwift言語の解説を読み、入門書1冊と公式ドキュメントを併走させると効率的です。

ステップ2｜SwiftUI基本ビューと状態管理（推奨2〜3週間）

Text / Image / Button / List / Form / NavigationStack / TabViewなどの基本ビューと、@State / @Binding / @ObservedObject / @StateObjectの使い分けを写経レベルで一通り触ります。AppleがWWDCで公開しているSwiftUIサンプル集を実際に動かすのが理解の近道です。

ステップ3｜画面遷移・データの永続化・API通信（推奨2〜3週間）

URLSessionでの通信、CodableでのJSONデコード、UserDefaultsやSwiftData / Core Dataを使った永続化を、最小構成のアプリで一通り経験します。

ステップ4｜UIKitとの相互運用（推奨1〜2週間）

UIHostingControllerとUIViewRepresentableを使った相互呼び出しを試します。現場ではUIKit由来のSDKと連携することが多いため、必ず通っておくべきステップです。

ステップ5｜公開アプリの完成と配信経験（推奨1〜2か月）

App StoreまたはTestFlightで配信できるレベルのサンプルアプリを1本仕上げます。配信フロー（証明書・プロビジョニング・審査）の経験は、案件選考で確実に問われる領域です。

ステップ6｜案件参画・実務経験の蓄積

ここまでの学習が終わったら、エージェントへの登録・面談に進みます。フリコンでもiOS関連の案件相談を受け付けています。

学習で詰まりやすいポイント

• 状態管理の選び方：@State / @ObservedObject / @StateObjectの使い分けは初学者がまず詰まる部分で、公式ガイドの該当章を繰り返し読むのが結局の近道です

• OSバージョン分岐：同じAPIでも対応OSが違うため、検索で出たコードがそのまま動かないことがあります

• プレビューが頻繁に落ちる：Xcodeのプレビューはマシンスペックを要求するため、メモリが少ない環境だと作業効率が大きく落ちます

SwiftUI採用判断フロー｜どんなプロジェクトに向くか

SwiftUIを「使うか/使わないか」を判断するための、ケース別の整理を置きます。

ケース1｜新規プロダクトでiOS 16以上を最低サポートにできる

SwiftUIファーストで設計しやすい状況です。NavigationStackやObservableマクロを含む新しめのAPIが使え、SwiftUIだけで完結する画面の比率を高められます。Apple純正の新機能（Live Activity・Vision Pro対応）を取り入れる予定があるなら、SwiftUI採用がほぼ必須となります。

ケース2｜既存UIKitアプリに画面を追加する

既存資産は触らず、新規追加分だけSwiftUIで書く判断が現実的です。UIHostingControllerで既存のUINavigationControllerに差し込む形で進めます。

ケース3｜iOS 14・15のサポートが必須

NavigationStackやChartsなどが使えず、設計の選択肢が大きく狭まります。UIKit中心で進め、限定的にSwiftUIを差し込む判断になりやすい領域です。

ケース4｜iOSとAndroidを同時にリリースする

ネイティブを2本走らせるリソースがあるならSwiftUIとAndroid側（Jetpack Compose等）の併走、リソースを抑えるならクロスプラットフォーム（Flutter / React Native）の検討が現実的です。SwiftUI単体ではこの要件を解決できません。

ケース5｜複雑なカメラ・動画・PDFを扱う

SwiftUIだけで完結させようとせず、該当画面はUIKit + AVFoundation / PDFKitで作り、SwiftUIから呼び出す構成が無難です。

判断のチェックリスト

採用判断時に最低限確認しておきたい項目です。

• 最低サポートOSのバージョンが固定されているか

• 既存アプリのUIKit資産との接合点（画面遷移・データ受け渡し）を整理できているか

• 使いたいサードパーティSDKがSwiftUI対応しているか、UIKit経由が必要か

• チーム内にSwiftUIの実装経験者がいるか、いない場合の学習工数を見込めているか

• App Store審査・CI/CD・配信フローの担当を明確にできているか

まとめ

SwiftUIは、Appleが提唱する宣言的UIフレームワークで、iOSをはじめとするApple製品のUI開発において新規プロダクトの第一選択肢になりつつあります。UIKitと対立する技術ではなく併用する技術で、案件で求められるのは「SwiftUIだけ書ける人」ではなく「SwiftUIとUIKitを実務で行き来できるiOSエンジニア」です。

要点の整理です。

• SwiftUIは状態を宣言するだけでUIが描画される宣言的フレームワーク

• UIKitとの併用が現場標準で、画面単位での置き換えが進んでいる

• iOS 16以上を許容できる新規案件ではSwiftUIファースト設計が増えている

• 公開案件で観測できる単価感はiOS開発全体の経験で決まる傾向が強い

• Swift言語の基礎→SwiftUI基本→UIKit相互運用→配信経験の順で学ぶのが現実的

• Apple Vision Pro・Live Activityなどの新領域はSwiftUI前提で設計されている

次のステップとして、まずはApple公式のSwiftUIサンプルを1本動かし、自分の手元でプレビュー機能を試すところから始めるのが最短経路です。学習が一段落したら、エージェント経由でiOS案件の単価感や募集要件を確認し、自身のスキル帯と照らし合わせると次の打ち手が見えやすくなります。フリコンでもiOSエンジニア向けの案件相談を受け付けているため、案件動向の感触をつかみたい段階で活用できます。

参考リンク

• Apple Developer｜SwiftUI 公式紹介ページ

• Apple Developer Documentation｜SwiftUI

• Swift.org｜Swift言語公式サイト