Impact of Xcode build options Enable bitcode Yes/No
- What does the ENABLE_BITCODE actually do, will it be a non-optional requirement in the future?
I'm not sure at what level you are looking for an answer at, so let's take a little trip. Some of this you may already know.
When you build your project, Xcode invokes clang
for Objective-C targets and swift
/swiftc
for Swift targets. Both of these compilers compile the app to an intermediate representation (IR), one of these IRs is bitcode. From this IR, a program called LLVM takes over and creates the binaries needed for x86 32 and 64 bit modes (for the simulator) and arm6/arm7/arm7s/arm64 (for the device). Normally, all of these different binaries are lumped together in a single file called a fat binary.
The ENABLE_BITCODE option cuts out this final step. It creates a version of the app with an IR bitcode binary. This has a number of nice features, but one giant drawback: it can't run anywhere. In order to get an app with a bitcode binary to run, the bitcode needs to be recompiled (maybe assembled or transcoded… I'm not sure of the correct verb) into an x86 or ARM binary.
When a bitcode app is submitted to the App Store, Apple will do this final step and create the finished binaries.
Right now, bitcode apps are optional, but history has shown Apple turns optional things into requirements (like 64 bit support). This usually takes a few years, so third party developers (like Parse) have time to update.
- can I use the above method without any negative impact and without compromising a future appstore submission?
Yes, you can turn off ENABLE_BITCODE and everything will work just like before. Until Apple makes bitcode apps a requirement for the App Store, you will be fine.
- Are there any performance impacts if I enable / disable it?
There will never be negative performance impacts for enabling it, but internal distribution of an app for testing may get more complicated.
As for positive impacts… well that's complicated.
For distribution in the App Store, Apple will create separate versions of your app for each machine architecture (arm6/arm7/arm7s/arm64) instead of one app with a fat binary. This means the app installed on iOS devices will be smaller.
In addition, when bitcode is recompiled (maybe assembled or transcoded… again, I'm not sure of the correct verb), it is optimized. LLVM is always working on creating new a better optimizations. In theory, the App Store could recreate the separate version of the app in the App Store with each new release of LLVM, so your app could be re-optimized with the latest LLVM technology.
Enable bitcode not in build options
Open the target "Build settings" then select "All" and "Combined" options. In the search field, type "bitcode" and select the value to "NO"
If the Enable Bitcode option is not on the list of the search results then check if Architecture and BaseSDK options are set up correctly.
What does ENABLE_BITCODE do in xcode 7?
Bitcode refers to to the type of code: "LLVM Bitcode" that is sent to iTunes Connect. This allows Apple to use certain calculations to re-optimize apps further (e.g: possibly downsize executable sizes). If Apple needs to alter your executable then they can do this without a new build being uploaded.
This differs from:
Slicing which is the process of Apple optimizing your app for a user's device based on the device's resolution and architecture. Slicing does not require Bitcode. (Ex: only including @2x images on a 5s)
App Thinning is the combination of slicing, bitcode, and on-demand resources
Bitcode is an intermediate representation of a compiled program. Apps
you upload to iTunes Connect that contain bitcode will be compiled and
linked on the App Store. Including bitcode will allow Apple to
re-optimize your app binary in the future without the need to submit a
new version of your app to the store.
Apple Documentation on App Thinning
Enable bitcode build option missing from target
Two things were required to remedy the errors:
Apparently, Xcode 9.2 has only for iOS targets the build setting Enable Bitcode
under Build Options.
Watch Extension targets require a User-Defined build setting ENABLE_BITCODE
set to YES
.
Additionally, I had wrong paths in my workspace.
My workspace contains 2 projects, each one with an iOS and a watchOS target. The 1st project is my app, and the 2nd project is my framework used by the app.
Apple Developer Technical Support suggested to deleted all references of my app to the framework in the project navigator of Xcode, and then to add back the frameworks for both app targets under General/Embedded Binaries.
This allowed my to create a valid archive that could be submitted to the App Store and was accepted.
Related Topics
How to Use Nsjsonserialization
How to Change the Name of an iOS App
How to Resize the Uiimage to Reduce Upload Image Size
How to Trigger a Block After a Delay, Like -Performselector:Withobject:Afterdelay:
Expand/Collapse Section in Uitableview in Ios
When Should I Compare an Optional Value to Nil
How to Load Custom Uitableviewcells from Xib Files
How to Add Nsapptransportsecurity to My Info.Plist File
Creating a Segue Programmatically
Airpods Not Working as an Input Source for Voice Recorder App
How to Scroll List Programmatically in Swiftui
Cell Spacing in Uicollectionview