Kotlin 2.4.10 iOSビルド：2026年のリモートMac CIをどう導入するか
WindowsまたはLinuxを主な開発環境として使いながら、Kotlin MultiplatformのiOS成果物だけを実Macへ渡す構成を解説します。Framework生成、Xcodeテスト、署名済みArchive、キャッシュ分離、再起動後の復旧を、各段階の入力と合格条件で確認できます。
目次
Kotlin公式のリリース情報では、この記事の対象である Kotlin 2.4.10 は2026年7月14日公開の安定版として扱われています。公式リリース一覧を基準にするなら、今週はWindowsまたはLinuxで共有コードを開発し、iOS Framework、シミュレーター検証、Xcodeテスト、Archiveだけを、Xcodeを完全に導入した実Macへ送る構成を組むべきです。
この方法なら、主力環境を買い替えずに済みます。ただし、遠隔のMacを単なるデスクトップ代替品として扱うのではなく、Apple向け成果物を検証する独立CIノードとして設計することが重要です。
対象読者と役割分担
WindowsまたはLinuxを主力にして、Kotlin MultiplatformでiOSアプリを納品する開発者向けです。
Kotlin/NativeとXcodeをCIへ接続したいモバイルDevOps担当者、共有Macの認証情報やキャッシュを管理するプラットフォーム責任者にも適しています。
共有コードの編集、Gradleによる静的検査、一般的なユニットテストは主力環境に残せます。一方、Apple SDKを使うFramework統合、シミュレーターの起動、Xcodeテスト、署名、ArchiveはmacOS側へ分離してください。Kotlin公式のマルチプラットフォームプロジェクト構成でも、共通コードとプラットフォーム固有コードを分けて管理する考え方が示されています。
最初に固定する成果物流
- 主力環境から送るもの：Gitリポジトリ、Gradle設定、依存関係のロック情報、ビルドパラメーター
- Mac側で生成するもの：Framework、XCFramework、テストログ、
xcresult、Archive - CIへ返すもの：機械可読なテスト結果、署名済み成果物、失敗時のログ
- 置かないもの：証明書、秘密鍵、App Store Connect用の認証情報、個人のローカルパス
全く新しい作業ディレクトリへクローンし、Apple向けビルド段階まで進めることを境界テストにします。既存のDerived Dataや開発者個人の設定がないと進めないなら、CIノードとしては未完成です。
Kotlin/Native Frameworkの生成設計
iOSターゲットと成果物
iosArm64は実機向け、iosSimulatorArm64はApple Silicon上のシミュレーター向けとして扱います。Kotlin公式のネイティブターゲット対応表を確認し、単一ターゲットの成功だけで納品可能と判断しないでください。
| 確認対象 | 主な用途 | 合格条件 |
|---|---|---|
iosArm64 |
iPhoneなどの実機用Framework | 実機向け構成で生成され、Xcodeから読み込める |
iosSimulatorArm64 |
Apple Silicon Mac上のシミュレーター | シミュレーター起動後にモジュールをロードできる |
| XCFramework | 複数のApple向けバイナリを配布 | 対象アーキテクチャを含み、別の作業ディレクトリでも再利用できる |
FrameworkをXcodeプロジェクトへ直接組み込む構成は、単一アプリで変更をすぐ反映したい場合に向いています。独立Frameworkは複数アプリで共有しやすく、XCFrameworkは社内配布やバイナリ依存に向きます。生成タスクの詳細はKotlin公式のネイティブバイナリ生成手順に合わせてください。
Xcode統合とCI接続
直接統合、CocoaPods、バイナリ依存
リポジトリ内でGradleとXcodeプロジェクトを一緒に管理するなら、直接統合によって共有コードの変更を同じジョブで反映できます。CocoaPodsを採用している場合はPodspec、依存解決、生成タスクの実行順を固定し、バイナリ依存ではXCFrameworkの取得元とバージョンを明示します。
Kotlin公式のiOS統合方式の比較を参照し、チームのリポジトリ構造に合わせて選んでください。SPMを使う場合も、Swift Packageとしてのエクスポート方法を確認し、開発者のホームディレクトリを参照する設定をCIへ持ち込まないことが大切です。
次の関係をリポジトリ内で確認します。
- Xcode Build Phaseが、Framework生成タスクの完了後に実行されるか
- SchemeがCI用に共有され、対話的な設定に依存していないか
- DebugとReleaseで参照するFrameworkの場所が固定されているか
- 共有コードを変更した後、iOSアプリが新しいFrameworkを読み込むか
注意：手元で一度ビルドできても、ユーザー固有のパス、キーチェーン状態、未コミットの設定ファイルが残っていれば再現性はありません。全新規クローンから同じ成果物を作れることを先に確認してください。
テストとシミュレーター検証
「Kotlin Multiplatform iOSアプリをローカルMacなしで構築できるか」という問いには、条件付きで可能と答えられます。共有コードの検査はWindowsやLinuxでも進められますが、Kotlin/NativeのiOSターゲット、シミュレーター、Xcodeテスト、署名済みArchiveはMacノードが必要です。
テストは一つの巨大なジョブにまとめず、責任範囲で分割します。
commonTest：共通ロジックの検査。主力環境で早く失敗させる- Kotlin/Nativeテスト：Apple向けバイナリ生成とネイティブ境界を確認する
- Xcodeテスト：Swift側の統合、画面起動、依存Frameworkの読み込みを確認する
- シミュレーター検証：対象ランタイム、ターゲットアーキテクチャ、グラフィカルセッションを確認する
シミュレーターは、SSHセッションだけで常に対話的デバッグできるとは限りません。CIでは画面を見ることより、テストログとxcresultを保存し、失敗したテストを後から再現できることを優先します。AppleのXcodeでビルドと実行を行うための公式資料に沿って、Schemeと実行先を明示してください。
Archiveと署名の段階設計
CIへ組み込む手順
以下の順序で、入力、成果物、停止条件を別々に記録します。
- リポジトリを新規ディレクトリへ取得し、依存関係を解決する
- GradleでiOS FrameworkまたはXCFrameworkを生成する
- Xcodeプロジェクトへ成果物を組み込み、統合テストを実行する
xcodebuild archiveでArchiveを作成する- Export処理を行い、アプリ識別子、署名、埋め込みFrameworkを検査する
- 失敗段階のログと中間成果物を保存し、同じコミットで再実行する
署名アカウントは日常開発用とCI用に分離します。証明書やプロビジョニングプロファイルをリポジトリへ保存せず、秘密鍵を通常のビルドログへ出力しないでください。Appleの配布用ワークフロー資料と登録済みデバイス向け配布資料を使い、Export方法と対象を先に固定します。
最終的な合格条件は、開発者のクリックなしでArchiveと成果物検査が完了し、失敗時に公開処理へ進まず、同じコミットから安全に再実行できることです。
キャッシュ、共有資源、復旧
Kotlin iOSビルドのキャッシュは一種類ではありません。Gradle依存関係、Kotlin/Native関連キャッシュ、XcodeのDerived Data、CocoaPodsやSwift Packageの依存キャッシュを分けて扱います。保存する前に、ログでヒットしたキャッシュと再生成されたファイルを確認してください。
共有Macでは、ジョブごとに作業ディレクトリ、Derived Data、シミュレーター、署名リソースを分離します。GitHub Actionsを使う場合は、セルフホストRunnerのラベル設定でiOS専用ノードへジョブをルーティングし、一般のLinux Runnerへ誤配信しないようにします。
経験上、キャッシュを残すこと自体を成功条件にしてはいけません。キャッシュを無効にした全新規ビルドが通り、キャッシュ有効時にも同じFrameworkとArchiveの検査結果になることが先です。
SSH接続が切れた場合でも、CIジョブがSSH端末の寿命に依存してはいけません。さらに、主力環境から次の復旧試験を実施します。
- SSHを切断してもジョブが継続するか確認する
- Macを再起動し、Runnerまたは接続サービスが戻るか確認する
- 新しいジョブを再配分し、同じラベルで受け付けるか確認する
- 全く新しい作業ディレクトリでFrameworkとArchiveを再生成する
- 同じ署名資源を複数ジョブが奪い合わないことを確認する
導入判断用の比較表
| 運用方式 | Windows/Linux側の担当 | Mac側の担当 | 向いている条件 | 評価 |
|---|---|---|---|---|
| 主力環境だけ | 共有コードと通常の検査 | なし | iOS成果物をまだ作らない | 低 |
| 必要時だけMacを使う | 開発とCI起動 | Framework、テスト、Archive | リリース頻度が低く、まず検証したい | 高 |
| 専用の遠隔Mac CI | 開発、ジョブ管理、成果物確認 | Apple向け全工程 | 継続的なビルドと再実行が必要 | 最高 |
| Mac miniを自社運用 | 開発と設備管理 | Apple向け全工程 | 物理接続や長期固定負荷が必須 | 条件付き |
費用は単純なCPU性能ではなく、稼働時間、保守担当者の作業、故障時の切り替え、署名資源の管理まで含めて比較します。短期の検証ならレンタル、長期間にわたり高頻度で固定負荷をかけるなら自社Mac、物理デバイス接続が必要なら手元設備という切り分けが現実的です。
| 段階 | 入力 | 生成物 | 停止条件 |
|---|---|---|---|
| 依存解決 | ロックファイル、PodまたはSPM設定 | 依存キャッシュ、解決ログ | 差分や未固定依存がある |
| Framework | Gradle設定、共有コード | FrameworkまたはXCFramework | 対象アーキテクチャ不足 |
| Xcodeテスト | Scheme、テスト設定 | xcresult、ログ |
モジュール読み込み失敗 |
| Archive | Release設定、署名資源 | .xcarchive |
署名またはBundle検査失敗 |
| Export | Archive、配布設定 | 配布用アプリ | 識別子、署名、埋め込み内容の不一致 |
今週の導入チェック
| 検証項目 | 実施内容 | 合格の証拠 |
|---|---|---|
| 新規クローン | 既存キャッシュなしで取得 | Apple向けタスクまで完走 |
| XCFramework | 実機用とシミュレーター用を生成 | 生成ログとアーキテクチャ一覧 |
| Xcode CI | SchemeをCLIから実行 | xcresultと終了コード |
| 署名Archive | 秘密情報をログへ出さずに作成 | ArchiveとExport検査結果 |
| 復旧 | SSH切断、再起動、再配分を実施 | 同一コミットの再実行記録 |
今週は、まず独立した遠隔Macへ新規クローンを作り、共有コードの変更が新しいFrameworkとしてiOS側へ届くところまで確認してください。その後にXcodeテスト、署名、Archiveを追加し、最後に再起動復旧を行います。各段階で証拠が残らない場合は、次の段階へ進まず設定を戻すのが安全です。
WindowsやLinuxだけで完結する構成は、共有コード開発には合理的ですが、Apple SDK、シミュレーター、Xcode署名、Archiveを外部サービスや不安定な個人Macへ分散すると、ローカルパス依存、認証情報の混在、復旧時の手作業という弱点が残ります。特にリリース直前だけMacを探す運用では、同じコミットを再現できないことが最大のリスクです。
実際にノードを選ぶ際は、Apple Silicon搭載Macの利用候補で接続方式と運用条件を確認し、CIジョブが要求するSSH接続、Runner、Xcode環境を先に照合してください。必要な期間だけ実Macを確保するなら、VPSMACの日本語向けMacレンタル案内から新規クローン、XCFramework、Xcode CI、Archive、再起動復旧を順に検証する方法が適しています。
検証が通った後に、継続利用する専用CIノードへ移行するか、自社Macを購入するかを判断すれば、不要な設備投資と未検証の署名運用を避けられます。