Capacitor 8 で CocoaPods を使うには、iOS プラットフォームを次のコマンドで作成し、 bunx cap add ios --packagemanager CocoaPodsCocoaPods をインストールし(Homebrew または Bundler を使った Gemfile)、続いて bunx cap sync ios Podfile の管理と実行 pod install. Capacitor 8 でも CocoaPods は引き続き完全にサポートされています。新しいプロジェクトのデフォルトが Swift Package Manager に変わっただけです。
CocoaPods はもはや長期的な方向性ではなく、2026年12月2日には trunk が読み取り専用になります。そこで本当の論点は、いつ CocoaPods が正しい選択なのか、どう動かし続けるか、そしてどうきれいに抜けるかです。本ガイドではこの3つすべてを扱います。
CocoaPods がまだ正しい選択となるケース
以下のいずれかに当てはまるなら、CocoaPods を続けるか、選んでください:
- 必要なプラグインに
Package.swift. SPM プロジェクトでは、CLI が「インストールされている Capacitor プラグインの一部は SPM と互換性がありません」と警告してそのプラグインを除外するため、実行時に「plugin is not implemented」で失敗します。 - ベンダーの SDK が pod としてしか配布されていない場合。 一部のアナリティクス、決済、アイデンティティ系の SDK は、今も CocoaPods 専用か、自分でラップする必要のある xcframework でしか提供されていません。
- Cordova プラグインが pods に依存している場合。 Capacitor は SPM プロジェクトの Cordova プラグイン用に Swift package を生成しますが、
<podspec>依存関係が複雑なものは CocoaPods の方がうまく動く傾向があります。 - podspec の subspec に依存している ことで SDK のバリアントを選択しています。SPM には現在 package traits があり、Capacitor は CLI 8.3 以降で実験的にサポートしています( Capacitor における SPM package traitsを参照)。ただし、プラグイン側でまず traits を定義する必要があります。
- 大規模でカスタマイズされた Xcode プロジェクト で、今回のリリースサイクルでは移行のリスクに見合わない場合。
パッケージ ID の衝突もかつては理由の一つでした。CLI 8.4 以降では、SPM で experimental.ios.spm.packageOptions (symlink または moduleAliases) を Capacitor の設定に追加することで回避できます。
これらに該当しない場合は、SPM を使用してください。Ruby ツールチェーンも Podfile も不要で、 .xcworkspace.
Capacitor 8 における CocoaPods と SPM
| CocoaPods | Swift Package Manager | |
|---|---|---|
新規プロジェクトのデフォルト cap add ios |
いいえ | はい |
| 追加ツール | Ruby + CocoaPods gem | 不要、Xcode に組み込み |
| 開くプロジェクト | ios/App/App.xcworkspace |
ios/App/App.xcodeproj |
| プラグイン要件 | .podspec |
Package.swift |
| 生成ファイル | def capacitor_pods ブロック内 Podfile |
ios/App/CapApp-SPM/Package.swift |
| オプション機能 | Subspecs | パッケージ特性(Capacitorでは実験的) |
| 将来 | 2026年12月2日からTrunkは読み取り専用 | Appleサポート |
CocoaPodsのインストール
CIを含むすべての環境で、1つのアプローチを選んで一貫して使用してください。
Homebrew (1人の開発者には最も簡単):
brew install cocoapods
pod --version
Bundler (チーム全体でバージョンを固定するため、CI での使用を推奨)。 Gemfile をプロジェクトのルートディレクトリまたは ios/App:
source 'https://rubygems.org'
gem 'cocoapods', '~> 1.16'
bundle install
Capacitor CLI が Gemfile に CocoaPods が記載されている場合、 bundle exec pod install の代わりに pod installを実行します。 pod が通常と異なる場所にある場合は、 CAPACITOR_COCOAPODS_PATH をバイナリに設定してください。
CocoaPods を使用した Capacitor 8 アプリを作成
bun add @capacitor/ios
bun run build
bunx cap add ios --packagemanager CocoaPods
bunx cap open ios
cap open ios を開きます App.xcworkspace。常にワークスペースからビルドしてください。 App.xcodeproj を直接提供します No such module 'Capacitor'.
Podfile の解説
以下は Capacitor 8 が生成する Podfile です:
require_relative '../../node_modules/@capacitor/ios/scripts/pods_helpers'
platform :ios, '15.0'
use_frameworks!
install! 'cocoapods', :disable_input_output_paths => true
def capacitor_pods
pod 'Capacitor', :path => '../../node_modules/@capacitor/ios'
pod 'CapacitorCordova', :path => '../../node_modules/@capacitor/ios'
end
target 'App' do
capacitor_pods
# Add your Pods here
end
post_install do |installer|
assertDeploymentTarget(installer)
end
触れてよい部分とダメな部分:
def capacitor_pods ... endこれは CLI に属します。 同期のたびに、ブロック全体がプラグインごとに1行、podプラグインのフォルダを指す行に置き換わります。node_modules中に追加した内容はすべて失われます。- 独自のPodは次の下に追加してください:
target 'App'の後に、capacitor_pods. assertDeploymentTargetデプロイターゲットが15.0未満のPodを15.0に引き上げ、Xcodeのサポート外ターゲット警告を回避します。この設定は残して、独自のpost_installロジックを同じブロック内に追加してください。platform :iosCapacitor 8 では15.0以上が必要です。
追加のPodとビルド設定の修正例:
target 'App' do
capacitor_pods
pod 'GoogleMLKit/BarcodeScanning', '~> 7.0'
end
post_install do |installer|
assertDeploymentTarget(installer)
installer.pods_project.targets.each do |target|
if target.respond_to?(:product_type) && target.product_type == 'com.apple.product-type.bundle'
target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end
end
このループは、リソースバンドルターゲットの code signing を無効にします。これは次を修正します: Signing for "X" requires a development team リソースバンドルを同梱するpodsに適用します。そのエラーに遭遇した場合のみ追加してください。
日常のコマンド
# After installing or removing a plugin
bunx cap sync ios
# Use the exact versions in Podfile.lock (good for CI)
bunx cap sync ios --deployment
# Refresh the spec repo when a new pod version isn't found
cd ios/App && pod repo update && pod install
# Update one pod past its locked version
cd ios/App && pod update FirebaseMessaging
cap sync ios も実行されます xcodebuild clean プロジェクトに対して、 pod installの後に実行されるため、プラグイン追加後の手動クリーンは不要です。
Commit Podfile と Podfile.lock。Commitしないでください ios/App/Pods/。これはによって再生成されます pod install.
既存アプリを SPM から CocoaPods へ切り替える
逆方向のマイグレーションコマンドはありません。手動で行います:
- コミットしてからコピー
ios/安全な場所に保存してください。 - 削除
ios/. - 実行
bunx cap add ios --packagemanager CocoaPods. - ネイティブの変更を再適用:
Info.plistキー、entitlementsとcapabilities、署名チーム、bundle identifier、アプリアイコンとスプラッシュアセット、URL schemes、拡張機能(widgets、notification service)、およびカスタムSwiftなどAppDelegate. bunx cap sync iosしてビルドします。
新旧の ios/App/App フォルダを比較するのが、漏れを確認する最も早い方法です。
よくあるCocoaPodsエラーの修正
CocoaPods could not find compatible versions for pod "X". ローカルのspec repoが古いか、2つのpodが互換性のないバージョンを要求しています。以下を実行してください: pod install --repo-update における ios/App。それでも失敗する場合は、エラー内の依存関係チェーンを確認し、バージョンが厳密に固定されているプラグインを見つけて、アップグレードするか podspecをパッチする.
The sandbox is not in sync with the Podfile.lock. Run 'pod install'. この Pods フォルダがlockファイルと一致しません。通常はブランチ切り替え後です。次を実行: bunx cap sync ios.
[!] Unable to find a specification for 'X'. specリポジトリのキャッシュが古いか、pod名が間違っています。次を実行: pod repo update.
Unable to find compatibility version string for object version '70' (または 77). Xcodeプロジェクトの形式が、使用中のCocoaPods/xcodeproj gemが理解できるものより新しいです。CocoaPodsを最新リリースに更新してください。できない場合は、 project.pbxproj 設定してください objectVersion CocoaPodsがサポートする値に戻してください。
Sandbox: rsync(...) deny(1) file-write-create. XcodeのUser Script SandboxingがCocoaPodsのembedスクリプトをブロックしています。次の設定で: ビルド設定、設定する ユーザー・スクリプトのサンドボックス化 (ENABLE_USER_SCRIPT_SANDBOXING)を いいえ App ターゲットに設定します。
No such module 'Capacitor'. 開いた App.xcodeprojを開く App.xcworkspace、または実行 bunx cap open ios.
pod: command not found CI で設定してください。 ジョブ内で CocoaPods をインストールするか、キャッシュされた Bundler を使用します vendor/bundle。これがない場合、CLI は「CocoaPods がインストールされていないため pod install をスキップします」とログに記録し、後でビルドが失敗します。
その他のiOSビルドエラーについては、 Capacitor iOSトラブルシューティングガイド.
CocoaPods trunkが読み取り専用になる日
CocoaPodsのメンテナーは、中央のspecリポジトリであるtrunkを、2026年11月初旬のテスト運用を経て、2026年12月2日に読み取り専用にすると発表しました。これがCapacitorアプリに与える影響は以下の通りです:
- 既存のビルドは引き続き動作します。 公開済みのすべてのpodspecは引き続き利用可能です。
- trunk経由での新しいバージョンの公開はできなくなります。 trunkから取得しているSDK(Firebase、Google ML Kit、ベンダー提供のSDKなど)は、trunkでのアップデートが停止します。セキュリティ修正や新しいiOS SDKへの対応は、SPMやその他のチャネルを通じてのみ提供されるようになります。
- Capacitorプラグイン自体が直接影響を受けることはありません。 これらはnpmからインストールされ、
:pathPodfile内で参照されます。ただし、推移的に依存しているpodは影響を受けます。
CocoaPodsはつなぎとして扱いましょう。どの依存関係が原因でCocoaPodsに留まっているのかを洗い出し、その依存関係がSPMに対応したら見直しましょう。
CocoaPodsからの移行
準備ができたら:
bunx cap spm-migration-assistant
実行します pod deintegrate、削除します Podfile, Podfile.lock と App.xcworkspace、作成します CapApp-SPM、書き込みます debug.xcconfig。次に追加します CapApp-SPM を Xcode でローカルパッケージとして追加し、 debug.xcconfig をデバッグ設定ファイルに設定します。詳細な手順は Capacitor アプリを SPM に移行する方法、トレードオフについては Capacitor の SPM と CocoaPods 比較.
SPM対応を追加したいプラグイン開発者は、こちらを参照してください Capacitor プラグインを SPM に移行する.
ビルドマシンでのRuby、CocoaPods、Xcodeのバージョン管理が課題であれば、 Capgo のビルド 最新のXcodeでCocoaPodsおよびSPMプロジェクトをクラウドでビルドします。