Swift Package Manager入門｜使い方とPackage.swift、CocoaPods移行をSwift 6世代で解説

Swift Package Manager（SPM）は、Xcodeに同梱されたApple純正の依存管理ツールで、2026年現在は新規iOS開発で第一に選ばれる存在です。本記事では、SPMの役割からPackage.swiftの書き方、Xcodeとコマンドラインでの使い方、バージョン指定のルール、そしてSwift 6世代（6.2〜6.4）で加わった最新仕様までを整理します。あわせて、2026年12月2日にトランクが読み取り専用化するCocoaPodsからの移行判断と、SPMを選ぶべきでない場面・失敗パターンも具体的に示します。「swift package manager 使い方」「package.swift」「CocoaPods 移行」で調べている方が、自分のプロジェクトでどう導入・運用すべきかを判断できる状態をめざします。

まとめ：新規iOS開発はSwift Package Manager、CocoaPods依存は2026年12月までに移行計画

新規のiOS・macOSアプリやSwiftライブラリを作るなら、依存管理はSwift Package Managerを選べば足ります。Xcodeに統合済みで追加ツールやRuby環境が不要なこと、Appleが新規コードで推奨していること、Alamofire・Kingfisher・RxSwiftといった主要ライブラリがSPMに対応済みであることが理由です。

一方、CocoaPodsに依存している既存プロジェクトは、トランクが2026年12月2日に読み取り専用化する前に移行計画を立てるのが現実的です。既存アプリがその日を境に動かなくなるわけではありませんが、以降は依存ライブラリの新バージョンやセキュリティ修正がトランク経由で届かなくなります。SPMとCocoaPodsは同一プロジェクトで併用できるため、依存を1つずつ置き換える段階移行が安全です。

Swift Package Managerとは｜Apple純正の依存管理ツールとCocoaPods・Carthageの違い

Swift Package Managerは、Swiftで書かれたコードを「パッケージ」という単位でまとめ、依存関係を解決しながら配布・利用できるようにするツールです。2011年から使われてきたCocoaPods、その後登場したCarthageと同じ依存管理ツールの系譜にありますが、Swiftツールチェーンとビルドシステムへ最初から組み込まれている点が決定的に違います。

SPMの役割：依存解決・コンパイル・配布を担うApple純正ツールの位置づけ

SPMが担うのは、ライブラリのダウンロード、依存先のバージョン解決、コンパイル、ビルドへのリンクという一連の流れです。これらをPackage.swiftという1つの設定ファイルから自動で処理します。GitHubなどのGitリポジトリで配布されたパッケージを取り込み、importするだけで自分のコードから呼び出せる状態にします。SPM自体もオープンソースで、リポジトリはswiftlang/swift-package-managerとして公開されています。

CocoaPods・Carthageとの違い：導入方式と.xcworkspace要否の比較

SPMとCocoaPods、Carthageの違いは、導入方式とプロジェクト構成への影響に表れます。

最大の差は、SPMがXcodeとswiftコマンドに統合済みで、CocoaPodsのようなRuby製CLIやPodfile、専用の.xcworkspaceを必要としない点です。CocoaPodsはトランクが2026年12月に読み取り専用化し、Carthageも更新頻度が落ちています。新規採用の合理性は、すでにSPM側に傾いています。

2026年にSPMが新規開発の標準となった背景：Apple推奨とCocoaPods保守化

SPMが標準になった背景には、ツール側とエコシステム側の両方の動きがあります。Appleは2019年のXcode 11でSPMをiOS開発に開放して以降、WWDCのデモを一貫してSPMで行ってきました。CocoaPods側も2024年8月に保守モード入りを公表し、2025年5月にはセキュリティ上の理由でprepare_commandフィールドの新規利用を禁止しています。FirebaseはCocoaPodsへの新バージョン公開を2026年10月で止め、SPMまたは手動導入への移行を案内しています。

Package.swiftの構造と役割｜swift-tools-version・products・targets・dependencies

Package.swiftは、パッケージの名前・対応プラットフォーム・公開する成果物・依存先・ビルド対象を宣言するマニフェストファイルです。SPMはこのファイルを読み取ってバージョン制約を解決し、ソースを取得してモジュールを組み立てます。

swift-tools-version宣言：マニフェスト先頭で示すツール最低バージョン

