UIKitとは？SwiftUIとの違いをコードで比較、iOS 27の変更点と併用の書き方

UIKitは、iPhone・iPad・Apple TV向けアプリの画面、タッチ操作、アプリの実行ループを管理するAppleのフレームワークです。Appleの公式ドキュメントは「iOS、iPadOS、tvOSアプリのための、グラフィカルでイベント駆動のユーザーインターフェースを構築・管理する」ものと定義しています。2019年に登場したSwiftUIが新しい画面づくりの中心になった今も、UIKitはアプリの土台として毎年更新されています。2026年9月に正式版が出たiOS 27でも、新しいAPIの追加と、既存アプリに対応を求める変更が入りました。

この記事では、UIKitの構成要素、同じ画面をUIKitとSwiftUIで書いたコードの違い、iOS 26・27で入った変更、両者を1つのアプリで併用する書き方、どちらを選ぶかの判断基準を順に扱います。サンプルコードは、Swift 6.3.3とmacOS 26.5 SDKのMac Catalyst向け環境で型チェックしたものです。型チェックは画面表示や操作の動作確認を含みません。

まとめ：UIKitとSwiftUIの違いと2026年の選び方

• UIKitとは：画面（ウインドウとビュー）、タッチなどのイベント処理、メインの実行ループを提供するAppleのUIフレームワーク。公式ドキュメント上はiOS 2.0から対応しています。
• SwiftUIとの違い：UIKitは「ラベルの文字をこう変える」と手順を書く命令型、SwiftUIは「状態がこうなら画面はこう」と書く宣言型です。同じカウンター画面で、UIKit版は35行、SwiftUI版は12行になりました。
• UIKitは終わらない：iOS 26で、updateProperties() と @Observable の自動追跡がUIKitに入りました。SwiftUIの画面も、内部ではUIKitの画面遷移やウインドウの上で動いています。
• 対応が必要な変更：iOS 27 SDKでビルドすると、UISceneのライフサイクルに対応していないアプリは起動しません。起動画面（launch screen）の設定も必須になりました。AppDelegateだけで動いている古いアプリは、SwiftUI化より先にこの対応が要ります。
• 併用が前提：UIHostingController でUIKitの画面にSwiftUIを載せ、UIViewRepresentable でSwiftUIの中にUIKitの部品を置けます。どちらもiOS 13から使えます。
• 選び方：新規アプリはSwiftUIを主にし、届かない部分だけUIKitで補います。UIKitの既存アプリは書き直さず、新しい画面からSwiftUIへ移します。

UIKitとは？iOSアプリの画面と操作を管理するAppleのフレームワーク

Appleの公式ドキュメントによると、UIKitは次の3つを提供します。UIを実装するためのウインドウとビューの仕組み、マルチタッチなどの入力をアプリへ届けるイベント処理、利用者・システム・アプリのやり取りを回すメインの実行ループです。加えて、アニメーション、テキストの表示と編集、印刷、検索、App Extensionなどの機能も含みます。

ボタンやラベルの部品集というより、アプリが起動してから画面を出し、タップに反応し、終了するまでの流れそのものを担う枠組みです。iOSアプリのほとんどは、SwiftUIで書かれたものも含めて、どこかでUIKitの仕組みの上に乗っています。

UIApplication・UIWindowScene・UIViewController・UIViewの役割分担

UIKitのアプリでは、アプリ全体、シーン、ウインドウ、ビューコントローラ、ビューが役割を分担します。下表は、そのうち4つのクラスを抜粋したものです。外側から順に見ると、どこに何を書くかが分かります。

UIWindowSceneの土台になる UIScene はiOS 13で追加されました。iPadで同じアプリを2つのウインドウで開けるのは、画面のまとまりがアプリ全体（UIApplication）から切り離されたためです。画面1枚の設計はUIViewControllerが中心になり、モデルとの役割分担はMVCとは？MVVM・MVPとの違いを同じ機能のコードで比較で扱っています。アラートのようにUIKitの部品をそのまま使う場面の書き方は、UIAlertControllerの使い方｜Swiftのアラート・アクションシート・入力欄とiPadのクラッシュ対策が具体例になります。

