-
Notifications
You must be signed in to change notification settings - Fork 39
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
base: master
Are you sure you want to change the base?
Conversation
Deploy preview for ios-factor ready! Built with commit 1ba1bcf |
|
||
- 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: |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
No description provided.