Package.swiftは必ず// swift-tools-version:で始まる行を先頭に置きます。ここで宣言した値が、そのパッケージのビルドに必要なSwiftツールの最低バージョンと、PackageDescriptionライブラリのAPI世代を決めます。たとえばswift-tools-version: 6.0と書けば、Swift 6.0以降のツールでのみビルドでき、6.0世代のマニフェストAPIが使えます。古いツールバージョンのAPIは後方互換で残るため、新しいSwiftを入れても既存マニフェストがすぐ壊れることはありません。

products・targets・dependenciesの関係：公開単位とビルド単位、外部依存

Package.swiftの中心は、products・targets・dependenciesの3要素です。targetはビルドの最小単位（ソースやテストのまとまり）、productはtargetを束ねて外部に公開する単位（ライブラリや実行ファイル）、dependenciesは外部パッケージへの参照です。利用側はproductをimportし、product内部のtargetが依存先targetや外部パッケージを参照する入れ子構造になります。

Package.swiftの最小記述例：name・platforms・依存・ターゲット定義

最小構成のPackage.swiftは次のようになります。

// swift-tools-version: 6.0
import PackageDescription

let package = Package(
name: "MyLibrary",
platforms: [.iOS(.v17)],
products: [
.library(name: "MyLibrary", targets: ["MyLibrary"])
],
dependencies: [
.package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.0.0")
],
targets: [
.target(name: "MyLibrary", dependencies: ["Alamofire"]),
.testTarget(name: "MyLibraryTests", dependencies: ["MyLibrary"])
]
)

dependenciesでAlamofireを参照し、targetのdependenciesでそれを使う宣言をしています。targetのdependencies側に product 名を書き忘れると、importしてもコンパイル時に解決されないため、両方の記述がそろっているかを確認します。

Swift Package Managerの使い方｜Xcodeでのパッケージ追加手順とコマンドライン操作

SPMの使い方は、XcodeのGUIから操作する方法と、swiftコマンドで操作する方法の2系統です。アプリ開発ではXcode、ライブラリやCLIツールの開発ではコマンドラインが中心になります。

Xcodeでの追加手順：Add Package Dependenciesからリポジトリ指定まで

Xcodeでパッケージを追加する手順は次の通りです。

1. メニューの［File］→［Add Package Dependencies…］を選ぶ
2. 右上の検索欄にGitリポジトリのURLを入力する（GitHub以外のGitリポジトリも指定可）
3. バージョンルール（後述のUp to Next Majorなど）を選ぶ
4. 追加先のtargetを選んで［Add Package］を押す

追加した依存の情報はPackage.swiftではなく、プロジェクトファイル（.xcodeproj）内に記録されます。Project NavigatorにPackage Dependenciesの項目が現れ、取得されたバージョンを確認できます。SPMはXcodeのIDEに統合されているため、Xcode自体の機能やインストール手順はXcode 26 新機能の総覧と全体像で整理しています。

コマンドラインの基本操作：swift package init・build・run・testコマンド

コマンドラインでは、空のパッケージを作るswift package initから始めます。--type libraryや--type executableでテンプレートを選べます。ビルドはswift build、生成物の実行はswift run、テストはswift testです。Swift 6世代ではビルドの裏側がSwift Buildバックエンドに切り替わり、SPMの既定ビルドエンジンになりました。

パッケージの更新と解決：swift package updateとPackage.resolvedの役割

依存の更新と解決もコマンドで行えます。swift package resolveは記録済みバージョンを取得する操作で、CocoaPodsのpod installに相当します。swift package updateは各依存を許可範囲内の最新へ更新する操作で、pod updateに相当します。解決結果はPackage.resolvedに記録され、これをGitにコミットしておくとチーム全員が同じバージョンでビルドできます。Xcodeでは［File］→［Packages］→［Update to Latest Package Versions］が同じ役割を果たします。

依存パッケージのバージョン指定とSwift Package Index活用｜from・範囲・ブランチの使い分け

依存パッケージは、どのバージョンまで自動更新を許すかを指定して追加します。指定方法の選び方が、ビルドの安定性と更新の取り込みやすさを左右します。

バージョン指定の5方式：from・厳密・範囲・ブランチ・コミットの使い分け

バージョン指定には主に5つの方式があります。

from指定は最も一般的で、「次のメジャーバージョン未満まで自動更新」を意味します。範囲指定は上限が含まれない点に注意が必要で、"1.2.3"..<"1.2.6"は1.2.5までです。ブランチ・コミット指定は再現性が下がるため、検証用途に限るのが無難です。

本番推奨のUp to Next Major：安定性と更新取得を両立する指定基準

