iOS（Swift・SwiftUI）

iOS のアプリは、画面に出ているか、裏に回ったかで OS から状態を切り替えられます。今のアプリはシーン（ウィンドウ1つ分。iPad では複数持てる）ごとに状態を持ちます。SwiftUI では @Environment(\.scenePhase) で .active・.inactive・.background を受け取れます。

大事なのは、サスペンド中に終了されても通知は来ないことです。だから「終了するときに保存」ではなく、バックグラウンドに入った時点で保存しておきます。次に開いたときは最初からの起動（コールドスタート）になるので、どの画面だったかを復元できるようにします（SwiftUI なら @SceneStorage）。

iOS のアプリは、裏に回ると数秒でサスペンドされます。裏で処理を続けたいときは、目的ごとに用意された仕組みを使います。自由に動き続ける方法はないので、「何を・どれくらい確実に」したいかで仕組みを選びます。

• できる：beginBackgroundTask で短い時間だけ処理を続ける（保存や送信の仕上げ）。URLSession のバックグラウンド設定でのダウンロード・アップロード（アプリが止まっても OS が続けてくれる）。BGTaskScheduler での定期的な更新（BGAppRefreshTask）や、充電中などに長めの処理（BGProcessingTask）。音楽の再生・位置情報・通話など、Background Modes で許可された用途。サイレントプッシュでの起動。
• できない：好きなときに好きなだけ動き続けること。BGTaskScheduler の実行時刻は OS が電池や使われ方を見て決めるので、「毎時0分に必ず動く」は作れません。サイレントプッシュも回数を絞られ、届く保証はありません。利用者がアプリ切り替え画面から上にスワイプして終了させると、次に開くまで裏の処理はほぼ動きません。

落とし穴は、時間内に endBackgroundTask を呼ばないと OS にアプリを終了させられることと、目的外の Background Modes を付けると審査で落ちることです。定期的な同期は「開いたときに取りにいく」を基本にし、裏の更新はおまけと考えると安定します。

SwiftUI は「状態がこうなら画面はこう」と宣言して書く UI の仕組みで、状態が変わると必要な部分だけが描き直されます。UIKit は昔からある仕組みで、画面の部品（View）を作って、状態が変わるたびに自分で書き換えます。新しい画面は SwiftUI で書くのが今の主流ですが、UIKit の資産や細かい制御が必要な場面はまだ残っています。

判断の目安は、アプリが対応する最低の iOS の版です。SwiftUI の便利な機能（たとえば NavigationStack は iOS 16、@Observable は iOS 17 から）は新しい OS でしか使えないので、最低の版を上げられるかで書き方が変わります。

SwiftUI では、画面は状態から作られるので、状態を誰が持つかをはっきりさせることが一番大事です。印（プロパティラッパー）は、持ち主か、借りているだけかを表します。

SwiftUI の画面遷移は、iOS 16 からの NavigationStack が基本です。積み重なった画面を path（配列）として状態で持てるので、コードから好きな画面へ移ったり、リンクから途中の画面を再現したりしやすくなりました。

@State private var path: [Route] = []
NavigationStack(path: $path) {
  ListView()
    .navigationDestination(for: Route.self) { route in
      switch route { case .item(let id): ItemView(id: id) }
    }
}

path には画面そのものではなく、どの画面かを表す小さな値（ID など）を入れます。こうすると状態の保存や復元、テストがしやすくなります。古い NavigationView は非推奨なので、新しい画面では使いません。

既存のアプリを一度に SwiftUI へ書き直すことはまずありません。新しい画面から SwiftUI にし、地図やカメラなど UIKit にしかない部品は包んで使う、という混ぜ方が普通です。

混ぜて使うとき

• UIKit の中に SwiftUI：UIHostingController(rootView:) で SwiftUI の画面を UIKit の画面として載せます。既存アプリで新しい画面から SwiftUI に移すときの定番です。
• SwiftUI の中に UIKit：UIViewRepresentable・UIViewControllerRepresentable で包みます。地図・カメラ・既存の独自部品などで使います。UIKit 側のデリゲートは Coordinator で受けます。

