Xcode「signed with invalid entitlements」の原因と解決方法

The application was signed with invalid entitlements.

The application's signature contains invalid entitlements.

Entitlements specified in your application's Code Signing Entitlements file do not match those specified in your provisioning profile.

「signed with invalid entitlements」とは

Entitlementsは、AppがApple Platform上で利用する特別な権限やCapabilityをCode Signatureへ記録する仕組みです。

例えばApp Groupsなら：

<key>com.apple.security.application-groups</key> <array> <string>group.com.example.myapp</string> </array>

Push Notificationsなら、署名時に：

aps-environment

が関係します。

Appが要求するEntitlementは、Provisioning Profileが許可している範囲内でなければなりません。

例えばAppが：

group.com.example.myapp

というApp Groupを要求しているのに、Profileには：

group.com.example.otherapp

しか含まれていなければ、SigningされたEntitlementsが無効と判断される可能性があります。

代表的な発生状況

• App Groupsを追加した直後
• Push Notificationsを追加した直後
• Associated Domainsを追加した直後
• Keychain Sharingを追加した直後
• iCloudを追加・変更した直後
• Sign in with Appleを追加した直後
• Capabilityを手動で.entitlementsへ追加した
• Automatic SigningからManual Signingへ変更した
• Bundle Identifierを変更した
• Developer Teamを変更した
• 古いProvisioning Profileを使用している
• Extension Targetだけ古いProfileを使用している
• Debugでは動くがRelease・Archiveで失敗する
• Localでは動くがCIだけ失敗する
• Ad HocやDistribution Buildだけ失敗する

主な原因

1. Provisioning ProfileとEntitlementsが一致していない

最も典型的な原因です。

App側：

com.apple.security.application-groups = [ group.com.example.myapp ]

Profile側：

com.apple.security.application-groups = [ group.com.example.other ]

のような不一致です。

2. Capability追加後も古いProfileを使用している

例えばPush NotificationsやApp Groupsを追加する前に作成したProvisioning Profileでは、新しく追加したEntitlementが含まれていないことがあります。

3. Entitlements Fileへ手動でKeyを追加した

例えば：

<key>com.apple.developer.associated-domains</key> <array> <string>applinks:example.com</string> </array>

を直接追加しただけで、Developer Portal側のApp ID Capabilityを設定していない場合です。

4. App Group Identifierが違う

App側：

group.com.example.debug

Developer Portal側：

group.com.example.production

のような不一致です。

5. Bundle Identifierを変更した

例えば：

com.example.oldapp

から：

com.example.newapp

へ変更したものの、旧App ID用のProvisioning Profileを使用している場合です。

6. Teamが違う

Development TeamとProvisioning Profileを発行したTeamが一致していない場合、Application IdentifierやKeychain Access Groupなども不整合になります。

7. application-identifierが一致していない

Signing後のEntitlementsには：

application-identifier

が含まれることがあります。

通常は：

TEAMID.com.example.myapp

のような値になります。

Team IDやBundle IdentifierがProfileと違うとSigning Errorにつながります。

8. keychain-access-groupsが一致していない

Keychain Sharingを使うAppでは：

keychain-access-groups

もSigning設定との整合性が必要です。

9. Push Notificationsのaps-environmentが不正

DevelopmentとDistributionではProvisioning Profileに応じて適切な値が署名されます。

Source Entitlementsへ：

<key>aps-environment</key> <string>development</string>

などを理由なく固定していると、Distribution Signingで問題になる場合があります。

10. Associated Domains CapabilityがProfileへ反映されていない

App側に：

com.apple.developer.associated-domains

が存在するのにProfileが許可していない場合です。

11. iCloud Containerが別App用

Entitlementsに設定したiCloud Containerと、App IDに関連付けられたContainerが一致していないケースです。

12. App Extensionで別のEntitlementsが必要

Main AppとWidget、Share Extension、Notification Service Extensionなどは別Executableとして署名されます。

Main Appだけ正しくてもExtension側が不正ならInstallやArchiveに失敗する場合があります。