本番アプリで迷ったら、from指定（Up to Next Major）を基準にします。メジャーバージョンが上がらない限り、互換性を壊さない範囲でバグ修正と機能追加を取り込めるためです。特定バージョンで挙動を固定したい依存だけexact指定にし、混在させて管理します。複数人開発では、Package.resolvedをコミットして実際に取得されたバージョンを固定するほうが、指定方式そのものより確実な再現性の担保になります。

Swift Package Indexでの探索：互換性とメンテ状況の確認手順

パッケージを探すときは、Swift Package Index（swiftpackageindex.com）が起点になります。ここでは各パッケージの対応プラットフォーム、Swiftバージョン互換性、最新リリース日、ビルドの成否が一覧で確認できます。候補が複数あるときは、メンテナンスが止まっていないか（直近のリリース日）と、自分のtools-versionでビルドが通るかを先に確認すると、追加後の手戻りを減らせます。RxSwiftのように広く使われるライブラリでも、用途や互換性は事前に把握しておくと安全です。RxSwiftとは？リアクティブプログラミングの基本概念では、代表的な依存ライブラリの位置づけを確認できます。

Swift 6世代で変わった最新仕様｜言語モード・パッケージレジストリ・バイナリ配布の要点

Swift 6世代（2024年のSwift 6.0以降、WWDC26で6.3と6.4が同時公開）では、SPMのマニフェストとビルドにいくつかの実務的な変更が入りました。古い解説記事のままでは取りこぼす要点を整理します。

tools-version 6.0の変更：swiftLanguageModesへの改称と段階的移行

tools-version 6.0では、従来のswiftLanguageVersionsが非推奨となり、swiftLanguageModesへ改称されました。あわせて言語モードをtarget単位で指定できるようになり、パッケージ全体を一度にSwift 6モードへ移すのではなく、targetごとに段階移行できます。大規模パッケージで並行性チェックのエラーを一度に浴びずに済むよう、移行ペースを自分で制御できるのが利点です。

tools-version 6.2の追加：strictMemorySafetyとdefaultIsolation

tools-version 6.2では、SwiftSettingに2つの設定が加わりました。strictMemorySafetyは、SE-0458で導入された厳格なメモリ安全性チェックを有効にする設定です。defaultIsolationは、SE-0466に基づきtargetの既定アクター分離を指定する設定で、並行性の既定挙動をパッケージ側でそろえられます。どちらもtools-versionを6.2以上に上げたパッケージでのみ使えます。

パッケージレジストリと署名付きパッケージ：SE-0391とTOFU検証

SPMは、Gitリポジトリからの取得に加えて、パッケージレジストリへの公開・取得にも対応しました（SE-0391の公開仕様）。あわせて署名付きパッケージをサポートし、TOFU（Trust On First Use）検証はフィンガープリント（チェックサム）だけでなく署名元の識別情報まで含めて、ソースアーカイブとマニフェストの双方で強制されます。社内に閉じたレジストリを運用する組織では、取得元の真正性を担保しやすくなります。

バイナリターゲットとXCFramework：ビルド時間を分単位で短縮する効果

ビルド時間が課題になる大型依存には、バイナリターゲット（XCFramework）の配布が効きます。たとえばWebRTCをソースから取り込むとクリーンビルドに15〜25分かかる一方、XCFrameworkのバイナリとして配布すれば1分未満に短縮できるという報告があります。Package.swiftでは.binaryTargetでローカルパスまたはURLとチェックサムを指定します。CIのビルド時間が伸びてきたら、依存の一部をバイナリ化する判断が現実的です。

CocoaPodsからの移行判断と失敗パターン｜2026年12月の読み取り専用化に備える進め方

CocoaPodsに依存している既存プロジェクトをどう扱うかは、2026年に避けて通れない判断です。結論から言えば、新規はSPM、既存は期限前の段階移行です。

2026年12月2日の読み取り専用化：既存アプリへの影響と更新停止の範囲

CocoaPodsのトランクは、2026年12月2日に永久に読み取り専用化します。当日を境に、新しいPodの公開と既存Podの更新がトランク経由でできなくなります。ただし、既存アプリがその瞬間に壊れるわけではありません。すでに公開済みのバージョンは引き続き取得・ビルドでき、稼働中のアプリにも影響しません。実害が出るのは、依存ライブラリの新機能やセキュリティ修正がトランクから届かなくなる点です。保守モード入りは2024年8月、prepare_commandの新規利用禁止は2025年5月に実施済みで、今回の読み取り専用化はその延長線上にあります。