UIKitが動くOSと公式ドキュメント上の対応版

公式ドキュメントのUIKitの対応プラットフォームは、iOS 2.0、iPadOS 2.0、tvOS 9.0、visionOS 1.0、Mac Catalyst 13.0です。Mac CatalystはiPadアプリをmacOSで動かす仕組みで、UIKitのコードがそのままMac上でも動きます。macOS向けの画面はSwiftUIやAppKitで作れます。AppKitはUIKitとは別のフレームワークで、UIKitベースのiPadアプリをMacへ展開する場合にはMac Catalystを使います。一覧にはwatchOS 2.0も載っていますが、watchOSで使えるのは UIImage や UIColor などの一部で、UIView と UIViewController はwatchOSでは使えません。Apple Watchの画面はSwiftUIで作ります。

Swift・SwiftUI・UIKitの関係：言語とUIフレームワークの役割分担

Swiftはプログラミング言語、SwiftUIとUIKitはその言語で画面を作るためのフレームワークです。SwiftUIは名前に「Swift」を含みますが、言語ではありません。「SwiftとSwiftUIのどちらを使うか」という比較は成り立たず、選ぶのはUIフレームワークの側だけです。

UIKitはObjective-Cの時代から続くため、Objective-CからもSwiftからも呼べます。SwiftUIはSwiftからしか使えません。Swiftの現行版とXcodeとの対応はSwiftの最新バージョンは6.4｜Xcode対応表とバージョン確認・更新手順にまとめています。iOSアプリ開発の全体像、費用や外注の判断から知りたい場合はiOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説が入口になります。

UIKitとSwiftUIのコード比較：同じカウンター画面の実装

ボタンを押すと回数が1増え、ラベルに表示されるだけの画面を両方で書きました。違いはコードの長さより、ラベルを更新する責任がどちらにあるかに表れます。

UIKit版：ラベルの更新を自分で呼ぶ命令型

import UIKit

final class CounterViewController: UIViewController {
    private var count = 0
    private let label = UILabel()
    private let button = UIButton(type: .system)

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground

        button.setTitle("増やす", for: .normal)
        button.addTarget(self, action: #selector(increment), for: .touchUpInside)

        let stack = UIStackView(arrangedSubviews: [label, button])
        stack.axis = .vertical
        stack.spacing = 12
        stack.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(stack)
        NSLayoutConstraint.activate([
            stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            stack.centerYAnchor.constraint(equalTo: view.centerYAnchor)
        ])
        updateLabel()
    }

    @objc private func increment() {
        count += 1
        updateLabel()
    }

    private func updateLabel() {
        label.text = "タップ回数: \(count)"
    }
}

部品を作り、画面に追加し、Auto Layoutの制約で位置を決め、ボタンの動作を登録する、という手順をすべて書きます。count を変えたあとに updateLabel() を呼び忘れると、値と表示がずれます。画面の状態が増えるほど、この「呼び忘れ」が起きる経路も増えます。

SwiftUI版：@Stateから画面が決まる宣言型

import SwiftUI

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack(spacing: 12) {
            Text("タップ回数: \(count)")
            Button("増やす") { count += 1 }
        }
    }
}

count が変わると、SwiftUIが body を評価し直して表示を更新します。更新を呼ぶコードがないので、呼び忘れも起きません。行数は35行から12行に減りました。その代わり、いつ・どの順で描き直すかはフレームワークに任せることになり、描画のタイミングを細かく握りたい処理では手が届きにくくなります。

SwiftUIとUIKitの違い：書き方・レイアウト・対応OSなど7項目の比較

