Many Environments To Manage
Have you ever worked on an iOS app that needed multiple environments to support it through development? I have. For me, almost every app I have ever worked on has had some sort of web based API supporting the app. And for these apps, I’ve tried a variety of techniques to consolidate and improve how I manage the urls for these web APIs across different test infrastructures. This kind of iOS environment configuration can become tricky. For example, at one place I worked, we had the following “test environments” or different web backends intermingled throughout the release pipeline:
- Local (url of localhost, sometimes an IP address_
- DEV (Development testing)
- INT (Integration testing)
- SAT (Systems acceptance testing)
- PERF (Performance testing)
- CAT (Client Acceptance Testing)
- Pilot (Alternate Production servers – including different urls for each node behind the F5 load balancer)
- Production (including different urls for each node behind the F5 load balancer)
This amounts to more than 10 different environments that I would need to provide builds for various testers throughout the development cycle.
Summary Of Options
Needless to say, 10 environments is a lot and need to be managed somehow. I was thinking of writing up each technique I’ve tried, but then I came across a useful article on “The App Business” blog, titled “A robust multi-environment build setup.” that clearly describes a couple of the most popular ways to do this.
Automating It
The majority of “The App Business” blog article recognizes some manual ways to manage your builds and the environments they are configured to connect to, including other iOS environment configuration. Later in the article though, “The App Business” goes a further extra mile by announcing an actual tool they created to help accomplish this, it’s called configen. configen takes a configuration file, and actually generates a Swift class to help manage selecting environments during build configurations.
Schemes Aren’t Bad
One qualm I have with the article. Using separate Xcode Schemes for different environment variables is a useful way to help separate our your iOS environment configuration. One thing I like about using separate Schemes that the article doesn’t mention, is that non-developer-types, like product managers or designers, may feel comfortable knowing where the dropdown is in Xcode to build for a separate scheme, while they may not feel comfortable having to modify code or run schemes to change environment options.
User Controlled
One thing I would have liked configen to take farther is the ability for the end user of the app to be able to change the environment variables and other iOS environment configuration used for a given session of the app. I’ve seen this done several ways, but none that I’m happy with. The last time I did it, I actually coded my own interface for the user to select which environment to use. I wasn’t happy with how intertwined the resulting user interface code was the rest of my code base, there wasn’t good decoupling. Ideally, there’s a third party package, that can be modularly loaded, such that it is a drop-in solution.
Getting More Clean
What’s on your wish list for iOS environment configuration? What aren’t I thinking of? How have you fared? I’d love to hear.
Happy cleaning.