Xcode 27でSwift Packageのchecksum不一致が出て、依存パッケージの取得が止まることがあります。
まず、Package.swiftのURLから取得したZIPが宣言時の公開物と同一か確認し、その正確なファイルからchecksumを再計算してください。再圧縮や差し替えが判明した場合は、古いURLのファイルを上書きせず、新しい不変バージョンを公開します。Appleはchecksumの対象をバイナリ成果物のアーカイブとして説明しています。checksumの対象と計算方法
対象となるのは、リモートのXCFrameworkを使い、依存取得時に検証エラーが出ているアプリ開発者、Swift Packageのバイナリを公開する保守担当者、Xcode 27のCIやリモートMacビルドを管理する担当者です。
ソースコードの取得失敗、ZIPのchecksum不一致、取得後のコンパイル失敗を切り分けたい場合にも役立ちます。
Xcode 27 Swift Packageのchecksum不一致を段階別に切り分ける
checksumエラーは、ビルド失敗という点では似ていても、原因が同じとは限りません。最初にログの失敗段階を特定し、依存の取得前後で何が起きたかを分けて記録します。
| 見えている症状 | 主に確認する担当 | 最初に照合する証拠 |
|---|---|---|
| Swift Packageのソース取得や解決で停止する | アプリ開発者、CI担当者 | パッケージの参照先、バージョン、解決結果 |
| ZIPのchecksumが宣言値と一致しない | アプリ開発者、パッケージ保守担当者 | Package.swiftのURL、実際に取得したZIP、公開履歴 |
| 依存取得後にビルドやリンクで失敗する | アプリ開発者 | コンパイルログ、プラットフォーム別のXCFramework構成 |
binaryTargetは名前、URL、checksumを指定する宣言です。したがって、エラーがchecksum検証時に起きているなら、まずソースパッケージのコードや後続のコンパイル設定ではなく、指定されたURLとアーカイブの組み合わせを調べます。binaryTargetの引数
checksumとダウンロードしたZIPが異なる場合、どこから調べますか。
Package.swiftに書かれたURL、実際のリクエスト先、取得ファイルのchecksumを同じ記録に並べます。転送先がリダイレクトされていないか、プロキシなどを経由して別のファイルが返されていないかも確認し、ログに残ったURLだけでなく、検証に使われたファイルそのものを特定します。
アプリ開発者は取得した依存を固定して確認する
アプリ側で確認するのは、マニフェストの記述とビルド時に取得された成果物の対応です。キャッシュ削除から始めると、元の失敗を再現する証拠が消えたり、別の成果物を取得して一時的に通っただけなのか判断しにくくなったりします。
- [ ] エラー全文と発生段階を保存し、ソース取得、checksum検証、コンパイルのどこで止まったか記録します。
- [ ]
Package.swiftのbinaryTarget名、URL、checksumを、対象プロジェクトのブランチまたはコミットと合わせて控えます。 - [ ] 失敗したビルドが解決したパッケージのバージョンと依存解決状態を確認します。
- [ ] 宣言URLから実際に取得されるアーカイブを確認し、リダイレクトや配布経路の違いを調べます。
- [ ] Appleが案内する
swift package compute-checksumで、取得したアーカイブファイルのchecksumを計算し、宣言値と照合します。checksum計算の公式説明 - [ ] 修正後、同じプロジェクトの固定したコミットをクリーンな状態でビルドし、エラーが再現しないことを確認します。
binaryTargetのchecksumは、XCFrameworkを展開した中身に対して計算しますか。
照合するのは、XCFrameworkのディレクトリではなく、それを格納して配布するアーカイブファイルです。圧縮済みZIPを再作成すると、展開後のファイル構成が同じでもアーカイブ自体は変わり得るため、公開URLから入手できるZIPを対象に計算してください。Appleの説明でも、対象はバイナリアーティファクトのアーカイブです。Swift Packageとしてのバイナリフレームワーク配布
キャッシュを消すのは、宣言と配布物の対応を確認した後です。調査前に削除する場合は、失敗ログ、解決結果、取得先URLを先に保存し、何を消したのかを記録してください。
パッケージ保守担当者は公開物を変えずに修正する
公開側では、checksumを計算したファイルと、利用者がURLから取得できるファイルが完全に同じか確認します。計算後にZIPを作り直した、同じURLのファイルを差し替えた、あるいは別ブランチが可変URLを共有している場合は、宣言値だけの修正では解決しません。
Appleのバイナリフレームワーク配布手順を参照し、公開用のXCFrameworkアーカイブ、ダウンロードURL、Package.swiftの宣言が同じリリースに対応しているか確認します。バイナリフレームワークの作成と配布
次のように、生成から公開までを同じレビュー対象として扱います。
- 生成したXCFrameworkをアーカイブし、公開候補のファイルを確定します。
- 確定したアーカイブに対してchecksumを計算し、値を記録します。
- 公開先から取得したファイルでもchecksumを計算し、生成時の記録と一致することを確かめます。
Package.swiftに正しいURLとchecksumを記載し、変更対象のバージョンとともにレビューします。- 公開後に同じURLからアーカイブを再取得し、マニフェストとの対応を確認します。
依存パッケージを更新したのにchecksumエラーが残る場合は、どう切り分けますか。
新しいバージョンのマニフェストだけでなく、そのバージョンのURLが実際に返すZIPも確認します。旧URLのファイルが上書きされていた場合は、新しい不変のバージョンと配布先を用意し、アプリ側の依存参照もその公開物に合わせて更新します。古いリリースを利用するプロジェクトがあるなら、旧バージョンの取得経路を残す運用も必要です。
CI・リモートMac担当者は同じ条件で再現する
ローカルだけで失敗する、またはCIだけで失敗する場合、直ちにXcode 27の一般的な不具合とは判断できません。依存の解決状態、参照先URL、ネットワーク経路、実行したコミットが異なれば、取得されるアーカイブも違う可能性があります。
Appleは、継続的インテグレーションでSwift Packageを利用するワークフローの説明を公開しています。CIの設定と依存の取得記録を照合し、想定したコミットと解決状態で実行されたか確認してください。CIでSwift Packageを使う際の公式案内
リモートMacで正しいバージョンが取得されたかは、何を見れば分かりますか。
ビルドログに残るコミット、依存バージョン、要求URL、リダイレクト後の取得先、checksum検証の失敗段階をローカルの記録と比較します。ネットワークに接続できない問題と、取得できたZIPのchecksumが異なる問題は別です。前者は取得経路、後者はアーカイブと宣言の対応を調べます。
Xcode Cloudを利用する構成では、依存パッケージをビルド環境から利用できる条件もAppleの案内で確認します。Xcode Cloudで依存関係を利用する条件 また、Xcode 27に関するツールチェーンの変更や修正の有無は、個別の失敗から推測せず、AppleのXcode 27リリースノートで確認してください。
更新前に公開と受け入れの条件をそろえる
複数のバージョンやリリースブランチを保守する場合、可変URLを共有すると、ある版の更新が別の版の依存を壊す原因になります。アーカイブ、checksum、URL、マニフェストを版ごとに対応づけ、公開後の置き換えを避けてください。
- [ ] 対象バージョンの
Package.swiftと配布アーカイブを一組として管理します。 - [ ] checksumを計算したファイルと公開URLから取得したファイルが一致することを確認します。
- [ ] 旧版のURLやファイルを無断で差し替えず、新しい成果物には新しい版の参照先を用意します。
- [ ] 同じコミットをクリーンな環境で再ビルドし、依存取得からコンパイルまでを確認します。
- [ ] ログ、依存解決結果、公開したアーカイブを残し、問題発生時に元の状態へ戻せるようにします。
Xcode 27のchecksumエラーでは、原因が宣言、配布アーカイブ、取得経路のどこにあるかを証拠で切り分けるのが先決です。最終更新は2026年10月8日で、Appleのchecksum文書とXcode 27リリースノートを確認しています。個別環境の失敗だけを、Xcode 27全体の欠陥とみなすものではありません。
まずは対象プロジェクトと固定したコミットで、依存のダウンロードからビルドまでを再現してください。ローカルにmacOSやXcodeの検証環境がなく、短期間だけ実機相当のmacOS環境が必要なら、RUVCLOUDのMac環境を候補として確認できます。継続的な重負荷ビルドや物理機器との接続が必要な場合は自前のMacが適することもあるため、利用期間と運用条件を照らし合わせてから、料金と利用条件を含めて判断してください。