What is the best folder structure to build two twin apps with React Native?

Question

I need to create two twin apps with React Native and both apps will be 90% the same they will use some shared components and the styles will be different.

the question is : should i create one react native project and from there to building two apps

and the folder structure will be :

• ReactProject
  • shared
  • project1
    • components
  • project2
    • components
• index.ios.js
• index.android.js

and when I want to build one of the apps I will need to change the main component.

or should I create to different React Native projects

and the folder structure will be :

• shared
• ReactProject1
  • components
  • index.ios.js
  • index.android.js
• ReactProject2
  • components
  • index.ios.js
  • index.android.js

I would like to know what is the right approach to do this kind of project

thanks !

Bagasse

This is a matter of personal preference. – Peeler

We went the second way, now we have like 5 working apps , with the core javascript services/components in external shared folder and styling inside projects folder. It is pretty easy to work and maintain all of them in this way, but do think twice as much as possible about possible nuances – Vernettaverneuil

@IvanChernykh can you attach step by step process for creating such project structure – Gaiseric

Answer 1

This is absolutely a personal preference as stated in comments. One could easily increase the number of structure options beyond 2. Other than that I can share my experience on this.

We build an app, actually 4 (quadruplets), from a single react native project. We choose that way because our apps had to be highly similar. They share same functionality. Furthermore, when one has more than one of these apps installed on their device they can easily switch between apps via deep linking. However they differ on the theme colors, logos, names and backend services to call etc. One of the ways to create multiple apps from a single project is to rename the project. But you can still produce multiple apps while keeping the project name same. Then you need to change some project files accordingly. These files are, for iOS;

• Info.plist
• project.pbxproj
• AppDelegate.m

For Android;

• strings.xml
• MainActivity.java
• MainApplicatoin.java
• AndroidManifest.xml
• android/build.gradle
• app/build.gradle

Actually changing all these files manually is an error-prone and cumbersome action. So that in order to manage these changes we wrote a bash script that converts a base app to the version that we want. Using this approach we can manage 8 apps (quadruplets for iOS and Android) from a single project repo. In the end we are really happy about using React Native which let us build 8 production quality native apps in 3 months without knowing native app development at production level.

Cali

Nice! Could you provide a sketch of the bash script you built? Also, that script only manages the renaming process or also deal with the different styles, logos, etc? How did you approach those differences? – Cheapjack

@Cheapjack a sample script is here for Android. I would suggest after you build most of the main app then you prepare this kind of a script to morph other apps. Otherwise you need to spend so much effort to keep master files up-to-date. – Cali

Do you create a configuration file to enable/disable certain features/logo's in order to use the same git? Or do you create a git project for each app? – Banc

@Banc It has been a very long time since I have done it. But the idea was to keep everything under the same git project. Think about what you need to change to make an app look different (names, colors, assets), and the script was basically transforming the app's assets according to the given parameter (App1, App2, etc). We ran the script to complete the transformation before building and releasing it to the market. This way worked for us because the designated apps were 99% the same except for the names, color themes, etc. – Cali

Answer 2

I solved this by using a js script(scriptName.js) that moves your folder for one project to a base code, here is an example:

// Import necessary modules
const fs = require('fs-extra');

// Determine the app environment based on the script name
const scriptName = process.argv[2];
let assetFolder;

if (scriptName === 'project1') {
  assetFolder = './project1/assets';
} else if (scriptName === 'project2') {
  assetFolder = './project2/assets';
} else {
  console.error(
    'Invalid script name. Please provide "project1" or "project2" as argument.',
  );
  process.exit(1);
}

// Use the determined folders for the build
console.log('Script Name:', scriptName);
console.log('assetFolder:', assetFolder);
fs.copySync(assetFolder, './src/assets');

And run it with node 'theNemeOfYourScript'.js project1

Put a script to a root directory And make your directory structure like this:

project1
  -assets
    -someFile
project2
  -assets
    -someFile
src
  -assets
    -`You can put a dummy file for initial`

And use imorts as you would usually use them as import * from 'src/assets/someFile'

Sabo