Xcode 12, building for iOS Simulator, but linking in an object file built for iOS, for architecture 'arm64' Xcode 12, building for iOS Simulator, but linking in an object file built for iOS, for architecture 'arm64' xcode xcode

Xcode 12, building for iOS Simulator, but linking in an object file built for iOS, for architecture 'arm64'

Basically, you have to exclude arm64 for the simulator architecture, both from your project and the Pod project,

  • To do that, navigate to Build Settings of your project and add Any iOS Simulator SDK with value arm64 inside Excluded Architecture.

    Enter image description here


  • If you are using custom XCConfig files, you can simply add this line for excluding simulator architecture.

    EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64


    You have to do the same for the Pod project until all the Cocoa pod vendors are done adding following in their Podspec.

    s.pod_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }

    You can manually add the Excluded Architecture in your Pod project's Build Settings, but it will be overwritten when youuse pod install.

    In place of this, you can add this snippet in your Podfile. It will write the necessary Build Settings every time you run pod install.

    post_install do |installer|  installer.pods_project.build_configurations.each do |config|    config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"  endend


Set "Build Active Architecture Only (ONLY_ACTIVE_ARCH)" to Yes for your libraries/apps, even for release mode.

While trying to identify the root cause of the issue I realized some fun facts about Xcode 12.

  1. Xcode 12 is actually the stepping stone for Apple silicon which unfortunately is not yet available (when the answer was written). But with that platform we are going to get an arm64-based macOS where simulators will also run on the arm64 architecture unlike the present Intel-based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/applications. So when a simulator is chosen as the "Run Destination", it builds the app for available simulator architectures and when a device is chosen as the "Run Destination" it builds for the architecture that the device supports (arm*).

  3. xcodebuild, in the Xcode 12+ build system considers arm64 as a valid architecture for simulator to support Apple silicon. So when a simulator is chosen as the run destination, it can potentially try to compile/link your libs/apps against arm64 based simulators, as well. So it sends clang(++) some -target flag like arm64-apple-ios13.0-simulator in <architecture>-<os>-<sdk>-<destination> format and clang tries to build/link against an arm64-based simulator that eventually fails on an Intel based Mac.

  4. But xcodebuild tries this only for Release builds. Why? Because, "Build Active Architecture Only (ONLY_ACTIVE_ARCH)" build settings is usually set to "No" for the "Release" configuration only. And that means xcodebuild will try to build all architectural variants of your libs/apps for the selected run destination for release builds. And for the Simulator run destination, it will includes both x86_64 and arm64 now on, since arm64 in Xcode 12+ is also a supported architecture for simulators to support Apple silicon.

Simply putting, Xcode will fail to build your application anytime it tries the command line, xcodebuild, (which defaults to release build, see the general tab of your project setting) or otherwise and tries to build all architectural variants supported by the run destination. So a simple workaround to this issue is to set "Build Active Architecture Only (ONLY_ACTIVE_ARCH)" to Yes in your libraries/apps, even for release mode.

Enter image description here

Enter image description here

If the libraries are included as Pods and you have access to .podspec you can simply set:

spec.pod_target_xcconfig = { 'ONLY_ACTIVE_ARCH' => 'YES' }

spec.user_target_xcconfig = { 'ONLY_ACTIVE_ARCH' => 'YES' } # notrecommended

I personally don't like the second line since pods shouldn't pollute the target project and it could be overridden in the target settings, itself. So it should be the responsibility of the consumer project to override the setting by some means. However, this could be necessary for successful linting of podspecs.

However, if you don't have access to the .podspec, you can always update the settings during installation of the pods:

post_install do |installer|  installer.pods_project.targets.each do |target|    target.build_configurations.each do |config|      config.build_settings["ONLY_ACTIVE_ARCH"] = "YES"    end  endend

One thing I was concerned about that what will be the impact of this when we actually archive the libraries and applications. During archiving applications usually take the "Release" configuration and since this will be creating a release build considering only the active architecture of the current run destination, with this approach, we may lose the slices for armv7, armv7s, etc. from the target build. However, I noticed the documentation says (highlighted in the attached picture) that this setting will be ignored when we choose "Generic iOS Device/Any Device" as the run destination, since it doesn't define any specific architecture. So I guess we should be good if we archive our app choosing that as a run destination.

I found a solution! SwiftUI Previews not working with Firebase

If you set excluded architectures for the simulator to arm64 it will compile.

Excluding architectures for the simulator