Cloud Configuration is a Dream

If you’ve already done the things I described above, then congratulations! Now let’s take some of those constants you have in your code, and turn them into variables in the cloud!

Doing this makes your app really powerful. Now you can control things like your UI details and feature settings, all while the app is in people’s hands.

Remember how you could control your DeLorean? Now you can do some serious shit to your app.

Here are some cool things you can do with remotely controlled config:

Adjust Your UI (revisited)

Same as above, but now with remote control! Maybe your image hosting service got an upgrade, so you can change to higher resolution images and make them larger. Awesome, you can remotely change the size of your image views!

Another example: If you’re not sure what the hell your “Sign Up” button should say (Tip — try: “Sign Up”, “Get Started”, “Hand Over Your Firstborn”), you can now make a small configuration variable on your server, and then change it after you ship.

Note: You could use an A/B testing tool to accomplish all sorts of major changes if you want, but I’m trying to get you to change some simple variables remotely, not run complicated “campaigns”. If you already use an A/B testing tool, then keep using it, but run some smaller changes too!

Think about it: Sometimes it’s the very little things about your app that get people to like it or hate it. Having bits of UI that you’re unsure about, but can remotely configure means you can quick make small changes with a large group of people. It’s really useful in a live user test.

Emails, URLs, and Social Media handles (revisited)

Apps change Twitter handles and even homepage URLs all the time. There’s no reason this should be hard-coded into your app. Maybe you’ll finally convince the squatter to sell you that domain you’ve wanted forever. Maybe you’ll change help desk providers (Hello Zendesk) and need to change your support email address. Maybe the Libyans will be back again to take your precious bit.ly away.

When we launched Cluster, we totally loved getcluster.com — but obviously we jumped at the opportunity to purchase cluster.co. If we had been able to update our app on the fly back then, the transition would’ve been seamless.

3rd-Party API Tokens

Ok. I’ve admitted to hard-coding stuff in the past, but now it’s time for you to come clean, too. You hard-code your 3rd party API tokens. Your S3 Access Key is sitting there as a constant in your app delegate. No, no, it’s ok. We’ve all been there.

Let me tell you about a time when I was burned by this: At my last startup, I was integrating a public-image-search service, for a “minor” feature, and so I incorporated my API key into the app’s binary. I figured if I ever ran close to the usage quota, we could pay to increase the limits.

When I accidentally hit the quota, it turned out that I had to provision a new key with a new quota, and I couldn’t just change the quota on my existing key. The “minor” feature generated tons of support emails and was completely broken for days while we waited for an expedited App Store review.

It’s not worth it. Join the closest post-traumatic-hard-coding community near you today!

Increasing or Decreasing Limits

When we launched video support into Cluster, we weren’t sure what kind of load we would experience on our video uploader. So we set a maximum duration for the video: 15 seconds. Since we knew that this limit would be going up, we built a custom config API call to give us the new time limit for video uploads.

After scaling up our backend from growing traffic, we were able to increase the limit to 60 seconds without re-submitting a new build to the App Store. Magic!

There’s no reason to hard code this stuff into your app. You might discover later that iPad Pros require better-quality uploads! Don’t make your users wait for a new version to start uploading better content.

Which In-App Purchases to show

If you have any in-app purchases in your app, you will probably want to offer holiday specials, and you’ll probably want short-term sales from time to time. Hard-coding this stuff in your binary is a fool’s errand.

A long time ago, before remote configuration, we were doing an in-app purchase promotion where the price would change at a certain date. Effectively, I was hard-coding a date into my app and showing a different in-app purchase. This, clearly, was a bad idea. But my server team didn’t have the bandwidth right then to make this a remote config, so I crossed my fingers and hoped that the in-app purchase would be different on the right date. You definitely should control this from your server(s).

Use Different Values Based on Device, Software Version, OS, etc.

In whatever remote config system you use, you should send up some local device and app settings, like:

Hardware Model (e.g. iPhone7,1)

OS (e.g. iOS 9.2)

App Bundle, Version and Build(e.g. com.myapp.TheBestApp, 3.4.1, 34)

Current Locale (e.g. en_US)

That way, you can set additional conditions on your config keys based on those settings.

For example, say a new iPad comes out (hello, iPad Pro!), and you realize it can handle way bigger images in your image-editing app, you can have it return a different value for a “maxImageSize” key.