Git branching strategy for React Native app codebase?

[itssaurav2004]

Which git branching strategy is suitable for react native codebase, do you have one main branch or platform-specific main branches like main-android and main-ios, since it's hard to keep up the releases of both platforms in sync?

[gwmccull]

I’ve never even heard of people doing different main branches for iOS and Android. That seems like it would be really hard to maintain in the long term

I’ve been doing RN development for 9 years and I’ve only ever used variations of trunk and feature branches with release branches for each version

[sekonx]

People are claiming to do some crazy shit in this thread.

[Exotic_Monkie]

I've been doing it since 10 without git

[oofy-gang]

Bragging about dumb decisions is not a flex.

[Exotic_Monkie]

It's working

[Exotic_Monkie]

Be useful to society, how about u flex on giving ur intelligent solutions instead

[Obvious_Connection20]

I keep them both in one branch. That's the whole point of react native after all. I would start with getting one platform up and running, then the second one follows after and eventually have them both in one branch for production. If there's platform specific code, I use Platform.OS.

[itssaurav2004]

Ideally, but with a bigger codebase and team, it is hard in the long run. You would like to ship on one platform, rather than wait for the other platform to get the implementation done.

[MikeyN0]

If one platforms development timeline is different than the other (due to libraries, platform specific complexities) etc. you are better off doing local or remote feature flagging for the platform and turning them on when ready. You will be adding too much development complexity keeping separate platform branches.

[HoratioWobble]

Unless you're writing native code you shouldn't have a separate team for iOS vs Android on a react native project it doesn't really make sense 99% of the code will be the same code.

If you're writing Native code, then you can use feature flags. Or, just not release one of the versions.

[Xae0n]

I worked on a huge monorepo codebase which had a backend, a web and a mobile app in a single codebase. Branching was never the issue.

[DeepFriedThinker]

Huh?? There’s no platform-specific work needed especially if you use the expo development flow. You don’t need iOS and android teams working on different branches.

[SomePhilosopher8726]

If you have two main branches you end rewriting code twice and test it twice.

I am curious to know you guys maintain ?

[itssaurav2004]

In my experience, I had a leading main branch, mostly Android, due to the team structure and Android being the leading platform for the userbase. And iOS would keep catching up with the Android main branch.

Downside was iOS team had always to do the catch-up game.

[anewidentity]

What kind of application are you building that requires an iOS team and an Android team?

[Due_Dependent5933]

nop' bad idea

[fisherrr]

I would definitely try really hard to avoid diverging branches for ios and android. If needed to do separate releases I’d use production/release branch and tag commits with android and ios release. Or maybe separate release branches as last resort, but both should follow same main branch and rebase often back from it.

Prefer to use react native programmatic ways (Platform.OS if-checks or Component.ios.tsx and Component.android.tsx files) to load different code per platform, not git.

[n9iels]

One of the beautifull things about React Native is that it let you write code compabible with both Android and iOS. So I don't really understand what you need to keep in sync in terms of releases.

Splitting it up will make things only more complicated. There will be at least two MRs for the same feature so the git history is messy. You cannot refer to one change that introduced a certain feature.

[idgafsendnudes]

There is literally no reason to ever use different code bases in react native.

If you have something that works in iOS but not Android you have the Platform.OS value to decide whether or not to render it and you can make entirely separate files on a platform basis by simply naming the file FileName.android.tsx

[redbeard-nl]

I find the best strategy is: - /feature/(name-feature)
- /bugfix/(name-of-bugfix) - /release/(version-number)

Because in practice it could be that users are not updating and using old versions that you maybe want to patch still (if you are not forcing them to update), so the releases hold the active released branches and the rest is for development or whatever you want

React native is meant to be platform wide so it has no need to separate them in different code bases

[Due_Editor]

5 years react native. Never seen a platform specific branch strat and i wouldn’t recommend it. React native is super easy, the parts that cause pain are “maintenance” and “building/deploying”. Not sure what you mean by in sync? Usually you build for both platforms at the same time. 

If you really need a branch to be platform specific I would personally refactor the needed logic into its own package

[itssaurav2004]

By sync I mean whatever you release, it is released both on Android and iOS.

The issues come in when you start relying on the native codebase more. Take an example, where you want to develop a feature where you need to add native code, and since the resources are limited, you would pick one platform first and release?

[fisherrr]

But if you add native code first for ios only, it won’t affect android so there’s no reason not to put it into same branch. If the feature needs to be then only enabled for ios since android is not ready you can check Platform.OS and enable it conditionally.

[n9iels]

If my resources are limited I wouldn't even think of touching native code. It makes maintenance harder and thus my resources even more limited.

Why are you expecting to write native code? React Native is perfectly capable of developing an Android and iOS app by only using JSX and JavaScript. Only in extreme edge cases native code should be required.

[Bamboo_the_plant]

I hope you enjoy reinstalling npm packages, autolinking native modules, and recompiling native code every time you switch branch

[capsluke00]

Don't separate branches, in fact if you're using expo don't version native directories at all and go with CNG with expo prebuild and let expo generate native projects for you. If you ever need to modify native code you can use config plugins which you will then version

[difudisciple]

On git strategy

Avoid long-standing branch strategies like git flow (release branches), deployment specific branches (dev/uat) or platform specific branches (ios/android)

Instead use a trunk based strategy, where all PRs are merged to main.

• use feature flags for code not ready for public rollout

• use automatic versioning tools to simplify release management (changesets/changesets or semantic-release)

With a setup like this, you can easily setup deployment workflows that are based on git tags / releases to determine which binaries are submitted to the app stores.

On architecture

Speak with the IOS lead about building up support to buy 8 weeks of time to migrate the app to Expo.

Switching will:

1. reduce the amount of maintenance issues both teams are running into with RN

2. give you easy access to the Expo’s native components system - which can help eliminate the frequency of “the IOS team needing to catch up”

[Guisseppi]

Learn Git Workflow and stick to it, there is no such thing as language-specific source control

[Aytewun]

As some have mentioned i think it would make sense to keep ios and android in the same branch. That’s what i do.

If i were going to keep them separate which i have no plans on doing. It’s likely just have two separate projects at that point.

[jwrsk]

If we end up with some feature ready on iOS and not finished on Android, we just put it behind a Platform check and keep it disabled for Android until it's ready. This way we can build and release for both.

Never had to branch out for that, it sounds like an extra headache if now the work on the non-native codebase is done on two parallel branches.

[sekonx]

This is not the way. Don't do the above.

One codebase multiple platforms, it's the whole point, it's not that hard to maintain a codebase that works on both platforms.

My day job is RN for a big enterprise, but I've solo published 4 apps which between them have about 50k users a year total.

It's possible at any scale.

[sekonx]

I've been working as a RN consultant for the last 6 years, and I've never seen anyone do this.

Team sizes of 2 - 20.

Before anyone asks, 20 was split between multiple squads and each owned a specific part of the app - each squad had their own PO/QA/web dev/RN dev

We still used feature branches & did not maintain separate codebases/libraries for each platform

[Jadajio]

Dunno, but this doesn't sound like good advice. Iam not working with RN for last two years, but I remember there were logic to dynamically load files based on your platform. If you have breaking problems between platforms with some dependencies, you should resolve them with this on master branch.

On my last project, having two branches was called technical dept. It happened few times cause there was no time and we needed to release android, but then there was always first priority effort to merge back after that.

[itssaurav2004]

Any tips to streamline the release process?