If you haven’t seen my slides on How to quickly eat your own dogfood in iOS, you should. It allows you to get the product in your hands faster and can help eliminate any assumptions you have about the UX by actually using it. The biggest caveat you run into is having configurations on a per target basis. For example, Google Cloud Messaging requires a GoogleService-Info.plist file in your bundle that contains a GCM_SENDER_ID and a BUNDLE_ID. The values will be different for both your beta builds and production builds. You can’t have two of these files because you’d have to name them differently and the Google library loads the plist directly by name.

The solution is to modify the GoogleService-Info.plist file after it’s been copied to the bundle. First add a step to your current Build Phase, specifically after “Copy Bundle Resources“. OS X has a built-in tool called PListBuddy which we’ll use to modify the GoogleService-Info.plist once it’s been copied to the bundle. It’s ok to modify it in the bundle before it’s been digitally signed.

/usr/libexec/PlistBuddy -c "Set GCM_SENDER_ID " $BUILT_PRODUCTS_DIR/.app/GoogleService-Info.plist
/usr/libexec/PlistBuddy -c "Set BUNDLE_ID " $BUILT_PRODUCTS_DIR/.app/GoogleService-Info.plist

Perform a clean, then build and you’re good to go. Alternatively, if you don’t want to hide configurations like this in an IDE, put it in a separate .sh file and execute the script. This way you can see that there is a file in source control and it’s not hidden to other developers with an IDE setting.

You could also use this technique to modify your Info.plist values between your prod and beta builds, so you don’t have to have separate .plist files for each of them.