実務で効くのは、レイアウトと対応OSの2点です。UIKitのAuto Layoutは制約の組み合わせで位置を決めるため、制約が矛盾すると実行時に警告が出て崩れます。SwiftUIはスタックの入れ子で配置が決まり、矛盾そのものが起きにくい作りです。

対応OSは逆の効き方をします。SwiftUIは毎年のOSで機能が増え、新しいAPIほど新しいiOSが必要です。古いiOSも対象に含めるアプリでは、使えるSwiftUIの機能が下限のOSで決まります。UIKitはiOS 13以前から揃っているAPIが多く、下限の影響を受けにくい側です。なお2026年9月9日以降、App Store Connectにアップロードするアプリは、iOS 13以降を対象にすることがAppleの提出要件になりました。

iOS 26・27でUIKitに入った変更：@Observableの自動追跡とUIScene必須化

「UIKitはもう更新されない」という見方は、2026年時点では当たりません。iOS 26ではUIKitの書き方そのものを変えるAPIが入り、iOS 27では既存アプリに対応を求める変更が効き始めました。

updatePropertiesと@Observableによる表示更新の自動化

iOS 26で、UIViewControllerとUIViewに updateProperties() が追加されました。このメソッドの中で読んだ @Observable なモデルのプロパティは、UIKitが自動で追跡します。値が変わると、UIKitが updateProperties() を呼び直して表示を更新します。

import UIKit
import Observation

@Observable
final class Counter {
    var count = 0
}

final class ObservingViewController: UIViewController {
    let counter = Counter()
    private let label = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(label)
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerYAnchor.constraint(equalTo: view.centerYAnchor)
        ])
    }

    override func updateProperties() {
        super.updateProperties()
        label.text = "タップ回数: \(counter.count)"
    }
}

先ほどのUIKit版にあった updateLabel() の呼び出しが不要になり、SwiftUIの書き方に近づきます。Appleの解説によると、自動追跡はiOS 26では既定で有効です。iOS 18では既定で無効で、Info.plistに UIObservationTrackingEnabled を追加して YES にすると、layoutSubviews() などで使えます。updateProperties() はiOS 26以降で利用できます。iOS 18も対象にするアプリでは、iOS 26以降専用の実装を可用性注釈と実行時の分岐で分離し、iOS 18向けには従来の更新処理を用意します。

iOS 27 SDKでビルドするアプリのUIScene必須化

Appleは技術ノートTN3187で、iOS 26の次のメジャーリリースからUISceneのライフサイクルを必須にすると予告していました。2026年9月に出たiOS 27のリリースノートは、「最新SDKでビルドしたアプリは、シーンベースのライフサイクルを採用しなければ起動に失敗する」と明記しています。複数ウインドウへの対応までは求められず、必須なのはSceneのライフサイクルを採用することだけです。

影響を受けるのは、SceneDelegateを持たず、AppDelegateの applicationDidBecomeActive(_:) などで画面の状態を管理している古いアプリです。iOS 26 SDKのヘッダーでは、これらのAppDelegateのメソッドに「UISceneのライフサイクルと sceneDidBecomeActive(_:) を使う」よう求める非推奨の注記が付いています。同じiOS 27のUIKitの項目には、次の2つも並んでいます。

• 起動画面が必須：27.0 SDK以降でビルドするiOS・iPadOSアプリは、Info.plistに UILaunchStoryboardName か UILaunchScreen などのキーが必要です。ないアプリは、App Storeが27.0 SDKでビルドしたアプリの受け付けを始めた時点でリジェクトされます。
• canOpenURLが非推奨：URLを開けるか事前に確かめるのをやめ、開いてみて失敗を処理する書き方へ移ります。カスタムURLスキームの代わりにユニバーサルリンクを使えば、この確認自体が要りません。

Xcodeのバージョン確認とアップデートの手順は別の記事で扱っています。

UIKitとSwiftUIを1つのアプリで併用する書き方

UIKitとSwiftUIは、どちらか一方を選ぶものではありません。同じアプリの中で相互に呼び出せるため、画面ごと、部品ごとに使い分けられます。ここでは、橋渡しの代表的なAPIを3つ紹介します。

