ERROR ITMS-90046 using xctool / xcodebuild vs XCode Archive's success - ios

I've got a command line script I use to compile, archive and submit my ios builds to ITC for TestFlight deployment. They work great, but I recently ran into an issue when trying to use an embedded framework within my otherwise working project. My script compiles and archives the project successfully but is getting ITC signing errors because of the embedded binary conflict.
xctool -workspace $BASE_DIR/$PROJECT_NAME -scheme $SCHEME -configuration $CONFIG clean archive -archivePath ./$PRODUCT_NAME.xcarchive
xcodebuild -exportArchive -archivePath ./$PRODUCT_NAME.xcarchive -exportPath $PRODUCT_NAME -exportFormat ipa -exportProvisioningProfile "$DIST_PROVISIONING_PROFILE_NAME"
# result is successful, with .ipa file generated
After a successful compilation my script tries to upload to ITC, and fails with the below msg. I get the same message if I try to upload the generated IPA file to ITC myself using Application Loader tool.
ERROR ITMS-90046: "Invalid Code Signing Entitlements. Your application
bundle's signature contains code signing entitlements that are not
supported on iOS. Specifically, value 'XXXXXXXXX.com.domain.Product'
for key 'application-identifier' in
'Payload/Product.app/Frameworks/Charts.framework/Charts' is not
supported. This value should be a string starting with your TEAMID,
followed by a dot '.', followed by the bundle identifier.
There is no application-identifier string used in my project or settings that I can find with a global search.
Extra Info
com.domain.Product would be my project's main bundleIdentifier, which has a distribution certificate and provisioning profile generated for it. Without the embedded binary that works just fine. The "Charts" embedded project has a bundleIdentifier but the team is set to "None" in the Info tab, and signing is set to Automatic. Since it is an embedded binary/framework, I'm assuming it doesn't independently sign it. When using Xcode's Archive, it is listed as a subset of the main Project with no independent identifier or entitlements.
I have also tried creating an independent appId and distribution provisioning profile for the embedded binary called "com.domain.ProductCharts" and setup the project correctly. This does not change the error.
I have further tried setting the embedded binary's project to use the same bundleIdentier and settings as the parent Project, but this does not change the error.
Why is xctool/xcodebuild unable to properly compile and sign this to get through to ITC, while the native Archiver can?

Currently, I encountered what I think is a bug in xcodebuild command similar to this, way I fixed it for me was to setup provisioning profile in the project settings. Try updating your project and run build again.
The investigation into the issue was here: https://forums.developer.apple.com/thread/14378
But others reported problem with associated domains:
SO question: Apple Store submit fails with Error ITMS-90046, but Associated Domains is not among entitlements
What is your OS, XCode ... etc?

Just a guess: Maybe you need to specify an application-identifier in your Entitlements.plist if you use the command line. Here https://developer.apple.com/library/ios/qa/qa1710/_index.html it is stated that in "In modern versions of Xcode.."
You said:
They work great, but I recently ran into an issue...
Have you created a new profile meanwhile and now there are two? Or two certificates? Here is a description on how to check your entitlements. Maybe this helps.

Creating .entitlements for the embedded framework will solve the issue only in Xcode 7.x. In the version 8.x the issue still exists.

Related

Xcode signing using Jenkins

I am trying to sign and archive my Unity application with Jenkins. I have the Xcode jenkins plugin installed and everything seems to run well except for a strange problem.
During the xcodebuild phase, when the archive should be signed, I get the following error:
error: No signing certificate "iOS Development" found: No "iOS
Development" signing certificate matching team ID "QF6V2M666X" with a
private key was found. (in target 'Unity-iPhone')
Now the problem is that I am not trying to build for development, but for production. I have a production provisioning profile used, which is pointing the production certificate. The team id is the production team id (changed here for security reasons). Here is another part of the build output:
Going to invoke xcodebuild:, scheme: Unity-iPhone, sdk: DEFAULT,
project: DEFAULT, configuration: Release, clean: NO, archive:YES,
consolelog:YES, symRoot: DEFAULT, buildDir: DEFAULT,
developmentTeamID: QF6V2M666X
[sr-ios] $ /usr/bin/xcodebuild -scheme
Unity-iPhone -configuration Release archive -archivePath
When I open the project in Xcode, I can see that for some reason Xcode selects "IOSDeveloper" in the code signing identities part and not "IOSDistribution" (or the actual certificate in the provisioning profile):
I don't know if this can be changed from Jenkins, but I think Xcode should pick this up from the provisioning profile.
So I managed to find the problem and solve it, here is the solution for others.
In Unity 2018 they added a new option to the iOS player settings, in the "Other settings" section, called IOS Provisioning Profile->Profile type:
This option is used to select the signing identity. I guess you can use "Automatic" but in my case, since I am using Jenkins, I am setting it on a build script like this:
PlayerSettings.iOS.iOSManualProvisioningProfileType =
ProvisioningProfileType.Distribution;
When this option is set, xcode is able to sign the app correctly for distribution.

