Question

My iPhone application connects to three different servers, say: production, staging and testing. There is a bunch of configuration values that the application uses depending on to which server it connects to, e.g. Facebook App ID, TestFlight team key, etc.

I’d like to have all the settings in GIT and only select which configuration the application supposed to use when compiling or releasing. For example, when testing is selected, Product -> Run in Xcode runs the debug version of the app connecting to testing, and Product -> Archive creates the IPA file with the release version that also connects to testing.

I don’t want to create more build configurations than debug and release (because that would mean 6 different combinations of build configurations/run-time configurations). The ideal solution, as I see it, would be that I have three schemes: production, testing and staging, and each scheme selects one of three Info.plist files to use with the application. That would allow me to not only define different run-time settings, but also different application versions or bundle identifiers depending on the back-end server. But it doesn’t look like I can configure the Archive action in any other way apart from selecting a different build configuration. Any ideas if that could be achieved in any way?

Edit: To make it a bit more clear, production/staging/testing is the back-end server, not the version of the iOS application. The iOS app comes in two versions: debug/release. In other words I may want to run a debug version of the application connecting to the production server for example to debug a crash caused by JSON returned from that server. I could have named the servers as A, B and C for the sake of clarity.

Answer 1

I would suggest using different build targets for each environment. I successfully used this model before. In your project’s settings you can duplicate the current target and change the build settings as needed. There’s an Info.plist File property that will let you change the default plist for that target.

After that, you can create a scheme for each environment that will use the according target.

You can get a step further and use different bundle id for each target and different names. That will allow you to install both the staging and the production builds on the same device for example.

The only downside in this is that you have more work when you want to update provisioning profiles.