UIHostingControllerによるUIKit画面遷移へのSwiftUIの組み込み

import UIKit
import SwiftUI

struct SettingsView: View {
    var body: some View { Text("設定") }
}

final class HomeViewController: UIViewController {
    func showSettings() {
        let hosting = UIHostingController(rootView: SettingsView())
        navigationController?.pushViewController(hosting, animated: true)
    }
}

UIHostingController はSwiftUIのビューを包み、UIViewControllerとして扱えるようにします（iOS 13から）。既存のナビゲーションやタブの構成に手を入れず、新しい画面1枚だけをSwiftUIで書けるため、UIKitのアプリにSwiftUIを入れるときの最初の一歩になります。

UIViewRepresentableによるSwiftUIへのUIKit部品の組み込み

import SwiftUI
import UIKit

struct ActivityIndicator: UIViewRepresentable {
    var isAnimating: Bool

    func makeUIView(context: Context) -> UIActivityIndicatorView {
        UIActivityIndicatorView(style: .large)
    }

    func updateUIView(_ uiView: UIActivityIndicatorView, context: Context) {
        isAnimating ? uiView.startAnimating() : uiView.stopAnimating()
    }
}

逆向きの橋渡しです。makeUIView でUIKitの部品を一度だけ作り、SwiftUI側の値が変わるたびに updateUIView で反映します。画面ごと埋め込むなら UIViewControllerRepresentable を使います。社内で作り込んだUIKitの部品や、SwiftUIに相当するものがない部品を、SwiftUIの画面で使い続けられます。

UIHostingConfigurationによるセル内容のSwiftUI化

import SwiftUI
import UIKit

func configure(cell: UICollectionViewCell, title: String) {
    cell.contentConfiguration = UIHostingConfiguration {
        Label(title, systemImage: "star")
    }
}

UIHostingConfiguration（iOS 16から）を使うと、UICollectionViewやUITableViewのセルの中身だけをSwiftUIで書けます。数千行のリストのスクロールやセルの再利用はUIKitに任せたまま、セルのレイアウトを短く書けるので、一覧画面の多い業務アプリで効果が出やすい組み合わせです。

UIKitとSwiftUIの選び方：新規・既存・学習順の判断基準

SwiftUIを主にしてよい条件

次の3つが揃うなら、SwiftUIを主にして、届かない部分だけUIKitで補う構成で始めて問題ありません。

• 新規開発で、UIKitの既存コードを引き継がない
• 対応OSの下限を直近2世代程度に置ける（使いたいSwiftUIの機能の対応版を下限が満たす）
• Appleの標準部品に近い見た目で要件が満たせる

データの保存には、SwiftDataとは？@Modelの仕組みとCore Dataとの違い・2026年の採用判断で扱うSwiftDataが使えます。SwiftUIとの統合機能を備えていますが、UIKitやAppKitのアプリでも利用できます。Liquid GlassはSwiftUIとUIKitの標準部品に対応しており、実装はLiquid Glassとは？仕組みと対応OS、SwiftUI・CSSでの実装方法【iOS 27の変更点まで】で扱っています。

UIKitを主に残すべき場面と全面書き換えで失敗するパターン

UIKitを主に残すべきなのは、数十画面以上のUIKitアプリを保守している場合、テキスト編集やスクロールの挙動を細かく作り込んでいる場合、カメラのプレビューに複雑な重ね合わせをする場合です。

避けたいのは、動いているUIKitアプリを「SwiftUIに全面移行する」案件として一度に書き直すことです。全面書き換えに開発要員を集中させると、新機能の開発が止まるおそれがあります。既存の不具合修正を新しい実装へ引き継げなければ、修正済みの不具合も再発し得ます。UIHostingControllerで新しい画面から1枚ずつSwiftUIにし、設定画面のように他の画面とのやり取りが少ないものから始めます。決済や認証のように失敗が事業に直結する画面は最後に回します。UIScene対応が済んでいないアプリは、SwiftUI化より先にTN3187に沿った対応を終えてください。iOS 27 SDKでビルドした時点で起動しなくなるのはこちらです。

