No meu caso, o que está em meu perfil de provisionamento:
security cms -D -i ~/Downloads/spolskyDevelop.mobileprovision
...
<key>application-identifier</key>
<string>P5GM95Q9VV.com.dca.spolsky</string>
<key>aps-environment</key>
<string>development</string>
Era diferente das coisas no aplicativo que foi realmente construído (você pode descobrir onde ele foi construído olhando a guia Logs do Xcode)
codesign -d --entitlements - '/Users/drew/Library/Developer/Xcode/DerivedData/spolsky-bdbtdfjeeywhqzccpmmceqvnhgtm/Build/Products/Debug-iphoneos/spolsky-ios.app'
<dict>
<key>application-identifier</key>
<string>Y2X6Z7Z2GR.com.dca.spolsky-ios</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>Y2X6Z7Z2GR.com.dca.spolsky-ios</string>
</array>
</dict>
Isso era verdade , embora o texto de dica "Atualmente corresponde" em Identidade de assinatura de código estivesse indicando o perfil de provisionamento correto - estranho, não? Para tornar uma história estranha ainda mais estranha, o perfil de provisionamento correto estava sendo instalado no dispositivo quando eu executei, (Configurações-> Geral-> Perfis) me levando a acreditar que o perfil de provisionamento estava certo - mas estava voltando para um ID curinga quando o aplicativo foi realmente iniciado .
A pista era a diferença na saída desses dois comandos:
Y2X6Z7Z2GR .com.dca. spolsky-ios vs P5GM95Q9VV .com.dca. spolsky
Quando fiz a correspondência da parte em negrito, a parte em itálico mudou para corresponder automaticamente. Além disso, a saída de segurança e code-sign estavam de acordo, e não havia mais erro aps-entitlement.
Meu palpite aqui é que o XCode estava usando uma correspondência de estilo curinga no meu ID não curinga. ("spolsky" é, afinal, quase "spolsky-ios"), e isso explica a saída "Corresponde atualmente". Mas algo na cadeia de construção é mais estrito sobre isso, então ele volta para um ID curinga real durante a construção.