You could use a monorepo approach and build from libs. I'd recommend you checkout nx by nrwl.

I had a similar kind of problem set while developing a white label app.

Here are my project requirements:

• Localization
• Theme customization
• Login Flow

I implemented a white label solution in the following way:

Let's say we have two customers i.e. Dine Out & Zomato.

• Create the main app flow i.e. the features which will be shared across the multiple apps in react-native.

• Make sure that you write the code configuration using flags/values and make reusable components. Ex: let's say Dine Out only accepting parcel take away not delivery but Zomato does so. Similarly Dine Out has a black colour navigation bar but Zomato likes brighter.

• Make configurable item's keys are same for all the apps.

Main White Label Configuration at Native Side:

iOS:

In terms of XCode, we can consider the Zomato & Dine Out as two different Targets in Xcode. So create two Targets & create the build configuration to set the multiple environments i.e. debug, release.

From the above image, you can see that there are two targets under the TARGETS section. And five Build Configuration under Build Active Architecture Only.

• Create two directories from the project navigator section & paste the configuration files & target assets.

• Select all the files from the target directory and only check the target for which you have added the assets & files from the Inspector section.

Android:

In terms of Android Studio, we can consider the Zomato & Dine Out as two different Flavors. So create two apps Flavors & create the buildTypes to set the multiple environments i.e. debug, release in app-level build.gradle file.

• Create two directories from at ./app/src/ path with the name same as build flavour names & paste the configuration files & target assets. After doing this, you will have a directory structure like the below image.

You can find detailed configuration for android from here.

React Native:

If you have followed all the steps till here then you are done with configuration from the native side. Now you only need to access the values related to Target/Flavour in react-native.

There are some important libraries in React Native that can help to fetch the values from native to React Native environment.

1. react-native-build-config: From the above image in the Android section you will see a buildConfigField field APP_ENVIRONMENT of type String. You can access this variable value by using this library in React Native i.e. BuildConfig.APP_ENVIRONMENT. Similarly, you can add the APP_ENVIRONMENT variable in iOS as shown in the below image.

2. react-native-fs: Use this if you are keeping configuration in JSON file in native directories. In above configuration, I kept PilotConfig.json file which can be accessed in React Native using fetch('PilotConfig.json) for iOS & RNFS.readFileAssets('PilotConfig.json') for Android.

3. react-native-localize: You can use this library for loading locales. It also provides a listener in case the user changes the device language.

Rest everything is at the logic part in JavaScript, how you implement.

Multiple Firebase apps can also be configured using build script.

I will start with a config file. e.g: config.base.js (JSON) Then override the base confi with: config.custom.js

And each customer will have their own config.<customer_id>.js file when you build, you can copy the customer config file to overwrite config.custom.js

Example how to load config into app

let baseConfig = require("./config.base.json");
const customConfig = require("./config.custom.js");

appConfig = Object.assign(baseConfig, customConfig);

export const FEATURES_ENABLED: [{id: string}: boolean] = appConfig.features;

The app code will depend on FEATURES_ENABLED to render

For your situation, I suggest you to create your own npm package for your app core features:

Benefits:

• You can update/fix your core inside the package project instead of every single app project
• If you want to update the core for existing production apps, just npm install again or update your package version
• Have better versioning control on your core code
• If your core codes don't have any business logic, you can open-source it and let other developers use and improve it together (optional)

Therefore...

If you don't want to expose your core codes, just create it as a private npm package: document

Or if you are ok to open source it as a public package: document

Cheers!