13. DebugとReleaseでCODE_SIGN_ENTITLEMENTSが違う

例えば：

Debug: MyApp-Debug.entitlements

Release:
MyApp.entitlements

となっていて、Release側だけ古い設定が残っているケースです。

14. .xcconfigから別Entitlements Fileを指定している

CODE_SIGN_ENTITLEMENTS = Config/Old.entitlements

のような設定が残っていることがあります。

15. CIで古い.mobileprovisionを使用している

Local XcodeのAutomatic Signingでは最新Profileを使用していても、CIへ固定で保存したProvisioning Profileが古ければCIだけ失敗します。

16. EntitlementsをBuild中に変更している

Run Script、PlistBuddy、sedなどでBuild途中にEntitlementsを書き換えると、Signing時の内容が期待と異なる可能性があります。

17. Wildcard App IDでは使えないCapabilityを利用している

一部Capabilityでは：

com.example.*

のようなWildcardではなく：

com.example.myapp

のようなExplicit App IDが必要です。

18. Managed Capabilityの利用条件を満たしていない

一部CapabilityはAppleの承認が必要です。

Entitlementを手動で追加しても、対象Team・App IDに許可されていなければ有効なProfileを作成できません。

まず確認すること

1. Signing & Capabilitiesを確認する

Xcodeで：

Project → Target → Signing & Capabilities

を開きます。

次を確認します。

• Team
• Bundle Identifier
• Automatically manage signing
• 追加済みCapability

2. Code Signing Entitlementsを確認する

Build Settingsで：

Code Signing Entitlements

を検索します。

Build Setting名は：

CODE_SIGN_ENTITLEMENTS

です。

3. ErrorがどのTargetから出ているか確認する

Main Appとは限りません。

例えば：

MyApp MyWidget ShareExtension NotificationService

のどのTargetが失敗しているかReport Navigatorから確認します。

解決方法1：Automatic Signingを有効にする

特別な理由がなければ：

Target → Signing & Capabilities → Automatically manage signing

を有効にします。

正しいTeamを選択し、必要なCapabilityをSigning & Capabilitiesから追加します。

Xcodeが対応するSigning Assetを管理しやすくなります。

解決方法2：問題のCapabilityを削除して追加し直す

例えばApp Groupsなら：

Signing & Capabilities → App Groups

を一度削除し：

+ Capability → App Groups

から再追加します。

Automatic Signing環境では、EntitlementsとProvisioning Profileが更新される場合があります。

解決方法3：Developer PortalのApp ID Capabilityを確認する

Apple Developerの：

Certificates, Identifiers & Profiles → Identifiers → App ID

を開きます。

対象Bundle Identifierで必要なCapabilityが有効になっているか確認します。

解決方法4：Provisioning Profileを再生成する

Manual Signingの場合、App IDのCapabilityを変更したらProvisioning Profileを再生成します。

概ね：

Certificates, Identifiers & Profiles → Profiles → 対象Profile → Edit → Generate

または新しいProfileを作成します。

解決方法5：新しいProfileをXcodeへ反映する

再生成したProfileをDownloadし、Signingで新しいProfileが使われていることを確認します。

古いProfileを明示指定している場合は：

PROVISIONING_PROFILE_SPECIFIER

も確認します。

解決方法6：不要なEntitlementを削除する

使用していないCapabilityが.entitlementsへ残っている場合は削除します。

例えばApp Groupsを使わないなら：

com.apple.security.application-groups

を無理にProvisioning Profileへ追加する必要はありません。

解決方法7：Entitlementsを手動編集しすぎない

Capabilityを使う場合、まず：

Signing & Capabilities → + Capability

から追加できないか確認してください。

Xcodeが必要なEntitlement Keyを管理することでTypoや不要Keyを減らせます。

解決方法8：App Groupsを正しいIdentifierへ修正する

例えば：

<key>com.apple.security.application-groups</key> <array> <string>group.com.example.myapp</string> </array>

なら、Developer Portalで同じ：