xcode9 requires a provisioning profile

I am using xcode plugin (version 2.0.1) with jenkins to generate our builds for multiple targeted app.
With Xcode 9, our jenkins build configuration is able to generate the archive but fails to create the ipa. The error message is as follows:
Error Domain=IDEProvisioningErrorDomain Code=9 ""test.app" requires a provisioning profile." UserInfo={NSLocalizedDescription="test.app" requires a provisioning profile., NSLocalizedRecoverySuggestion=Add a profile to the "provisioningProfiles" dictionary in your Export Options property list.}
I have already added the provisioning profile inside Jenkins Custom xcodebuild arguments section by passing the PROVISIONING_PROFILE, PROVISIONING_PROFILE_SPECIFIER, CODE_SIGN_IDENTITY, CODE_SIGN_STYLE and DEVELOPMENT_TEAM however, it still shoots the same error message. Besides, I also pass the ExportOptions.plist file in the Build phases Run script option but it seems that Xcode generates its own ExportOptions.plist(enterpriseTEAMIDExport.plist) and ignores mine. When I open enterpriseTEAMIDExport.plist file it only contains the teamid and the method of export and so, it doesn't find the provisioning profile.
So, how can I tell xcode to use my ExportOptions.plist file instead? I have followed the image here but unable to find it inside Xcode 9. Also, this post doesn't relate to me.
Another important thing is that I am able to generate the ipa using my own ExportOptions.plist file from command line xcodebuild tool using this command as follows:
xcodebuild -exportArchive -archivePath archive.xcarchive -exportPath /my/export/path -exportOptionsPlist options.plist
So, I don't know why it doesn't work with Jenkins Xcode plugin.
Any help is much appreciated.
Thanks!

How to build and sign an iOS app on separate machines?

We have an iOS app which is built using a series of Bash scripts run by Jenkins. As things are today, we build an xcarchive using this command:
xcodebuild archive -workspace "..." -scheme "..." -configuration "Release" -archivePath "..."
This builds the app and signs it using the certs specified in the provisioning profile which is set using an xcconfig. Once it is complete, we then turn it into an IPA using:
xcodebuild -archivePath "..." -exportArchive -exportOptionsPlist "${export_options_plist}" -exportPath "..."
This IPA can then be uploaded to Hockey or to the App store depending on the xcconfig we use (we swap them out to create different builds).
We now want to make sure our certificates are kept safe as much as possible. This means we want to perform the build on one machine, but the signing on another. In order to do that, we need to do this:
Create an unsigned xcarchive
Transfer the xcarchive to the signing machine
Turn the xcarchive into a signed IPA
Step 2 can be ignored for now though, so lets just focus on steps #1 and #3.
Creating the unsigned xcarchive can be done by adding the arguments CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO to the archive command.
Signing the IPA is much trickier though. We assumed we could just create the IPA again and use the codesign command to sign the binary in the IPA. This had a couple of problems though. The first is that the .entitlements file we had for the app wasn't respected. We had to pass this as a flag to the signing command. Then we realised that we had to correct all the variables in the .entitlements file since Xcode was no longer replacing them with the correct values. Then we realised that we had to do this for each extension we had.
We finally got this all working, with the correct entitlements, replacing the variables and everything was signed, but when I tried uploading the new signed IPA to Hockey it rejected it. The error message wasn't helpful either.
We diff'ed a build with the previous system with the new system and each binary was different. We're not sure if this is a codesigning issue, or just a timestamp change, but there are changes. Furthermore, we discovered that my extensions are all missing archived-expanded-entitlements.xcent files, plus possibly more issues.
It definitely seems like we are going about this the wrong way. We clearly shouldn't have to re-do everything just to sign on a different machine, so where are we going wrong? How are we supposed to build on one machine and sign on another?
P.S. Our current tools use xcodebuild directly, but we have support for fastlane for other parts of our build process, so we are happy to use it if needed.
Update: We have a "solution" to this which is to sign the Release builds with a dev cert, then resign them using the distribution one. This solves all the problems with entitlements being populated etc. but still requires each binary to be resigned and entitlements combined, etc. so I'm curious if there is a better solution.
Please follow the steps to create an unsigned xcarchive
Set ‘Code Signing Identity’ = ‘Don’t Code Sign’
• Select Targets (‘’) -> Build Settings and find the ‘Signing’ section.
• Set ‘Code Signing Identity’ = ‘Don’t Code Sign’
Set Bundle Identifier = ‘’
Set Version = 1.0 //That you need to send
Set Build = 5 //That you need to send
Remove ‘Automatically manage singing’ flag.
Open the terminal and go to the project root folder. Then run the following command.
xcodebuild -workspace <ProjectName>.xcworkspace -scheme <ProjectName> -configuration Release clean archive -archivePath buildArchive/<ProjectName>.xcarchive CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
After successfully completing, it will create a new ‘buildArchive’ folder and inside that a ‘.xcarchive’ file.
You can Zip that ‘.xcarchive’ file and transfer the xcarchive to the signing machine.
We worked on this for several weeks along with other teams in the company. All of us came to the same conclusion, there is no better option than signing with a dev cert and then re-signing each and every binary with the prod cert afterwards. It's not a straight forward process, but that's what we have been left with.
This might work for you I think
Create an unsigned IPA on your build machine.
Have a script in the build machine that transfers the IPA to your
signing machine.
Use the FloatSign script on the signing machine to resign the
IPA.

