iOS Build Troubleshooting
Important
Visual Studio App Center is scheduled for retirement on March 31, 2025. While you can continue to use Visual Studio App Center until it is fully retired, there are several recommended alternatives that you may consider migrating to.
Building an xcworkspace
or an xcproject
requires a shared Xcode scheme. Xcode schemes are saved locally so Xcode can access them. By default schemes aren't shared with others or included in source control.
To share a scheme in Xcode, use the following steps:
- Select Product > Scheme > Manage schemes.
- Set the scheme for your xcproject/xcworkspace as shared.
- The scheme's container must be set to the Xcode project or workspace you want to build.
- Add the
.xcscheme
file to source control and pushed to your remote repository so that App Center can access it.
Warning
Make sure that your xcshareddata/xcschemes/
folder isn't in your .gitignore
file. This is where the .xcscheme
files are stored by Xcode. App Center relies on these files to build the project properly. Simply exporting the .xcscheme
into a different folder won't work.
The error could be caused by App Center building with the xcodeproj instead of the workspace. When adding CocoaPods to your project, switch to using the workspace when building in App Center.
Indicator: Look for this line in your build log:
ld: library not found for -lPods-GarageController
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** ARCHIVE FAILED **
To fix this error, open your project's Build configuration and click Save. App Center will automatically choose the workspace correctly for future builds.
Note
Signing identities which use non-ascii characters aren't supported in Build.
Dealing with provisioning profiles and certificates can be a challenging process. The following tips should help you successfully sign your iOS apps:
Save the build configuration in App Center after you've pushed signing changes to your project. In App Center, the build configuration of any branch stores two values of your Xcode project: the
CODE_SIGN_STYLE
andDEVELOPMENT_TEAM
(set in theproject.pbxproj
file in your.xcodeproj
folder). Whenever you change between manual and automatic signing or switch the development team, make sure you save the build configuration on App Center after pushing the changes. If you don't save after pushing, your build may fail with a signing error.Drag and drop the correct provisioning profile when using automatic signing. In Xcode, in the General tab of your target under Signing, click the info icon next to Xcode Managed Profile. You’ll then see a popover with profile information. Click and drag the PROV icon on the top left to the wanted location (as shown below).
Take note of App Center's currently supported options when using manual and automatic signing. App Center fully supports manual iOS app signing, so you can use any type of profile or certificate. Verify the provisioning profile and certificate you upload to App Center match what you’ve specified in your project. If you've enabled Automatically Manage Signing in Xcode, App Center supports app signing with developer certificates and profiles (not with distribution). When uploading to App Center, you’ll need to use the autogenerated provisioning profile from Xcode.
To troubleshoot and get build signing up and running, we suggest the following steps:
- Set up manual signing in your Xcode project and make sure it’s working locally.
- Once that's verified, commit and push the changes to your repository.
- Prepare the provisioning profile and certificate selected in the Xcode target and upload them to the App Center build configuration.
- Most importantly: make sure you’ve pushed the latest state of your project before saving the new certificate and profile to the build configuration.
Xcodebuild, unlike xcrun, doesn't allow generating an .ipa
file if the build isn't signed. Unsigned builds produce an .xcarchive
instead. If you wish to generate an .ipa
file with the artifacts of an unsigned build, you can use the .xcarchive
file to do so.
If your builds fail with error: Invalid bitcode version (Producer: '802.0.38.0_0' Reader: '800.0.42.1_0')
, you're using a library or pod that was built by a newer version of Xcode than your project. You can either update your project and build configuration in App Center to use a newer version of Xcode or switch to an alternate version of the problematic library, which is compiled with a matching version of Xcode.
A common reason for tests to fail is where the linker commands hit an error similar to the following one:
ld: directory not found for option iPhoneSimulator10.3.sdk/Developer/Library/Frameworks
❌ ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later (@rpath/XCTest.framework/XCTest) for architecture x86_64
❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)
The likely cause of this error is the linking type of Apple Mach-O Linker isn't set to static library. To successfully build and test your app, ensure the linking type of Apple Mach-O Linker in your test target is set to static library.
It might be because the signing configuration in you Pods project differs from the one in your Main project. Are your Pods checked-in into your repository? If so, your Pods project must use the same signing method as your Main project.
If your Pods aren't checked-in, there might be different issues. There are a few workarounds you can use in this GitHub Issue with pre-build scripts.
Since I've upgraded my project to Xcode 10 beta, my app fails to build with the error Cycle in dependencies between targets
Xcode 10's new build system detects dependency cycles in your build and fails your build if there are any.
For more information on how to fix the build, see Apple's documentation on resolving common types of dependency cycles.