メインコンテンツへスキップ

Capacitor 8 で CocoaPods を使う方法(そして使うべきでない場面)

Capacitor 8 で CocoaPods を使う:CocoaPods iOS プロジェクトの作成、Podfile の管理、pod install エラーの修正、そして CocoaPods trunk の読み取り専用化への備え。

Capacitor iOSプロジェクトでCocoaPodsとSwift Package Managerの選択を示すイラスト

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 :ios Capacitor 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 へ切り替える

逆方向のマイグレーションコマンドはありません。手動で行います:

  1. コミットしてからコピー ios/ 安全な場所に保存してください。
  2. 削除 ios/.
  3. 実行 bunx cap add ios --packagemanager CocoaPods.
  4. ネイティブの変更を再適用: Info.plist キー、entitlementsとcapabilities、署名チーム、bundle identifier、アプリアイコンとスプラッシュアセット、URL schemes、拡張機能(widgets、notification service)、およびカスタムSwiftなど AppDelegate.
  5. 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からインストールされ、 :path Podfile内で参照されます。ただし、推移的に依存している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プロジェクトをクラウドでビルドします。

Capacitor アプリ向けの Live Updates

Web レイヤーのバグが本番で発生したら、App Store の審査を何日も待たずに Capgo で修正を配信しましょう。ネイティブの変更は通常の審査フローに残したまま、ユーザーはバックグラウンドでアップデートを受け取れます。

最新のブログ記事

Capgoは、真にプロフェッショナルなモバイルアプリを作るために必要な最高のインサイトを提供します。