I am using xcodebuild to generate an archive from a workspace. I use the following command:
xcodebuild -workspace MyProject.xcworkspace -scheme "MyProject"
-destination generic/platform=iOS archive
-archivePath "../PathToArchive/MyProject.xcarchive
(I've spaced it out over multiple lines for readability)
This command generates a MyProject.xcarchive. However it generates a generic "Xcode Archive" rather than an "iOS App Archive." This cannot be submitted to the App Store.
If I archive the exact same workspace and scheme using Xcode.app version 7.0.1 (7A1001) instead of xcodebuild then I get an "iOS App Archive" which can be submitted to the App Store.
Inspecting the contents of these two xcarchives shows the main difference is the bundled Info.plist file. The one generated by Xcode.app contains an additional ApplicationProperties dict with versioning and signing details. The one generated by xcodebuild lacks these details in its Info.plist.
Copying the Xcode.app generated Info.plist into the xcarchive generated by xcodebuild "fixes" the archive, and it can be submitted to the App Store. This is not a solution however, as it means I cannot build on the command line.
Note that doing xcodebuild -version prints:
Xcode 7.0.1
Build version 7A1001
Edit: sometimes xcodebuild appears to generate a correct iOS App Archive instead of a Generic Archive. I'm not exactly sure why this happens. It's not consistent.
Are you using Cocoapods? If so try using the pre release version gem install cocoapods --pre . I had the issue because of a copy pods phase being somewhere it should not have been, please go through https://github.com/CocoaPods/CocoaPods/issues/4021 you should find a solution that fits you.
After a lot of frustration I have discovered the cause of xcodebuild producing incorrect xcarchive packages.
I had to disable the "Parallelize Build" option for the scheme I was building.
After un-ticking this option, the builds take a lot longer, but xcodebuild is consistently producing an "iOS App Archive" rather than a "Generic Archive." With "Parallelize Build" enabled xcodebuild would generate a "Generic Archive" 90% of the time, occasionally generating a correct archive.
Because I wanted my build times within Xcode to remain unaffected, I left the "Parallelize Build" option enabled for my schemes. I duplicated the schemes to be built with xcodebuild and un-ticked the option only for the deployment schemes.
Related
On my hand is an Xcode project, comprising of a number of static libraries, and an iOS application that consumes them (we do not intend to release the libraries). Part of it is a crash reporting implementation based on Google Breakpad.
An issue that we've found is that we aren't getting line number information in crash reports for the libraries, from our releases. These are generated using xcodebuild archive -project ${PROJECT_PATH} -scheme ${SCHEME_NAME} -archivePath ${OUTPUT_PATH} -UseModernBuildSystem=NO -IDEBuildingContinueBuildingAfterErrors=YES. EDIT: using Xcode 12.
If, instead of archive, I run the xcodebuild build action with the same options (exc. archivePath of course) - or build the project in the IDE -, then I get complete symbol information and everything works (at least testing on iOS Simulator). This seems to be the only difference - of course then I'd still need to produce an .ipa somehow.
The build options are shared between all libraries and application, and include the following:
COPY_PHASE_STRIP = YES
DEPLOY_POSTPROCESSING = YES
SEPARATE_STRIP = YES # tried to change each of these to NO in various permutations; no difference.
STRIP_STYLE = non-global
What is the difference between the steps that the build and the archive actions perform, with regards to stripping?
How can I create the .ipa from the artifact of the xcodebuild build, or otherwise coerce xcodebuild archive to omit / delay stripping, so that I may perform that manually once I've dumped the symbols?
It might be worth mentioning that I've tried combinations of the xcodebuild actions as well, i.e. clean build archive in one or separate steps - makes no difference.
(FWIW, I realise that the PackageApplication command of xcrun was deprecated as of Xcode 8.3.)
I'm trying to run Facebook's WebDriverAgent, for testing on real devices: https://github.com/facebook/WebDriverAgent.
Our admin isn't a fan of Apple's automatic signing, so we're trying manual. When I put
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx
it says
Testing failed:
WebDriverAgentLib has conflicting provisioning settings. WebDriverAgentLib is automatically signed, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the project editor.
I set manual signing on everything (in xcode), and try again:
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx
Testing failed:
WebDriverAgentLib does not support provisioning profiles. WebDriverAgentLib does not support provisioning profiles, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.
It seems I need to decompose the 'test' action to build the library without the profile, but everything else with the profile, and then trigger testing.
Can this 'xcodebuild test' command be rewritten as several commands to effect such a build/test? I need a command-line solution because this is part of a continuous integration.
Thanks in advance!
This happened to me using manual signing and including Cocoapods dependencies. This is possibly a known issue with Cocoapods (https://github.com/CocoaPods/CocoaPods/pull/6964). Their workaround is to specify setting PROVISIONING_PROFILE_SPECIFIER to '' in the Podfile's post_install hook, but this didn't work for us because we commit our Pods, so the post_install hook doesn't run when we build.
However, in addition to passing the option PROVISIONING_PROFILE_SPECIFIER=xxxxx to xcodebuild, we were able to build by setting the following options in Pods.xcodeproj/project.pbxproj for each target/build configuration:
CODE_SIGNING_ALLOWED = NO;
CODE_SIGNING_REQUIRED = NO;
PROVISIONING_PROFILE = '';
PROVISIONING_PROFILE_SPECIFIER = '';
I am not primarily an iOS developer by trade, but from my understanding, PROVISIONING_PROFILE is deprecated and specifying both CODE_SIGNING_ALLOWED and CODE_SIGNING_REQUIRED may be redundant, but we do it anyway at the moment in our project.
Try using PROVISIONING_PROFILE_SPECIFIER=xxxxx instead of setting PROVISIONING_PROFILE, which is deprecated starting with Xcode8.
If the error then still occurs, try to set neither DEVELOPMENT_TEAM nor PROVISIONING_PROFILE_SPECIFIER, as these codesigning related buildsettings are only relevant, if you are actually building an app (but you are only executing an xcodebuild test on an already build app bundle).
If you want to build and test the app with one call of xcodebuild, you are encouraged to do a xcodebuild ... clean build test
EDIT
After taking a look at the WebDriverAgent project, the problem is related to the WebDriverAgentLib being a Dynamic Framework and a Target-Dependency of the WebDriverAgentRunner-Bundle. Dynamic Frameworks don't like codesigning during the build phase in Xcode8 at all (they now should be codesigned on the fly when being copied into the build product). With specifying code signing related build settings on the command line (DEVELOPMENT_TEAM etc.), Xcode8 will complain about this for Dynamic Framework targets and fail the build.
Solution 1: remove all codesigning related build settings from your xcodebuild call (PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE, DEVELOPMENT_TEAM, CODE_SIGN_IDENTITY) and just set these for the WebDriverAgentRunner-Target (either in the Xcode UI or via Command-Line with plistbuddy on the project.pbxproj).
Solution 2: don't test on a real device and instead just on the Simulator. As there is no need to codesign an Executable and/or Test-Bundle for Simulators, you can safely omit any codesigning related parameters from your xcodebuild call.
Solution 3: just stick with Automatic CodeSigning and assure that there a is valid login for the proper Developer Account in the build machine's Xcode.
I had this error and https://stackoverflow.com/a/39923121/713391 suggested i check "Enable Automatic Signing" then click cancel without doing anything, which did fix it. A code diff showed the change was to add
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES;
or in Xcode it's called Always Embed Swift Standard Libraries
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.
I'm trying to build and archive (in Release and Debug mode) an ios project generated with apache cordova 4.0.0, via command line tool xcodebuild
These commands work ok:
cordova platform add ios
cordova prepare ios
cordova build ios
The ios project generated by cordova has a scheme called iHogar. After that, when I try to launch this command on the console:
xcodebuild -scheme iHogar -sdk iphoneos -configuration Debug
CODE_SIGN_IDENTITY="iPhone Distribution: S-N-A L-C-A, S- CO-P-Ñ-A DE
SE-U-O- Y R--A-E-U-OS (xxxxxxx)"
It stops at the beginning of the execution, and does not continue. The value of param CODE_SIGN_IDENTITY is modified due to privacy reasons.
Here is the output of the command, through console:
Build settings from command line:
CODE_SIGN_IDENTITY = iPhone Distribution: S-N-A L-C-A, S- CO-P-Ñ-A DE SE-U-O- Y R--A-E-U-OS (xxxxxxx)
SDKROOT = iphoneos8.1
And stops there without finishing the command (it hangs) , only stops with crtl+C
The certificate is ok, and also the provisioning profile. If I open the project with Xcode (version 6.1) everything goes ok, I can build and archive it without problems, with the same certificate and provisioning profile.
Has anyone experienced this behavior?
Thanks in advance
I have resolved this issue. The problem was that the cordova generated ios project hasn't got schemas. Those are created the first time you open the project with XCode. When the app has been created by cordova, is only created with targets.
In this scenario, that the generated app cannot be opened with XCode with human interaction, is better to build the app with the target option, like this:
xcodebuild -xcconfig "cordova/build.xcconfig" -project "iHogar.xcodeproj" ARCHS="armv7 armv7" -target "iHogar" -configuration Debug -sdk iphoneos build VALID_ARCHS="armv7 armv7s" CONFIGURATION_BUILD_DIR="build/device"
It's important to have the certificate to sign the app installed in the keychain, and the related provisioning profile downloaded.
I know you got around your issue, but as this is quite recent, have you considered upgrading to Cordova 5.1.1. This will build and code sign the app without the need to go into XCode.
I am using Phonegap CLI 3.1 and XCode5. I want to generate the release build for iPhone Application through command line, I have valid distribution certificate and mobile provisioning profile. I want to generate the release build totally through command and don't want to use XCode GUI or Phonegap Build. I have tried too much with xcodebuild, xcrun and even corodva build command but none of them provide me the release build file (either in .app format or .ipa).
Method 1 (Use xcodebuild)
a) xcodebuild -project MyApp.xcodeproj -alltargets -sdk iphoneos7.0 PROVISIONING_PROFILE="PROFILE_UUID.mobileprovision" -configuration Release
** BUILD FAILED **
The following build commands failed:
CompileC build/MyApp.build/Release-iphoneos/MyApp.build/Objects-normal/armv7/AppDelegate.o MyApp/Classes/AppDelegate.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
CompileC build/MyApp.build/Release-iphoneos/MyApp.build/Objects-normal/armv7/MainViewController.o MyApp/Classes/MainViewController.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
CompileC build/MyApp.build/Release-iphoneos/MyApp.build/Objects-normal/armv7s/AppDelegate.o MyApp/Classes/AppDelegate.m normal armv7s objective-c com.apple.compilers.llvm.clang.1_0.compiler
(3 failures)
Method 2 (Use corodova build and xcrun to sign the app)
a) cordova build ios -release
Compiling app on platform "ios" via command "/Users/Macuser/Desktop/MyApp/platforms/ios/cordova/build" --release Platform "ios" compiled successfully.
b) xcrun -sdk iphoneos PackageApplication -v "build/Release-iphoneos/MyApp.app" -o "build/Release-iphoneos/MyApp.ipa" --sign "iPhone Distribution: NAME (ID)" --embed "PROFILE_UUID.mobileprovision"
error: Failed to read entitlements from '/tmp/iyibGn3aUv/Payload/MyApp.app
The problem is that you do not have proper schemes. When phonegap project is generated it does not contain any schemes and thus linking to the phonegap files is incorrect.
Go to the phonegap generated project in console and put 'xcodebuild -list'
in the output you will get that there is no schemes in the project.
Open generated by phonegap project in the xcode - this will generate schemes.
Now you can build this using xcodebuild(Remember to fill up the proper scheme name):
xcodebuild -scheme YOURSCHEMENAME -project MyApp.xcodeproj -alltargets -sdk iphoneos7.0 PROVISIONING_PROFILE="PROFILE_UUID.mobileprovision" -configuration Release
For continous integration this is bad solution because you have to launch the xcode GUI to generate the schemes but I did not found any other solution for this problem. If someone know how to generate scheme using command line it would be nice of him to write it down.
First, you need to create your app in iTunes Connect (This is in the member center of your iOS developer account). If you've already created your profiles and certificates, then you can select the correct one in iTunes Connect. Here is where you name your app, set a price, write a description, and upload screen shots and a large icon. Make sure you fill in all information and upload all images for your app. You will know when you are done the status of your app changes to 'Waiting for Upload".
After you've created your app successfully in iTunes Connect, to generate an .IPA file for distribution (either for the AppStore or Ad-Hoc) in Xcode you need to select your Project in the file tree (at the top of the tree). Then make sure your 'Targets' is selected to the right.
Choose 'Build Settings". Then go to the section where is says Code Signing. For 'Release', make sure that the correct iPhone Distribution identity or profile is selected.
Below 'Release' it should say 'Any iOS SDK'. Make sure that it says 'IOS Distribution' next to it.
If you have the correct certificates and profiles in the keychain, you can now in the menu at the top choose Product > Archive.
If it doesn't build, then press the run button to build your project. Xcode should say that it is archiving.
After it archive's successfully, go to the Organizer. In the menu at the top choose Window > Organizer. Now click Archives.
If your project successfully archived you will see it here. First you need to Validate your project with iTunes Connect. You will need to enter your iOS Developer login info. Xcode 5 does a pretty good job of detecting the correct profiles so you should see it in there.
If your app validates then you can then distribute either to the App Store or as an Ad-Hoc distribution. Depending on which profile you have.
This is the process for distributing apps either Native or Phonegap. It doesn't matter, I've built both.
I would suggest doing it this way, in case your app doesn't validate. Xcode will then tell you what you need to do to fix. Then once you fix everything. Create a new archive and try until it validates.