group.com.example.myapp

が対象App IDへ関連付けられているか確認します。

解決方法9：Push NotificationsをSigning & Capabilitiesから設定する

Push Notificationsを利用するなら：

Signing & Capabilities → + Capability → Push Notifications

から追加します。

Manual SigningではDeveloper PortalのApp IDも更新し、Profileを再生成します。

解決方法10：aps-environmentをむやみに固定しない

Source Entitlementsへ：

<key>aps-environment</key> <string>development</string>

を理由なく手動追加・固定するのは避けます。

Push Notifications CapabilityとProvisioning Profileに基づいてSigning設定を正しく構成してください。

解決方法11：Associated Domainsを正しく設定する

Xcodeで：

Signing & Capabilities → Associated Domains

を追加し：

applinks:example.com

などを設定します。

Manual SigningならApp ID CapabilityとProfileも更新します。

解決方法12：Keychain Sharingを確認する

Keychain Sharingを利用する場合：

keychain-access-groups

に、Team IDやAccess Groupの不正な値が入っていないか確認します。

通常はSigning & Capabilitiesから設定する方が安全です。

解決方法13：Bundle Identifierを一致させる

Xcodeの：

PRODUCT_BUNDLE_IDENTIFIER

とProvisioning ProfileのApp IDを確認します。

例えばApp：

com.example.myapp

なら、そのApp ID用のProfileを使用してください。

解決方法14：Teamを一致させる

Xcodeの：

DEVELOPMENT_TEAM

と、Provisioning Profileを作成したTeamが一致しているか確認します。

解決方法15：DebugとReleaseのSigning設定を比較する

Build Settingsで：

• CODE_SIGN_STYLE
• CODE_SIGN_ENTITLEMENTS
• DEVELOPMENT_TEAM
• PROVISIONING_PROFILE_SPECIFIER
• PRODUCT_BUNDLE_IDENTIFIER

をDebug・Releaseそれぞれ確認します。

解決方法16：Archiveだけ失敗する場合はReleaseを確認する

次を開きます。

Product → Scheme → Edit Scheme → Archive

使用ConfigurationがReleaseなら、Release側のSigningとEntitlementsを確認します。

解決方法17：ExtensionごとにSigningを確認する

例えば：

MyApp MyWidget NotificationService

がある場合、各Targetについて：

• Bundle Identifier
• Team
• Provisioning Profile
• CODE_SIGN_ENTITLEMENTS
• Signing & Capabilities

を確認してください。

解決方法18：Provisioning ProfileのEntitlementsを確認する

Provisioning ProfileをProperty Listへ変換します。

security cms -D \ -i MyApp.mobileprovision \ > /tmp/profile.plist

Entitlementsを表示します。

/usr/libexec/PlistBuddy \ -c "Print :Entitlements" \ /tmp/profile.plist

これによりProfileが実際に許可しているEntitlementsを確認できます。

解決方法19：署名されたAppのEntitlementsを確認する

Build後の.appに対して：

codesign -d \ --entitlements :- \ /path/to/MyApp.app

を実行します。

Sourceの.entitlementsではなく、最終Code Signatureに入った値を確認できるため非常に有効です。

解決方法20：Profileと署名済みAppを比較する

次の2つを比較します。

security cms -D -i MyApp.mobileprovision

codesign -d --entitlements :- MyApp.app

特に確認する項目：

• application-identifier
• com.apple.developer.team-identifier
• keychain-access-groups
• com.apple.security.application-groups
• aps-environment
• com.apple.developer.associated-domains

解決方法21：Archive内のembedded.mobileprovisionを確認する

実際にArchiveした.appには通常：

MyApp.app/embedded.mobileprovision

があります。

これを確認すれば、「Xcode上ではこのProfileを選んだつもりだった」という推測ではなく、実際に組み込まれたProfileを確認できます。

security cms -D \ -i /path/to/MyApp.app/embedded.mobileprovision \ > /tmp/embedded-profile.plist

解決方法22：App Identifierを確認する

Profile内：

