Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ideas about run time config #27

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions factors/config.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,13 +14,18 @@ Apps sometimes store config as constants in the code. This is a violation of iOS

A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.

There are many ways on how you can inject config values during build time
There are many ways you can inject config values during build time

- Configuration files (e.g. JSON or YAML files)
- [cocoapods-keys](https://github.com/orta/cocoapods-keys) to better hide keys and apply them to your iOS app during build time
- Custom built solution (e.g. using a build phase)

As deployments on the iOS platform are significantly slower than server deployments, you might want a way to quickly update config over the air (OTA) to react to issues fast.
There are also techniques for providing config values at run time:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to say, I don't fully understand this, can you tell us a bit more about it on why one should use it for?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! So in the same way that 12factor server apps provide config at run time via environment variables, iOS apps can have similar using these techniques. The reason we want run time config is because with build time config, the build you are testing is not the build that is sent to real users. If you build one app package, and then for testing you run with some run time config, provided via a url or a shared keychain, then you can test the actual build that will go to users. This also simplifies the entire build pipeline, because you then have just one app package that's built, tested, shipped to users. And if you already have multiple targets or versions of an app, this dramatically reduces the complexity involved.

For example, say you have an api server to connect to from the app, and you need to test against a different instance of the api to the production api.

You can load the url for the api from a plist with entries like:

	<key>default</key>
	<string>https://api.example.com</string>
	<key>test</key>
	<string>https://test-api.example.com</string>

So now, when testing the app, you can open it with a link such as myapp://?api_instance=test, and you're testing the production build of the app, but with whatever run time config you need.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So is this something you're happy to add with some extra explanation?


- Linking into the app with a custom url scheme
- Using a shared keychain and a separate app for configuration

As deployments on the iOS platform are significantly slower than server deployments, you might want a way to quickly update config over the air (OTA) to react to issues fast.

OTA config updates are powerful and allow you to instantly

Expand Down