Swift Testing LinuxとmacOS CIはどう分担する？2026年ガイド

LinuxではSwift Packageのテストが通るのに、Appleプラットフォーム向けの検証範囲が曖昧です。 最短の分担方法は、Apple SDKに依存しないテストをLinuxへ、Xcode・Simulator・署名が必要な検証をmacOSへ置くことです。

クロスプラットフォームのSwift Packageを保守し、共通テストをLinux CIに残したい開発者向けです。 Appleプラットフォームのアプリを開発し、Swift TestingとXcode CIの境界を決めたいエンジニアにも役立ちます。 macOSのCI実行環境を増やす前に、必要なタスクを切り分けたいDevOps担当者も対象です。

Swift TestingのLinux・macOS CIは依存関係で分けます

Swift Testingの公式情報にはLinuxとAppleプラットフォームのサポートが記載されています。ただし、これはすべてのテストや依存ライブラリがLinuxで動くという保証ではありません。対象コード、テストコード、依存パッケージのそれぞれが、実行先のプラットフォームに対応しているかを確認してください。Swift Testing公式リポジトリのプラットフォーム情報とSwift.orgのプラットフォームサポート表は、対応範囲を確認する出発点になります。

判定は「Swift Testingを使っているか」ではなく、テストが何を呼び出し、何を検証するかで行います。Swift Package Managerのマニフェストで宣言するプラットフォーム要件も確認し、実際の依存関係と食い違っていないか見直します。PackageDescriptionのプラットフォーム設定は、パッケージの対応先を整理する際に参照できます。

Swift TestingはLinux CIで実行できますか？

実行できます。ただし、対象がLinuxで利用できるAPIと依存パッケージに限られる場合です。文字列処理やデータ変換など、Appleプラットフォームのフレームワークや固有の挙動を必要としないテストなら、既存のLinux CIに含める候補になります。

「Swift TestingがLinuxをサポートしている」という情報だけで、テストターゲット全体を移すのは避けてください。テストファイルにApple専用APIが含まれていたり、依存パッケージが特定プラットフォーム向けだったりすると、ビルドまたは実行時に差が出ます。テストを含むターゲットと依存パッケージの両方を、実行対象プラットフォームと照合します。

どのテストをmacOS Runnerに残すべきですか？

UIKitやSwiftUIなどAppleのフレームワーク、Apple SDK、Xcodeのビルド機能に依存するテストは、対応するAppleプラットフォームの環境で検証します。たとえばUIKitを使うコードは、UIKitのAPIやプラットフォーム上の挙動を前提にするため、Linuxでコンパイルできたことを実機能の検証に置き換えることはできません。UIKitの公式ドキュメントで対象APIを確認し、必要なテスト環境を切り分けてください。

対比しておくと、判断がぶれにくくなります。

• Linux向き： Apple SDKを参照しない純粋なロジック、対応する依存パッケージだけで完結するテスト。適合度は高めです。
• macOS・Xcode向き： Apple SDKを使うビルド、Simulatorでの実行、アプリのUI検証、署名を含む処理。適合度は高めです。
• 両方で確認： 共通コードでも、条件コンパイルや依存ライブラリの違いが結果に影響する場合。片側の結果だけでは不十分です。

この評価は実行速度や性能の比較ではなく、タスクの依存条件に基づく適合度です。Xcodeは複数種類のテストを扱い、テスト対象をプロジェクト内に追加して構成できます。Xcodeのテスト概要とテストターゲットの追加手順を確認し、Packageの単体テストとアプリの検証を別の仕事として扱います。

Linuxの結果だけでXcodeテストを代替できますか？

代替できません。Linuxで成功したという結果が示すのは、その環境で実行され、成功したテスト範囲です。Apple SDKを使うアプリのビルド、Simulator上の動作、UI自動化などは、対応するXcode環境で別途確認する必要があります。

iOSアプリやmacOSアプリでは、ビルド対象のSDKと実行先を合わせて検証してください。Simulatorまたは物理デバイスでの実行を含むテストは、その実行条件まで確認します。AppleのSimulator・物理デバイスでの実行ガイドを参照し、Linuxのテスト成功をAppleプラットフォーム向けの合格証跡として扱わないようにします。

共有コードはテスト対象と証跡を分けます

同じSwift Packageでも、条件コンパイルや依存パッケージの利用可能範囲によって、プラットフォームごとにビルドされるコードが異なることがあります。テスト名が同じでも、実際に通ったコードパスやアサーションまで同じとは限りません。

そこで、CIの結果には「ジョブが成功したか」だけでなく、どのコミットで、どのテストターゲットとテスト集合を実行したかを残します。テストプランを使う構成では、フィードバックの目的ごとにテストを整理する方法も確認できます。Xcodeのテスト整理に関するガイドを参考に、両方の環境で何を実行したか追跡できる状態にします。

Linux CIとmacOS CIをどう分けますか？

次のチェック項目に沿って、テストごとに実行先を決めます。

• [ ] テスト対象と依存パッケージがLinuxで利用でき、Apple SDKを参照しない → Linux CIに割り当てます。
• [ ] ビルドやテストにApple SDK、Xcode、Simulator、UI検証、署名のいずれかが必要 → macOS上のXcode CIに割り当てます。
• [ ] 共通コードに条件コンパイル、プラットフォーム依存のパッケージ、異なるOS上の挙動がある → 必要なテストをLinuxとmacOSの両方で実行します。
• [ ] 実行先を決められない、または必要なAPIがLinuxで使えるか確認できない → 依存関係を調べ、Appleプラットフォーム固有の処理はmacOSで検証します。

導入は、まずリポジトリ内のテストターゲットを洗い出し、各ターゲットのAPIと依存パッケージを確認するところから始めます。次に、Linuxだけで完結するテストとApple環境が必要なテストを分類します。その後、Linux側の既存ジョブは共通テストに使い、Xcodeを要するタスクをmacOS側へ割り当てます。

最後に、両方のジョブが同じコミットを対象にしていること、実行したテスト集合が記録されること、ビルド成果物とテストレポートを照合できることを確認します。片方のCIだけが新しいコミットを検証している状態では、二つの成功表示を一つの検証結果として扱えません。

注意：条件コンパイルがある場合は、テスト名の一致だけで実行範囲を判断しないでください。各環境で実際にビルドされたコードと実行されたアサーションを記録します。

遠隔Macを追加する前に実タスクで判定します

Linux CIにAppleプラットフォーム向けの検証を追加したい場合は、先に対象プロジェクトの実タスクを一つ選びます。Xcodeでのビルド、Simulatorを使うテスト、署名を含む処理など、macOSが必要な作業を実行し、ビルド結果とテストレポートを確認してください。

遠隔Macを検討する際は、必要なツールチェーンを導入できるか、CIから必要な方法で接続できるか、ジョブの証跡を保存できるかを要件として整理します。環境の違いも選定条件になるため、実機と仮想化環境の特徴を比較する場合はMacの実行環境を選ぶための解説も参照してください。

LinuxだけのCIを続けると、Apple SDKのビルドやSimulator検証をカバーできず、別のMacを手元で維持すると、使わない時間もハードウェアの管理対象になります。Apple専用タスクが断続的に必要なら、MacDateのリモートMac環境を使い、実際のビルドとテストが要件を満たすか確かめてから導入範囲を決められます。一方、常時重い処理を回す場合や物理ポートへの直接接続が必須の場合は、手元のMacなど別の運用方法も含めて比較してください。