/usr/libexec/PlistBuddy \ -c "Print :Entitlements:application-identifier" \ /tmp/profile.plist

を確認します。

期待するTeam IDとBundle Identifierになっているか確認してください。

解決方法23：CIのProvisioning Profileを更新する

Localだけ成功する場合、CIへ保存されたProfileが古い可能性があります。

Capability変更後に生成した新しいProfileへ置き換えます。

Fastlane MatchなどでSigning Assetを管理している場合は、RepositoryやStorageへ最新Profileが反映されているか確認してください。

解決方法24：CIのEntitlements Fileを確認する

CIだけ別.xcconfigを使用している場合：

CODE_SIGN_ENTITLEMENTS

がLocalと違うFileを指していないか確認します。

解決方法25：xcodebuildで実際のSigning設定を確認する

xcodebuild \ -project MyApp.xcodeproj \ -scheme MyApp \ -configuration Release \ -showBuildSettings | grep -E "CODE_SIGN|ENTITLEMENTS|PROVISIONING|DEVELOPMENT_TEAM|PRODUCT_BUNDLE_IDENTIFIER"

Archive時の最終Build Setting確認に利用できます。

解決方法26：古いProvisioning Profileを削除して再取得する

Automatic SigningでXcodeが古いProfileを選んでいる疑いがある場合、不要なLocal Profileを整理して再Buildすると、新しいProfileを取得できる場合があります。

一般的な保存先：

~/Library/MobileDevice/Provisioning Profiles/

解決方法27：EntitlementsをBuild中に書き換えない

次のような処理：

/usr/libexec/PlistBuddy ... sed -i ... cp generated.entitlements MyApp.entitlements

をxcodebuild実行中に行わないようにします。

Environmentごとに値が違うなら、別Entitlements Fileを用意します。

解決方法28：ConfigurationごとにEntitlementsを分ける

例えば：

MyApp-Debug.entitlements MyApp-Staging.entitlements MyApp-Release.entitlements

を用意し：

Debug: CODE_SIGN_ENTITLEMENTS = MyApp/MyApp-Debug.entitlements

Release:
CODE_SIGN_ENTITLEMENTS =
MyApp/MyApp-Release.entitlements

のように固定します。

解決方法29：Wildcard App IDを見直す

Capabilityによっては：

com.example.*

では利用できません。

必要に応じて：

com.example.myapp

というExplicit App IDを使用します。

解決方法30：Managed Capabilityの承認状態を確認する

CarPlayなど一部CapabilityではApple側の承認が必要です。

Developer PortalでApp IDへ対象Capabilityが付与されているか確認し、必要であればCapability Requestの状態を確認します。

承認されていないEntitlementを手動で.entitlementsへ書いても正常に署名できません。

App Groupsで発生する場合

App Groups関連なら、まず：

com.apple.security.application-groups

を確認します。

確認順：

1. Signing & CapabilitiesのApp Groups
2. .entitlements内のGroup Identifier
3. Developer PortalのApp Group
4. App IDとApp Groupの関連付け
5. Provisioning Profileの再生成
6. 最終署名済みAppのEntitlements

Push Notificationsで発生する場合

確認項目は：

aps-environment

です。

基本的には：

1. Signing & CapabilitiesへPush Notificationsを追加
2. App IDでPush Notificationsを有効化
3. Provisioning Profileを更新
4. 新しいProfileで再Signing

の順で確認します。

Associated Domainsで発生する場合

確認項目：

com.apple.developer.associated-domains

Signing & CapabilitiesからAssociated Domainsを設定し、Manual SigningならApp IDとProfileも更新してください。

Keychain Sharingで発生する場合

次を確認します。

keychain-access-groups

Team ID Prefixを含む値が、Provisioning Profileと最終署名済みAppで一致しているか比較します。

iCloudで発生する場合

iCloudでは複数のEntitlementが関係する場合があります。

• com.apple.developer.icloud-container-identifiers
• com.apple.developer.icloud-services
• com.apple.developer.ubiquity-kvstore-identifier

