I am attempting to automate the submission process to iTunesConnect using a shell script and the command line tools from Xcode. So far, I have managed to achieve every step in the process bar one: archive.
The code from the script:
echo "Attempting to build target: ${TARGET_PRODUCT}"
cd $ENGINE_PATH
# Clean
/usr/bin/xcodebuild clean -project projName.xcodeproj -target "${TARGET_PRODUCT}" -configuration Release
# Build and Archive
/usr/bin/xcodebuild archive -project projName.xcodeproj -scheme "${TARGET_PRODUCT}" -configuration Release -archivePath "${TARGET_PRODUCT}".xcarchive
So far, the archive command has been unable to create an archive successfully. The only output from this command is:** ARCHIVE FAILED **
.
If I just try to build, rather than archive, I get: ** BUILD SUCCEEDED **
The archive does produce a file at the expected location and 'Show Package Contents' expands to show a directory structure identical to archives produced within Xcode with one exception, the archive created within Xcode includes an additional folder called SCMBlueprint
.
I've seen on other forum posts that issues with archiving are often due to Code Sign or Provisioning Profile issues. However, I'm not convinced this is an issue in this case, as during the build and archiving process the Code Sign Identity and Provisioning Profiles used are output in the console. My failed archiving is using the same Code Sign Identity and Provisioning Profile that successful builds are using. In addition, I produced an archive using Xcode and looked within that archive for the embedded.mobileprovision
file. I compared this to the failed archive generated by xcodebuild
and could see that they are identical.
I've looked elsewhere online for any suggestions for what is causing the archiving by xcodebuild
to fail, but so far, I am stumped! Any help is much appreciated!
Disabling bitcode on Xcode was solving the issue, but using the xcodebuild command was not, because we tried using an export options plist file generated by Fastlane, which seems to be defective. Be sure to disable bitcode when exporting your archived build. If you're using xcodebuild ensure your export options plist includes the following entry:
I am experiencing the exact same issue. Xcode 13.1 is crashing with this error message when attempting to export our iOS app from the archive. The bug was introduced in our project because one of our dependencies is not ready to use bitcode.
The bug was introduced in our project because one of our dependencies is not ready to use bitcode. Disabling bitcode on Xcode was solving the issue, but using the xcodebuild command was not, because we tried using an export options plist file generated by Fastlane, which seems to be defective.
This command has code signing issues with Xcode 13, where apparently a communication with Apple failed. The command is executed on macOS 12.0 Beta (21A5304g). By switching to Xcode Version 12.2 (12B45b) using xcode-select, the export works under equal conditions! This seems to be a regression in Xcode 13.
Please check if you do not have any errors during archive process. Also please compare the logs between Xcode and command line output, it may help you understanding on which step compilation fails.
I had the same issue. Archive was failing without any specific reason, while .xcarchive was produced. I looked at build logs from xcode noticed that it finished with Build finished with errors
message. Despite this error organizer was showing archive and I was able to export IPA from it.
When I reviewed that, I found out there was an archive error caused by broken PNG file, which couldn't be compressed during archive process. Error was non fatal, hence archive was being produced anyway. When I fixed PNG file everything started compiling smoothly without any issues.
This just happened to me, and it was for a different issues than with PNGs (maybe what follows is just the more general case though): I had a custom build phase which was outputting errors to stderr
, but the build phase wasn't returning an exit code different from 0
in this case (using xcodebuild
from Xcode 9.3 (9E145)
).
The build phase was similar to:
find "${SRCROOT}/Directory" -print0 | <...>
Where ${SRCROOT}/Directory
was renamed, and so find
would output an error without failing the script: the build log would contain Command /bin/sh emitted errors but did not return a nonzero exit code to indicate failure
right after executing the build phase.
While Xcode itself has no issues with it, xcodebuild
would simply fail with **ARCHIVE FAILED**
at the end, right after touching the DSYM.
The fix was to make sure that if a build phase outputs to stderr
, the build phase correctly explicitely returns an exit code different from 0
(like 1
). In my case, changing the path referenced in find
fixed the issue.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With