CopyPastor

Detecting plagiarism made easy.

Score: 1; Reported for: Exact paragraph match Open both answers

Possible Plagiarism

Plagiarized on 2021-05-16
by Prakhar Prakash Bhardwaj

Original Post

Original - Posted on 2020-09-30
by Ayan Sengupta



            
Present in both answers; Present only in the new answer; Present only in the old answer;

**For Swift**
If you are using CocoaPods with Xcode 12, then you have probably seen this error:
The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.
This is happening because support for iOS 8 has been dropped, but the minimum deployment target for the pod is iOS 8.
Until this is fixed, you can add the following to your Podfile:
post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET' end end end
This will remove the deployment target from all the pods in your project and allows them to inherit the project/workspace deployment target that has been specified at the top of Podfile.
**For React Native**
Delete the ./project-root/ios/build folder and type `react-native run ios`

**For Cordova**
<preference name="deployment-target" value="8.0" />

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 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 &lt;architecture&gt;-&lt;os&gt;-&lt;sdk&gt;-&lt;destination&gt; 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][1]][1] [![enter image description here][2]][2]
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][3] 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 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]: https://i.stack.imgur.com/EwcNf.png [2]: https://i.stack.imgur.com/ryqPU.png [3]: https://guides.cocoapods.org/syntax/podspec.html#user_target_xcconfig

        
Present in both answers; Present only in the new answer; Present only in the old answer;