Container、App ID、Provisioning Profile、Entitlementsの組み合わせを確認してください。

「実機だけInstallできない」場合

SimulatorではCode Signing条件が実機と異なるため、Simulatorで動作していても実機Install時にEntitlements Errorが出ることがあります。

実機でだけ失敗する場合は：

• Provisioning Profile
• Development Team
• Device登録
• App ID
• Signed Entitlements

を優先して確認します。

「Debugは成功するがArchiveは失敗する」場合

典型的にはRelease Signing設定の差です。

確認：

Product → Scheme → Edit Scheme → Archive

そのConfigurationに対応する：

• Provisioning Profile
• CODE_SIGN_ENTITLEMENTS
• DEVELOPMENT_TEAM
• Bundle Identifier

を確認します。

「Localは成功してCIだけ失敗する」場合

次を疑います。

• CIに保存された古い.mobileprovision
• 古いSigning Certificate
• 別Team ID
• 別Bundle Identifier
• CI専用.xcconfig
• Build中にEntitlementsを変更するScript

Clean Build Folderで直るか

Signing AssetやEntitlementsそのものが不正なら：

Product → Clean Build Folder

だけでは解決しません。

Signing設定を修正した後の補助策として使用します。

DerivedData削除は必要か

Signing設定を正しく直しても古いBuild Artifactが疑われる場合：

rm -rf ~/Library/Developer/Xcode/DerivedData/*

を補助的に利用できます。

ただしProvisioning ProfileがEntitlementを許可していない場合、DerivedDataを削除しても直りません。

やってはいけない対処

Entitlementを増やすほど解決するわけではありません。

逆にProvisioning Profileが許可していないEntitlementを追加すると、このErrorの原因になります。

また、Application IdentifierやTeam Identifierなど、Signing Processによって決まる値をSource Entitlementsへ手動で固定するのも避けてください。

最短で確認するチェックリスト

1. Errorが発生しているTargetを確認する
2. Signing & Capabilitiesを確認する
3. Automatically manage signingを確認する
4. Teamを確認する
5. Bundle Identifierを確認する
6. CODE_SIGN_ENTITLEMENTSを確認する
7. .entitlementsの不要Keyを確認する
8. Developer PortalのApp ID Capabilityを確認する
9. Capability変更後ならProvisioning Profileを再生成する
10. App Groups Identifierを確認する
11. Push Notificationsを確認する
12. Associated Domainsを確認する
13. Extension Targetを確認する
14. security cmsでProfile内Entitlementsを確認する
15. codesignで最終AppのEntitlementsを確認する
16. ProfileとSigned Entitlementsを比較する
17. DebugとReleaseのSigning設定を比較する
18. CIの古いProfileを確認する
19. Build中にEntitlementsを書き換えていないか確認する
20. 修正後に新しいBuild・Archiveを作成する

まとめ

Xcodeの「signed with invalid entitlements」は、Appへ署名されたEntitlementsが、Provisioning ProfileやApp IDによって許可された内容と一致していない場合に発生します。

代表的な原因は、古いProvisioning Profile、手動で追加した不正なEntitlement、App GroupsのIdentifier違い、Bundle IdentifierやTeamの不一致、Push Notifications・Associated Domains・iCloudなどのCapability設定不足です。

まずSigning & Capabilities、Team、Bundle Identifier、CODE_SIGN_ENTITLEMENTSを確認してください。

Automatic SigningではCapabilityをXcodeから正しく設定し、Profileを再取得します。Manual SigningではDeveloper PortalのApp ID Capabilityを更新し、Provisioning Profileを再生成します。

原因が分からない場合は、security cmsでProvisioning ProfileのEntitlementsを確認し、codesign -d --entitlements :-で最終Appへ署名されたEntitlementsを確認して比較する方法が非常に有効です。

Clean Build FolderやDerivedData削除は補助策です。本質的な解決方法は、Appが要求するEntitlements、App ID Capability、Provisioning Profile、実際のCode Signatureを一致させることです。