Automating iOS/WatchKit App Store submission - Code signing issue

I have a rather typical iOS 8 iOS/ObjC/Xcode 6.4 application, which includes a WatchKit extension. I have no trouble manually submitting to the App Store using Xcode using the Archive menu option.
We use a build server (Bamboo but it shouldn't matter). The build server currently automates builds and distributions through HockeyApp, but we manually build and upload to iTunes Connect using Xcode. We would like to automate the builds for the iTunes Connect, so we're certain same codebase is used for both HockeyApp and iTunes Connect (both TestFlight and App Store).
I'm having a heck of a time getting the script working for iTunes Connect, due (I believe) to the three targets that need signing (iOS app, WatchKit Extension, and Watch App).
I found this answer to a related question, which has been very helpful: https://stackoverflow.com/a/29605731. That suggests putting variables into the Provisioning Profile settings for the three targets. This works for building. But that question doesn't involve uploading to iTunes Connect, which is where I'm seeing trouble.
So my script looks like this:
APP_PROFILE="[the hex string]"
WATCHKITEXT_PROFILE="[another hex string]"
WATCHAPP_PROFILE="[one more hex string]"
First I make the xcarchive:
xcodebuild archive -project myProject.xcodeproj -scheme "myScheme" -archivePath myProject.xcarchive APP_PROFILE="${APP_PROFILE}" WATCHKITEXT_PROFILE="${WATCHKITEXT_PROFILE}" WATCHAPP_PROFILE="${WATCHAPP_PROFILE}"
which works fine. Then I export the archive to an .ipa:
xcodebuild -exportArchive -archivePath "myProject.xcarchive" -exportPath "myPath" -exportFormat ipa APP_PROFILE="${APP_PROFILE}" WATCHKITEXT_PROFILE="${WATCHKITEXT_PROFILE}" WATCHAPP_PROFILE="${WATCHAPP_PROFILE}"
which also reports success. Then I need to send the .ipa to iTunes Connect using the Application Loader's command-line tool (here I'm just verifying):
altool --validate-app -f "myProject.ipa" -u myUsername -p myPassword
which spits back this set of error messages:
*** Error: Unable to validate archive 'myProject.ipa': (
"Error Domain=ITunesConnectionOperationErrorDomain Code=1091 \"Invalid Signature. A sealed resource is missing or invalid. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose \"Clean All\" in Xcode, delete the \"build\" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html\" UserInfo=0x7fec4be78b80 {NSLocalizedRecoverySuggestion=Invalid Signature. A sealed resource is missing or invalid. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose \"Clean All\" in Xcode, delete the \"build\" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html, NSLocalizedDescription=Invalid Signature. A sealed resource is missing or invalid. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose \"Clean All\" in Xcode, delete the \"build\" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html, NSLocalizedFailureReason=iTunes Store operation failed.}"
I get the same error if I use the Application Uploader GUI.
I'm confident I'm using the correct profiles in the script, as when I export an archive in Xcode these are the three Xcode selects (that export will validate/submit fine).
I'm at a loss where to look next. Any and all help is appreciated - thanks!

Cocoapods/ CrittercismSDK causing App Submission Error: ITMS-90035

I am trying to upload an app to Testflight using XCode 6.3. However, on trying to validate the app, it is giving me the error message below:
I have tried regenerating the certificates and provisioning profiles without having any success.
ERROR: ERROR ITMS-90035: "Invalid Signature. Code object is not signed
at all. The binary at path [VirtualMechanic.app/dsym_upload.sh]
contains an invalid signature. Make sure you have signed your
application with a distribution certificate, not an ad hoc certificate
or a development certificate. Verify that the code signing settings in
Xcode are correct at the target level (which override any values at
the project level). Additionally, make sure the bundle you are
uploading was built using a Release target in Xcode, not a Simulator
target. If you are certain your code signing settings are correct,
choose "Clean All" in Xcode, delete the "build" directory in the
Finder, and rebuild your release target. For more information, please
consult
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html"
That dsym_upload.sh script does not belong in the app bundle as it's the script that is run as part of a Build Phase that is used to upload the debug symbols to Crittercism.
Find the Build Phase that is copying it into the app bundle and remove it, however please note that it will still need to be run within a Build Phase.
Here's the official Crittercism Support Article related to the issue which recommends upgrading the pod to version 5.2.0.

Resources