SPMとCocoaPodsの併用移行：依存を1つずつ置き換える現実的手順

移行は一度に行う必要はありません。SPMとCocoaPodsは同じプロジェクトで併用できるため、次の順で1つずつ置き換えるのが安全です。

1. 現在のPodfileを棚卸しし、各依存がSPMに対応しているかを確認する
2. SPM対応済みかつ依存の浅いライブラリから、Xcodeでパッケージ追加して置き換える
3. 置き換えたライブラリをPodfileから外し、ビルドとテストが通るか確認する
4. SPM非対応の依存は、手動導入やバイナリ化など代替手段を個別に検討する
5. すべて移行できたらCocoaPods関連ファイル（Podfile・.xcworkspace等）を削除する

分析・課金・地図系SDKなど、CocoaPodsのインストールスクリプトに強く依存する依存は移行が重くなりがちです。期限直前に全件をまとめて移行すると検証時間が足りなくなるため、依存数が多いプロジェクトほど早めに着手します。

SPMを選ぶべきでない場面と失敗パターン：非対応残存・ネスト依存・resolve肥大

SPMが常に最適とは限りません。採用を見送る、あるいは慎重になるべき場面があります。第一に、主要依存の一部がSPM非対応で、かつ代替が存在しない場合です。この状態で無理に移行すると、一部だけCocoaPodsを残す中途半端な構成になり、かえって管理が複雑になります。第二に、ローカルパッケージを細かく分割しすぎたモノレポ構成です。パッケージがネストして依存グラフが膨らむと、resolveに時間がかかりCIが遅くなります。モジュール分割は機能のまとまり単位にとどめ、1ファイル単位でのパッケージ化は避けます。第三に、branchやcommit指定の依存を本番に残すパターンです。再現性が下がり、ある日突然ビルドが変わる事故につながるため、本番ではバージョンタグ指定に統一します。

よくある質問

Swift Package Managerについて検索で多い質問を5つ取り上げます。

Swiftとは何ですか？どの企業が開発した言語ですか？

SwiftはAppleが2014年に発表したプログラミング言語で、iOS・macOSをはじめとするApple製プラットフォームのアプリ開発に使われます。現在はオープンソースで、サーバーサイドや組み込み、Android向けSDKなどクロスプラットフォームでも利用が広がっています。Swift Package Managerは、このSwiftのツールチェーンに同梱された純正の依存管理ツールです。

Xcodeでパッケージのバージョンを更新するにはどうしますか？

Xcodeでは、メニューの［File］→［Packages］→［Update to Latest Package Versions］で、各依存を許可された範囲内の最新へ更新できます。コマンドラインならswift package updateが同じ役割です。更新後はPackage.resolvedの差分を確認し、意図しないバージョン変更がないかをチェックしてからコミットします。

FlutterアプリでSwift Package Managerは利用できますか？

Flutterは長らくiOS側の依存管理にCocoaPodsを使ってきましたが、Flutterチームは公式にSPM対応を進めており、新しいバージョンではSPMを利用できます。プラグインの対応状況によってはCocoaPodsとの併用が必要な場面も残るため、利用中のFlutterとプラグインがSPMに対応しているかを確認したうえで切り替えます。

Swift Package ManagerとCocoaPodsは同じプロジェクトで併用できますか？

併用できます。実際、CocoaPodsからSPMへ移行する際は、両者を同居させながら依存を1つずつ置き換えるのが一般的な進め方です。SPMで追加した依存とCocoaPodsで管理する依存が混在していてもビルドは成立します。ただし長期的に併用し続けると管理が二重になるため、移行の過渡期に限るのが望ましい運用です。

SPMで追加した依存パッケージの情報はどこに記録されますか？

XcodeのGUIから追加した場合、依存の情報はプロジェクトファイル（.xcodeproj）内に記録され、Package.swiftには書かれません。一方、Swiftパッケージ自体を開発している場合は、依存はPackage.swiftのdependenciesに記述します。いずれの場合も、実際に解決されたバージョンはPackage.resolvedに記録され、これをGitで共有することでチーム間のバージョン差を防げます。

関連記事

• RxSwiftとは？リアクティブプログラミングの基本概念とフレームワーク：SPMで導入する代表的なSwiftライブラリの一つ。リアクティブプログラミングの基礎を解説しています。
• Xcode 26 新機能の総覧と全体像：SPMが統合されたXcode本体の最新機能とインストール手順を網羅しています。