落とし穴は、両方で同じ状態を持ってしまい、どちらが正しいか分からなくなることです。状態は ViewModel などの1か所に置き、UIKit 側・SwiftUI 側はそれを表示するだけにします。また SwiftUI では、body の中で重い計算や通信を始めないこと（何度も呼ばれる）、一覧では安定した id を付けることが性能の基本です。

Swift の並行処理は、async・await で「待つ処理」を素直に書ける仕組みです。通信の結果を待つ間もアプリは固まらず、終わったら続きが実行されます。Task { } で処理を始め、actor で「同時に1つしか触れないデータ」を作れます。

MainActor

画面の更新は必ずメインスレッドで行う決まりがあります。@MainActor を付けたクラスや関数は、メインスレッドで動くことをコンパイラーが保証します。ViewModel には @MainActor を付け、重い処理（画像の加工・大きな JSON の解析）だけを別の場所で動かすのが基本の形です。

@MainActor
final class ProfileViewModel: ObservableObject {
  @Published var user: User?
  func load() async {
    user = try? await api.fetchUser()  // 待つ間も画面は固まらない
  }
}

データ競合は、複数のスレッドが同じデータを同時に書き換えて値が壊れる不具合です。たまにしか起きず再現も難しいので、Swift 6 では型の仕組みでコンパイル時に見つけるようにしました。

Swift 6 の言語モードでは、データ競合（複数のスレッドが同じデータを同時に書き換える不具合）の可能性をコンパイル時のエラーとして出します。スレッドをまたいで渡す値は Sendable（安全に渡せる型）である必要があり、メインスレッド専用のものを別のスレッドから触るとエラーになります。最初は大量のエラーが出るので、Swift 5 モードのまま警告として有効にし、モジュールごとに少しずつ直すのが現実的です。Swift 6.2 からは、モジュール全体を既定で MainActor にする設定（Default Actor Isolation）も選べ、Xcode 26 で新しく作ったアプリのプロジェクトでは最初からこの設定になっています。アプリのコードでは注釈の手間がかなり減ります。

よくある失敗は、エラーを消すために @unchecked Sendable や nonisolated(unsafe) を安易に付けることです。これはチェックを止めるだけで、競合はなくなりません。

Swift の並行処理は構造化されていて、Task の中で始めた子の処理は親に結びつきます。親が終わるかキャンセルされると、子にもキャンセルが伝わるので、画面を閉じた後に通信が残り続けることを防げます。

キャンセルは止めてほしいという合図で、処理が勝手に止まるわけではありません。長いループでは try Task.checkCancellation() や Task.isCancelled で確かめます。URLSession の async の関数はキャンセルされると CancellationError などで終わるので、それをエラーとして画面に出さないようにします。検索欄の入力ごとに前の検索を取り消す、といった場面でよく使います。

iOS のアプリは、Apple が発行した証明書で署名しないと実機でも動きません。「ビルドはできるのに実機に入らない」「CI でだけ失敗する」の多くは署名の問題です。

1人の開発では Xcode の自動署名で十分ですが、チームや CI では、証明書を1か所で管理して配る仕組み（fastlane の match など）や、App Store Connect API のキーでの自動化を使います。証明書や鍵は CI のシークレットに置き、リポジトリには入れません。

iOS は毎年6月の WWDC で新しい版が発表され、秋に公開されます。利用者の更新が速いので、公開の日から多くの人が新しい OS でアプリを使います。

対応する最低の iOS の版は、利用者の分布を見て、毎年1つずつ上げるチームが多いです。最低の版を上げると、新しい SwiftUI の機能が使えて分岐のコードが減ります。目安は「最新とその1〜2つ前まで」ですが、自分のアプリの利用者の数字で決めます。