スパイダープラス Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ

トップ > テクノロジー > SwiftUI vs UIKit: iOS開発の比較

SwiftUI vs UIKit: iOS開発の比較

テクノロジー Swift iOS

こんにちは。
スパイダープラスでiOSエンジニアとして働いているJです。

iOS開発を始める際に、SwiftUIとUIkitのどちらを学ぶべきか？ または 既存のUIKitプロジェクトをSwiftUIに移行すべきか？ という疑問を持つ人も多いと思います。

私はSwiftUIとUIKitの両方を使用したプロジェクトに携わった経験があります。
私自身はiOSエンジニアとしてUIKitから開発を始めたため、最初にSwiftUIのプロジェクトに参加した際は、その開発スタイルの違いに戸惑うこともありました。

今回は、そうした経験も踏まえて両者の違いを比較し、それぞれのメリットとデメリットについて解説します。

1. 開発スタイルの違い

SwiftUI

  • 宣言的（Declarative）なアプローチでUIを構築
  • データバインディング（@State、@Binding、@ObservedObject）によりUIが自動更新
  • 動作確認はシミュレーターでも確認できるが、プレビューのサポートできるのでコード修正後すぐに確認可能

UIKit

  • 命令的（Imperative）なアプローチでUIを構築
  • delegate、dataSource パターンを使用して状態を管理
  • 動作確認はシミュレーターが必要

宣言的（Declarative）vs 命令的（Imperative）

上記のSwiftUIとUIKitのスタイルの違いを説明する内容に「宣言的」「命令的」という表現がありますが、こちらのスタイルにどんな違いがあるか確認しましょう。

  • 宣言的（Declarative）
    • 「何をするのか？」 (What to do?) を定義するスタイル
    • 開発者はUIの最終状態を宣言するだけで、システムが自動的に状態を維持
    • 「このUIはこの状態であるべき」と定義するだけでOK
    • UIの更新(レンダリング)はシステムが自動で処理
    • SwiftUI、 React、 Flutter などのフレームワークは宣言型の方式
  • 命令的（Imperative）
    • 「どのようにやるのか？」 (How to do?) を定義するスタイル
    • UIの変更を行うために、すべての手順を明示的に記述する必要がある
    • UIの状態を変更する際、具体的な操作を1つ1つ指示する必要がある
    • UIKit, Androidの従来のViewシステム、 Java Swing などは命令型の方式

以上のように簡単に整理するとSwiftUIは宣言型のアプローチで、UIの状態を変更するだけで自動的に更新されます。

UIKitは命令型アプローチで、開発はコードが比較的複雑になりますが、具体的な操作を1つ1つ指示するためより細かいUI制御が可能な方式です。

2. コード比較

シンプルなコードでSwiftUIとUIKitでの実装比較

下の画像のように「Increase」ボタンをクリックしたら画面に表示されるCountが1ずつプラスできるコードを比較しましょう。

SwiftUI

Swift
struct ContentView: View { 
    @State private var count = 0 // 状態変数として宣言
        var body: some View { 
            VStack { 
                Text("Count: \(count)") // UIが自動更新される
                Button("Increase") { 
                    count += 1 
                }
             }
         }
     }

UIKit

Swift
import UIKit 

class ViewController: UIViewController { 

// Storyboardで接続したIBOutlet
@IBOutlet weak private var label: UILabel!
@IBOutlet weak private var button: UIButton!

// カウント変数
    var count: Int = 0 

// 初期UI設定
    override func viewDidLoad() { 
        super.viewDidLoad() 
        // Label 生成 
        label.text = "Count: \(count)" 

        // Button 生成 
        button.setTitle("Increase", for: .normal) 
     } 
    
// Storyboardで接続したIBAction（ボタンクリック時に実行）
@IBAction func increaseCount(_ sender: Any) {
        count += 1 
        label.text = "Count: \(count)"  // UI更新は手動で適用する必要あり
    }
}

上記のようにSwiftUIで実装されているコードは「＠State」という状態変数を宣言してボタンactionでデータが更新されたらUIが自動的に更新されます。

UIKitではStoryboardから接続したUILabelやUIButtonの値変更はIBActionを明示的に接続して、処理するボタンクリックなどのイベント処理をする時に、IBOutletを使用して手動で値を変更できるようにする必要があります。

3. メリット・デメリット比較

 

  SwiftUI UIKit
UI更新

状態変化によって自動更新 (@State)

 IBAction Eventの中にデータを変更するIBOutletパーツを呼び出して手動更新
アニメーション 標準機能として提供（簡単に適用可能） UIView.animate() や Core Animation を使用
Storyboard対応 不可 (すべてコードでUIを作成) 可能 (XIB、Storyboardが使用可能)
互換性 iOS13以上対応 iOS 2 以上対応（幅広いデバイスをサポート）
マルチプラットフォーム対応 iOS, iPadOS, watchOS, macOS をサポート iOS, iPadOS 中心（macOSはAppKitが必要）
おすすめの使用ケース 新規プロジェクト、シンプルなUI開発、高速なプロトタイピングが必要な場合 既存のUIKitプロジェクトのメンテナンス、詳細なUIカスタマイズ( Core Graphics, Core Animation, CALayer等 )が必要な場合

 

※結論を考えると

  • SwiftUI: シンプルで直感的なコードで開発し、状態ベースのUI更新が重要な場合
  • UIKit: 複雑なUIカスタム、レガシープロジェクトのメンテナンス、Storyboardの活用が必要な場合

と、区別することができます。

可能であれば両方ともSwiftを用いて開発する方法なのでUIKitとSwiftUIを組み合わせて活用し、それぞれの強みを最大限に生かすのが最も効率的な方法になると思います。

最後に

SwiftUIは、宣言的なスタイルを採用しており、コードを見ただけで画面の構成を直感的に理解しやすいのが特徴です。
また、効率的なiOS開発を実現できる点も大きなメリットです。

一方で、UIKitはレガシーシステムの保守や、細かいUIカスタマイズが必要な場面において、今でも重要な役割を果たしています。

冒頭でも書いたように私自身、SwiftUIとUIKitの両方を使用したプロジェクトに携わった経験があります。
それぞれの良さを振り返ると、SwiftUIとUIKitの両方を学び、バランスよくスキルを身につけることをおすすめします。

 

最後に、スパイダープラスでは仲間を募集中です。
主観的にはスパイダープラスではSwiftUI、 UIKit 両方経験できる開発環境がありますのでiOSエンジニアとして大きく成長できます。

スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧くださり、ありがとうございます。