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

Solution 1:

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.

  

OR

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

  EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64
  

  Then

  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 you use 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"
    end
  end
  

Solution 2:

TL;DR;

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.

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' } # not recommended

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
  end
end

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.

Solution 3:

I found a solution! SwiftUI Previews not working with Firebase

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

Solution 4:

The Valid Architectures build setting has been removed in Xcode 12. If you had values in this build setting, they're causing a problem and need to be removed.

I was able to "clear out" the VALID_ARCHS build setting by adding it back in as a user-defined build setting (with no values), running the project (which failed), and then deleting the VALID_ARCHS build setting. After that, I was able to run on the simulator.

My Architectures build setting is Standard Architectures.

You can add a user-defined setting from the plus button in Build Settings:

Solution 5:

The proposed answers are outdated/incorrect.

You should initially try to update both CocoaPods and the dependencies for your library/app, and then, if that doesn't work, contact the vendors of any dependencies you are using to see if they have an update in progress to add support for arm64 Simulator slices on M1 Macs.

There are a lot of answers on here marked as correct suggesting that you should exclude arm64 from the list of supported architectures. This is at best a very temporary workaround, and at worst it will spread this issue to other consumers of your libraries. If you exclude the arm64 Simulator slice, there will be performance impacts on apps that you're developing in the Simulator (which in turn can lead to reduced battery time for your shiny new M1 kit while you're developing your amazing ideas).