Thank you @benjfromlondon for showing me the way! I had the same issue while building using the Xcode@5 in Azure Pipelines although the project was otherwise configured as it should and as many StackOverflow threads indicated it should.
I will add below more information about how I fixed the issue and troubleshooting.
The fix
The Xcode@5 Azure Pipelines task does not sign the archive by default:
# Signing & provisioning
#signingOption: 'nosign' # 'nosign' | 'default' | 'manual' | 'auto'. Signing style. Default: nosign.
#signingIdentity: # string. Optional. Use when signingOption = manual. Signing identity.
So I added the following to my Yaml pipeline: (signingOption, signingIdentity and provisioningProfileName)
- task: Xcode@5
displayName: 'Build IPA'
inputs:
actions: 'clean build'
configuration: 'Release'
sdk: 'iphoneos'
xcWorkspacePath: 'ios/MyApp.xcworkspace'
workingDirectory: '$(Build.SourcesDirectory)'
scheme: 'MyApp'
packageApp: true
signingOption: 'manual'
signingIdentity: 'iPhone Distribution'
provisioningProfileName: '${{ parameters.provisioningProfileName }}'
Troubleshooting and checking the fix
According to this Q/A there are a couple of ways to check that the entitlement is present in the ipa. Unzip the .ipa first, then you can run the following commands:
security cms -D -i "Payload/MyApp.app/embedded.mobileprovision"
codesign -d --entitlements :- "Payload/MyApp.app"
The first command checks the entitlements in the provisioning profile used for code signing when exporting the ipa. It did include the aps-environment entitlement both before and after the fix.
The second command checks the entitlements in the app bundle (unsure exactly where). It did not output the aps-environment before adding the code signing identity to the archive build, but did after I specified the code signing identity (and I could check in the build logs that the Xcode@5 task did pass the code signing identity parameters to xcodebuild during archiving).
I then uploaded the .ipa to the App Store and the warning was gone.
