Apple

Lets say I've written a networking engine shared amongst multiple projects. For convenience, the networking engine's SDK requires paths and payloads but AUTOMATICALLY determines the hostname.

The hostname is a function of the "environment" that the application is targeting. Note that this is the core problem I am attempting to solve here - and feel free to suggest I go about this a different way.

Solution #1:

- create unique Configurations for each environment. Specifically, a "Configuration" in Xcode is "Debug" or "Release". This means I now have Dev, Test, Stage and Production configurations - and no more Debug and Release.

- add a key value pair to the app's Info.plist ... Configuration=${CONFIGURATION}

- create a scheme for each environment and then pick the corresponding Configuration ... so we end up with 4 schemes: Dev, Test, Stage and Prod each pointing to their similarly named Configuration.
- at runtime, look in the Apps bundle for the value of "Configuration"

- use that value to key into a single, shared plist file that includes hosts for all environments.

This works great, except for a few things:

- All debug symbols are lost. The "Dev" configuration was simply a name change from the original "Debug" ... and yet, values are not showing up in the debugger. The settings screen indicates that Symbols are not stripped - and yet we can't see anything in debug mode. Everything is essentially nil.

- Is "Debug" a special word?

- the other part we notice is that we're essentially duplicating work since we create 4 configs and 4 schemes. Technically, we really only need 2 configs and 4 schemes. Debug and Release are just fine ... and actually convey more information in this case per their context.

- so, instead of trying to figure out what happened to our debug info, it seems like we should revert back to Debug and Release configurations (that would feel more standard) - but we need to find a clean way to get the environment qualifier we need ... maybe ala the Schemes?

WHAT ABOUT USING SCHEMES?

- Again, we chose this way initially because Configuration=${CONFIGURATION} was an easy win. ${CONFIGURATION} was clearly available via Xcode so we captured it and then looked it up.