Releasing Mobile (React Native) Artifacts with Config File

Question

Taking inspiration from The Twelve-Factor App: V. Build, release, run, I'm working on updating our CI/CD pipeline with these three distinct steps in mind for an app being built with react-native-web.

Specifically, I want to:

1. Build: generate an environment agnostic artifact of the code for each platform (web, android, ios)
2. Release: take an artifact and a config file (API URLs, API keys, debug settings, etc), and release to each platform

This is trivial for web, which is what The Twelve-Factor App had in mind. My question is how do I read a config file on mobile platforms and how can I incorporate this with react-native-web build artifacts? Does my artifact need to contain all of the source code and dependencies so I can pull in the config at release time and build then?

Ideally, each artifact would contain code compiled for each platform that somehow knows how to pull in a config file and do something with it. Next best would be to have the source code for each platform that I can compile with a config file at release time. Third best is have a way to give each distribution enough information at release time so it can request the config at runtime.

Full disclosure, I know nothing about building and deploying mobile apps so I apologize if there is an obvious solution for this!

Answer 1

It's similar for Android. Once the build binary is created it's immutable. So unfortunately that negates option #1. We can't do anything else with the binary once we build it.

I think for react-native option two is the best approach. Essentially you'll need to build the apps at release time once you have resolved what your configs need to be. That avoids any overhead of loading stuff at runtime in option #3 and still matches nicely to Twelve Factor. You'll still have a mobile binary that matches the same configuration as your release type.

For actually reading those values, you can just drop the config file into the project's root and we can help with the setup to pull them in. I'll be glad to discuss those details if you'd like.

UPDATE:

Anything iOS does we can do (almost as well)

Current build tools compile all code into bytecode classes.dex and compress all resrouces into resrouces.arc but res/raw is left untouched. This gives us a place to inject our files. From there, the app will be able to read and parse at runtime.

Answer 2

For iOS, the build and (non-App Store) release process works like this at a high level:

1. Archive your project in Xcode, which results in an .xcarchive artifact.
2. Export your archive which signs and generates an .ipa file.
3. Either host this .ipa file yourself (with some additional metadata files) or upload it to a service like HockeyApp for distribution.

There are a few ways that you can manage config inside an Xcode project. One fairly common and straightforward way is to use the info.plist file to store custom keys and values. The app can then look up and use these values at runtime.

In the scenario you describe, it sounds like you want to be able to inject specific config values after step 2 but before step 3. Fortunately, the .ipa file generated during step 2 can be extracted, which will reveal a Payload folder containing an .app file. This file can be inspected, and inside you will see, amongst other things, the app's Info.plist. Modifying this file will allow for injection of whatever config values you want to set.

This will save needing to manage configs inside the Xcode project, and creating a separate archive for each configuration of the app. However what this doesn't solve is step 3. You are still going to need to distribute each configured .ipa file separately.