I'm wanting to setup a proper deployment pipeline for our apps using React Native so that for example in iOS we have a:
Debug version for the development team
Internal Release UAT version
Release Production version
Now with the default setup, using the Schema "Debug" and "Release" allows for 1 and 3 but how can I add another for point 2 which will still make React Native build as a release?
We're using Code-Push and I want to have some separate config for point 2 and 3 which is why I am asking this question. Same will go for Android too.
Related
I'm working on an enterprise React Native project that targets customers' backend installed on-premises. Some customers are slower than others to upgrade the backend and we still need to support them.
Instead of using feature flags, would it be possible to set up a workflow so that:
each release branch gets bundled as (e.g. release-v1, release-v2, release-v3,...)
we configure the compatible app version on the backend
the React Native opens up, fetches the compatible app version number, and loads up the appropriate bundle
With git you can group different branches that hold different versions of your app:
ANDROID:
path: yourProject/android/app/build.gradle
search and change: "versionCode" and "versionName"
iOS:
Open xCode
Select app project
Go to "General"
Change "version"
If you need get app version from Javascript use "react-native-version-info":
https://www.npmjs.com/package/react-native-version-info
You could organise your codebase so that it is flexible for all the different 'flavours' of the app.
For example:
Main code branch (all your base code goes in here, shared functionality, etc..)
Branch v1 - the differences on top of your 'main' branch for this version
Branch v2 - as v1 but with specific changes for v2 users
Branch N - ...and so on
Then each Branch 1,2,N version of the app can have it's own bundle Id and be released as a separate app.
You have 1 codebase to work on. Updates can be made on main and trickled down to Branch N apps if needed.
Specific "Branch" updates can be made and pushed to the relevant code branch.
I am working on building a modular React Native App for Enterprises in which it requires adding or remove packages as features or plugins (without updating the app). The following shall be a process
An enterprise user shall download and install a base mobile Android/iOS app (build in React Native) in a mobile handset
From the back-end, multiple packages or features (may defer with other enterprises) shall be configured for an enterprise
The multiple pre-built packages/modules shall be kept at a store at the backend
The enterprise user shall automatically get the packages as features in the mobile app using step 1 above, post step 2
I don't have any issue handling and building the backend and react native app. I am struggling that how dynamically adding/removing a package is possible in the existing base mobile app based on backend configuration.
If those packages/features are javascript only you can try codepush. This will allow to change the js bundle runtime. Check out this section: Dynamic Deployment Assignment
However if those packages require native implementation the only solution would be to split your code. This way you would need to ship every package in the apk, but the main bundle will contain only the code of the "base" app and the other code with the additional features would be loaded runtime. This will also bring a huge performance boost.
You can easily control which user sees what by conditionally rendering the screens by a role or whatever.
For code splitting you can check out these repos:
react-native-bundle-splitter or repack
Before i continue, let me let you know that i know the code to deply to a targeted build for codepush
appcenter codepush release-react -a aountName/appName -d Production -m --description "CommentHere" -t versionName
I have tried to figure this out on my own and i have not been able to.
I have several versions of my app which i have deploy using CodePush and everything works well but I started having fears of crashes when i installed new packages on the latest build.
This implies the current code base would have new native differences as compaird to the old version.
The question is how can i deploy my new build with new native codes
and packages present to an old version of my app which does not have those
native packages without running into several crashes from all the users using the old version of the app...
I ask this cos i have a feeling if i push the new build with the new changes in UI and native chnages to the old version of my app, the app old app would crash.
If a bug comes in for an old version, how do I fix it and deploy it
for the old version only? Bugs may be critical and not everyone will
have the latest version of the app Or, the bug may only exist on a old
version of the app.
I await your response.
Code push will not affect any native code written within the Android or the iOS projects of a React-Native application. If you read the documentations carefully, it specifically says that it does not change / modify / update the native portion of the app.
Why?
This is because of the way the CodePush mechanism works. In essence, CodePush only stores and triggers the update of the JS bundle of the React-Native application.
This is why we wrap only the JS main app instance with CodePush HOC (Higher Order Component). This is what's happening when you do:
CodePush(MyApp); //wrapping the js bundle at app-root
So, unfortunately in your case, if there are native codes involved, regardless of deployment to a new or old version of the app, it has to be a AppStore / Playstore driven deployment.
Scenario
I have two apps that are identical except for some minor textual differences. Currently I have 2x projects and would like to condense them into one.
eg.
React Native Project
/ \
Xcode build 1 Xcode build 2
Another important caveat: App Signatures
I assume the App Stores recognize app uploads by some sort of archive/compilation signature, not by app name. This is why I'm wanting to do 2 separate xcode builds rather than 1 xcode build.
Question
Can a React Native project maintain 2 separate Xcode builds?
Running multiple builds off of the same application is a pretty common paradigm in iOS development, and this holds true for React Native as well.
The instructions here should get you well on the way to configuring multiple builds, with unique bundleIds (what the app store will use to recognize it as a unique application).
To test them out on your machine after configuring everything, you can use the following command as an example.
react-native run-ios --simulator 'iPhone X' --scheme 'YOUR_SCHEME' --configuration 'YOUR_NEW_CONFIGURATION'
I would start by just duplicating your Release config and renaming it, just to make sure that it runs fine on your machine before you start playing around with the configuration.
I am currently working in a team developing a react native IOS application, we are all doing this for the first time. I am unable to find any information on development setup with many people working on the same code and we are running into many issues requiring each member to have their own project, and one person with the master project is having to copy and paste code over, any pointers much appreciated!!
Initial project build is successful, the problem occurs when someone else clones the repository and attempts a build. Too many errors to go over and different with each machine. Is there some setup in X-Code or something I am missing with regards to working in a team environment with react native?
Because React native use many libraries like module to help build app fastly and reuse.So, I suggest this workflow to build mobile application with RN.
- Use GIT as system version control
- Use IDE (Android Studio, Xcode) to help auto build and fix a lot build error when your team install new libraries and use `react-native link` (ex: react-native-router-flux,...)
- Just push js file to repository and other member can pull it and reload js file.
- Do it and take a look some repository on github with tutorials
Cheer!
Using Yarn rather than Node package manager resolved a majority of the issues.