While developing iOS apps, it can sometimes be useful to temporarily redefine the default behavior of your app for convenience or debugging purposes. For example, maybe you’re working on a first-run feature—a tutorial, for instance—that users should only see the first time they open your app. In production, you might want this feature to appear based on a flag stored in NSUserDefaults:
While building this feature, however, you want it to appear every time you build and run. What are your options in this situation? Well, you could comment out chunks of code to force the feature to show up while you’re working on it:
The simplicity of this approach is tempting, but the disadvantages are fairly obvious. For one, you have to remember to uncomment the code before committing it to your repository. This can be especially annoying (and even dangerous) if you’re working with other people who might have difficulties with—or worse, accidentally ship—your temporarily commented-out version.
Another approach might be to use a preprocessor conditional, perhaps based on a custom build setting in your prefix header file, your project, or a
This is better, but it still shares some major disadvantages with commenting out the code. As above, you’re still making changes you’ll have to revert, and you and your coworkers still run the risk of using the wrong build settings when archiving the app for production if you’re not careful.
The best way I’ve found to deal with this scenario relies on a combination of the preprocessor and custom launch arguments defined in an Xcode scheme. You may be familiar with launch arguments and environment variables already, but if not, you should check out this great guide on NSHipster. In addition to controlling the behavior of the frameworks you’re using, launch arguments can be great for overriding boolean flags in your own code during development:
If you need to override specific non-boolean values, environment variables are a great alternative to launch arguments. For example, if you’re working on a login screen for your app, it might be useful to pre-populate your username and password text fields with default values, while avoiding committing sensitive information to your repository:
If you typically use a shared scheme for building and running your app (which is committed to version control), make sure to duplicate it locally before making these additions. Oh, and make sure you’re using the latest and greatest gitignore file for Objective-C development.
Have a different way of doing things? Let me know on Twitter. Thanks for reading!