既存アプリの段階移行やUIScene対応を外部に任せる場合は、当社のiOSアプリ開発支援を含め、UIKitの既存コードを読める体制があるかを先に確認してください。

SwiftUIとUIKitの学習順：新規開発と既存アプリ保守の違い

新しくアプリを作るために学ぶならSwiftUIが先です。少ないコードで画面が動くまでたどり着けるうえ、iOS 26で入ったUIKitの updateProperties() も、@Observableで状態を追う点でSwiftUIと同じ考え方に寄っています。ただし、業務で既存アプリの保守に入るなら、UIViewControllerのライフサイクル（viewDidLoad から viewWillDisappear まで）とAuto Layoutは避けて通れません。既存アプリの改修を担当する予定があるなら、SwiftUIで一通り作れるようになった段階でUIKitの読み方を押さえる順番が現実的です。iOS以外も含めた言語の選び方はアプリ開発の言語選定｜Swift・Kotlin・Dartの分岐条件を実装視点で解説にまとめています。

UIKit・UIキット・UIkitの違い：Apple製フレームワーク・デザイン素材・Web用フレームワークの区別

「uikit」で検索すると、AppleのUIKitとは別のものが2つ混ざります。

• UIキット（UI kit）：Figmaなどのデザインツールで使う、ボタンや入力欄などの部品をまとめたデザイン素材集です。コードではなくデザインデータで、Figmaのコミュニティでは無料のUIキットが多数公開されています。
• UIkit（YOOtheme）：Webサイト向けのCSS・JavaScriptフレームワークです。「k」が小文字で、公式サイトで配布されています。GitHubの最新リリースはv3.25.26（2026年10月5日）です。

iPhoneアプリの開発でSwiftから呼ぶのは、Apple製の「UIKit」（Kが大文字）だけです。Webの画面にUIkitを入れても、iOSアプリの部品にはなりません。

UIKitとSwiftUIに関するよくある質問

UIKitとは何ですか？

iPhone・iPad・Apple TV向けアプリの画面、タッチなどのイベント処理、アプリの実行ループを管理する、Apple製のUIフレームワークです。SwiftとObjective-Cから使えます。

SwiftUIとUIKitの違いは何ですか？

UIKitは表示の更新を開発者が手順として書く命令型、SwiftUIは状態から表示を宣言する宣言型です。SwiftUIはiOS 13（2019年）からの新しいフレームワークで、macOSやwatchOSにも同じ書き方で対応します。

UIKitはなくなりますか？

なくなる予定は示されていません。iOS 26でも updateProperties() や @Observable の自動追跡が追加されています。一方で、iOS 27 SDKでビルドするアプリは、UISceneのライフサイクルに対応していないと起動しなくなりました。

SwiftUIとUIKitは同じアプリで併用できますか？

できます。UIKitの画面にSwiftUIを載せるには UIHostingController、SwiftUIの画面にUIKitの部品を置くには UIViewRepresentable を使います。どちらもiOS 13から使えます。

Swiftとはどういう意味ですか？

Appleが開発したプログラミング言語の名前です。英語の「swift」は「速い」という意味です。SwiftUIはSwiftで画面を作るためのフレームワークの名前で、言語そのものではありません。

関連記事

• Swiftの最新バージョンは6.4｜Xcode対応表とバージョン確認・更新手順
• iOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説
• MVCとは？MVVM・MVPとの違いを同じ機能のコードで比較
• UIAlertControllerの使い方｜Swiftのアラート・アクションシート・入力欄とiPadのクラッシュ対策
• Liquid Glassとは？仕組みと対応OS、SwiftUI・CSSでの実装方法【iOS 27の変更点まで】