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

Conversation

mbaltaks
Copy link

@mbaltaks mbaltaks commented Jun 6, 2018

No description provided.

@KrauseFx
Copy link
Member

KrauseFx commented Jun 6, 2018

Deploy preview for ios-factor ready!

Built with commit 1ba1bcf

https://deploy-preview-27--ios-factor.netlify.com


- 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants