Repository navigation
Unable to tns publish ios #2922
Description
here's the command i'm using:
echo "================ PREPARE ===============" && \
tns prepare ios --provision ...redacted profile id... && \
echo "================ PUBLISH ===============" && \
tns publish ios ...redacted user... ...redacted password... ...redacted profile id... "iPhone Distribution"
My xcconfig:
// You can add custom settings here
// for example you can uncomment the following line to force distribution code signing
// To build for device with Xcode 8 you need to specify your development team. More info: https://developer.apple.com/library/prerelease/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME = LaunchImage;
DEVELOPMENT_TEAM = ...redacted team id...
CODE_SIGN_IDENTITY = iPhone Distribution: ...redacted company name ..., LLC (...redacted team id...)
PROVISIONING_PROFILE = ...redacted profile id...
APP_PROFILE = ...redacted profile id...
TARGETED_DEVICE_FAMILY = 1
CODE_SIGN_ENTITLEMENTS = quickridensmobile/quickridensmobile.entitlements
Build fails on the CI machine (Circle CI) with the following:
=== BUILD TARGET GTMSessionFetcher OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Sign error: Provisioning profile does not match bundle identifier: The provisioning profile specified in your build settings (“App Store Provisioning Profile”) has an AppID of “com.gosuna.quickride.DriverApp” which does not match your bundle identifier “org.cocoapods.GTMSessionFetcher”.
=== BUILD TARGET PocketSocket OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Sign error: Provisioning profile does not match bundle identifier: The provisioning profile specified in your build settings (“App Store Provisioning Profile”) has an AppID of “com.gosuna.quickride.DriverApp” which does not match your bundle identifier “org.cocoapods.PocketSocket”.
=== BUILD TARGET GoogleToolboxForMac OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Sign error: Provisioning profile does not match bundle identifier: The provisioning profile specified in your build settings (“App Store Provisioning Profile”) has an AppID of “com.gosuna.quickride.DriverApp” which does not match your bundle identifier “org.cocoapods.GoogleToolboxForMac”.
=== BUILD TARGET Protobuf OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Sign error: Provisioning profile does not match bundle identifier: The provisioning profile specified in your build settings (“App Store Provisioning Profile”) has an AppID of “com.gosuna.quickride.DriverApp” which does not match your bundle identifier “org.cocoapods.Protobuf”.
It used to work. And still works on my local environment(s) (laptop and workstation).
Activity
PanayotCankov commentedon Jun 28, 2017
Hi,
This will not fix the signing problem, but have in mind that
tns prepare ios --provisionwill set the provisioning profile you provide along with "Manual Signing Style" in the pbxproj in platforms/ios. It will be with higher precedence over the pbxproj settings, so in general you should either have the DEVELOPMENT_TEAM , CODE_SIGN_IDENTITY, PROVISIONING_PROFILE etc. in the xcconfig, or you should have none of them and configure the project using the --provision switch.On the other hand we had similar problems with Cocoapods in the past. We were passing the signing identity and provisioning profile with flags to the underlying
xcodebuildcommand, and since the build was multi-target build, it tried to sign and provision each and every target, including the pods. Now the pods obviously can not share the same id as your app, and trying to sign them and apply the distribution provisioning profile fails. The framework produced by the Cocoapod should not be signed during build. It should be signed by the app target when they are added to the app as embedded frameworks, and this will not apply the provisioning profile to them, it will just sign with the same certificate used for the app. Publishing either through the Xcode UI or through the {N} CLI involves building archive out of the project and then exporting the app (that is re-signed in the process) for distribution. So in general you should not use the .pbxporj nor --provision to set distribution sertificates or provisioning profiles when publishing, you can have the development certificates there (tns prepare --provisionor xcconfig) and provide the distribution certificates totns publish ios ...these will be used when the app is extracted from the archive. So to narrow things down:Use
tns prepare --provision <with-development-provision>or set the xcconfig to use development certificate and provisionUse
tns publish ios <distribution certificate, provision etc.>, it will export the app with whatever xcconfig or --provision you provided first, and then it will extract app for App Store distribution using the distribution certificates.I don't know why the build tries to provision and sign the Cocoapods but chances are if you use a wildcard provision for development it will manage to provision the Cocoapods framework and strip the signature when exporting for distribution.
Check the Cocoapods, ruby, python, node and tns versions on you CI machine, this may be an issue with the Cocoapod that may already be fixed.
briandilley commentedon Jul 5, 2017
I made this change, still no luck. I'll try with 3.1 today.
briandilley commentedon Jul 5, 2017
Still no luck
briandilley commentedon Jul 11, 2017
I noticed that
tns prepare --provision XXXlaunches a simulator (but still works) on my local machine... i wonder if that's the problem on the CI machinebriandilley commentedon Aug 10, 2017
All of this works for me now after having removed the fabric plugin and the firebase plugin. Those plugins caused a number of issues for me that were resolved as soon as i removed them.
dtopuzov commentedon Aug 14, 2017
@briandilley
Happy to hear you resolved the problem.
If you think that issue is caused by specific plugin you can log the issue in plugin's repo.
btw, we had some issues with distribution and adhoc provisioning profiles that are fixed in
nativescript@nextso you can give it a try once again.Steps: