Disable bitcode in debug builds for physical iOS devices

[mochimoshi]

A PR for the suggested change in issue #498

The change in the configuration file is only for debug builds on iOS devices - tvOS and watchOS are not touched.

[martijnwalraven]

@tonyarnold I'm not as familiar with this, but do you agree we should make this change?

[tonyarnold]

I'm afraid I'm not completely across bitcode - but this seems legitimate. My question for @mochimoshi is: why? Can you link to some further reading about this change? Why isn't it necessary for watchOS/tvOS as well?

[mochimoshi]

@tonyarnold honestly my understanding of bitcode is a bit fuzzy, but this is what I think the problem was before:

When bitcode is enabled, all of the project's/framework's dependencies must also have bitcode enabled. Furthermore, most projects by default don't seem to explicitly set the bitcode generation mode in their build settings, but use a C compiler flag to determine whether it should generate a bitcode marker (i.e. placeholder) file or an actual bitcode file. By default, this seems to be debug builds all use markers, and release builds may use bitcode if relevant (i.e. no for MacOS, yes for all other platforms). Setting the bitcode generation mode in the build settings will cause xcode to use the settings there rather than the compiler flag.

ApolloSQLite relies SQLite.swift as a dependency, which does not explicitly set bitcode generation mode in its build settings though. This will cause a linker error on compile where Xcode will complain that SQLite.swift is compiled without full bitcode support. Changing debug builds to use marker in the build settings essentially reverts bitcode behavior to before #475 was merged - ie bitcode is still generated in release builds, but not on debug builds. Changing it only for iOS is also my attempt at minimizing effects on other platforms.

As for watchOS and tvOS, from my readings it seems like they've required bitcode from the start (as opposed to iOS, where bitcode is not required). I unfortunately don't have an easy way of physically testing either of those devices at the moment, as building onto the simulator isn't an issue after #475, but until then this also unblocks me from building onto my iPhone / iPad.

This is from my readings over the day yesterday, so this is just my take at what I think is going on with the error I'm hitting in #498. I'm definitely happy to discuss and make changes if there are other concerns or better solutions around this.

[tonyarnold]

No, that all makes perfect sense - thank you for indulging me and explaining that so well.

I think this PR should be merged.

[mochimoshi]

@tonyarnold thanks for your work in making build configurations a lot easier to read and update as well!