Documentation

Support

Errors after migration to a new Xcode version

Resolve errors caused by migrating to a new Xcode version.
Read time 2 minutesLast updated 16 hours ago

Symptoms

Errors after you migrate to a new version of Xcode from an earlier version. The following frequent error messages and warnings from the UBA/Xcode logs are symptomatic of this issue:
  • Compiler fails with symbol not found:
    • ld: symbol(s) not found for architecture arm64
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
  • The iOS deployment target version is not supported:
    • warning: The iOS deployment target 'IPHONEOSDEPLOYMENTTARGET' is set to 10.0, but the range of supported deployment target versions is 11.0 to 16.1.99
  • Signing requires a development team which is not selected:
    • error: Signing for "gRPC-C++-gRPCCertificates-Cpp" requires a development team. Select a development team in the Signing & Capabilities editor. (in target 'gRPC-C++-gRPCCertificates-Cpp' from project 'Pods')

Causes

These errors often appear when you change Xcode versions if some components, packages, or plug-ins aren't compatible with the new version of Xcode.

Resolution

The first step is to ensure you can build locally in batch mode with a clean clone of the repository (that has no locally cached library) and build the Xcode project without any additional changes beyond what you are doing in your Build Automation targets. After you successfully build locally in batch mode, ensure the version of
cocoapods
you use locally matches the one you use in Build Automation. If the version doesn't match, use the following pre-build script to install the correct version. The following example is for
cocoapods
version 1.12.0:
gem install cocoapods -v 1.12.0
echo "current cocoapods version: "
gem which cocoapods
"UBA - Cocoapods Build Script"
To check your local version of
cocoapods
, use the following command in the terminal:
pod --version
You can pin
cocoapods
to a specific version to ensure that the version is consistent across all builds. You can do this with an external tool such as the External Dependency Manager for Unity or you can directly edit
Dependencies.xml
files. With this tool, if you use an exact version such as
7.0.0
rather than an expression, such as
~> 7.0
which uses any version greater than 7.0, you guarantee that the dependent package version doesn't change and introduce any new bugs.
If you haven't resolved the issue, please open a support ticket so the support team can investigate further. To submit a ticket from the Unity Dashboard, open DevOps and select Help & Support > Ticket > File a ticket.

Additional resources