Skip to main content
Active reading [<https://en.wikipedia.org/wiki/Apple_silicon> <https://en.wikipedia.org/wiki/Macintosh> <https://www.youtube.com/watch?v=1Dax90QyXgI&t=17m54s>]. Expanded.
Source Link
Peter Mortensen
  • 31.4k
  • 22
  • 110
  • 134
  1. Xcode 12 is actually the stepping stone for Apple SiliconApple silicon which unfortunately is not yet available (when the answer was written). But with that platform we are gonnagoing to get an arm64 based-based macOS where simulators will also run on the arm64 architecture unlike the present Intel based x86_64-based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/appsapplications. 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 Siliconsilicon. 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-based simulator that eventually fails on an Intel based macMac.

  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 Siliconsilicon.

Simply putting, Xcode will fail to build your appapplication 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 hereEnter image description here   

enter image description hereEnter image description here

One thing I was concerned about that what will be the impact of this when we actually archive the libs/appslibraries and applications. During archiving appsapplications 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.

  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 gonna get arm64 based macOS where simulators will also run on arm64 architecture unlike the present Intel based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/apps. 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 arm64 based simulator that eventually fails on 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 app 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

One thing I was concerned about that what will be the impact of this when we actually archive the libs/apps. During archiving apps 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 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.

  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

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.

added 32 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
  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 gonna get arm64 based macOS where simulators will also run on arm64 architecture unlike the present Intel based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/apps. 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 (not available yet). So it sends clang(++) some -target flag like arm64-apple-ios13.0-simulator in <architecture>-<os>-<sdk>-<platform><destination> format and clang tries to build/link against arm64 based simulator that eventually fails on 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.

  1. Xcode 12 is actually the stepping stone for Apple Silicon which unfortunately is not yet available. But with that platform we are gonna get arm64 based macOS where simulators will also run on arm64 architecture unlike the present Intel based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/apps. 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. 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 (not available yet). So it sends clang(++) some -target flag like arm64-apple-ios13.0-simulator in <architecture>-<os>-<sdk>-<platform> format and clang tries to build/link against arm64 based simulator that eventually fails on 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.

  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 gonna get arm64 based macOS where simulators will also run on arm64 architecture unlike the present Intel based x86_64 architecture.

  2. Xcode usually depends on the "Run Destination" to build its libraries/apps. 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 arm64 based simulator that eventually fails on 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.

added 63 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43

Simply putting, Xcode will fail to build your app anytime it tries the command line, xcodebuild, (which defaults to release build, see the general tab of your project setting) or otherwise inand releasetries to build all architectural variants supported by the run destination mode. 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.

Simply putting, Xcode will fail to build your app anytime it tries the command line, xcodebuild, (which defaults to release build, see the general tab of your project setting) or otherwise in release mode. 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.

Simply putting, Xcode will fail to build your app 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.

added 73 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 122 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 353 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 353 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 353 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 24 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
added 748 characters in body
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading
Source Link
Ayan Sengupta
  • 5.4k
  • 2
  • 30
  • 43
Loading