3 ms·

I was heavily involved with the rollout and maintenance of React Native(RN) at my previous job. This post touches on an interesting point that has just now crys

I was heavily involved with the rollout and maintenance of React Native(RN) at my previous job. This post touches on an interesting point that has just now crystallised in my head. In particular the OP writes: > Fortunately, I could find the bug in the library with my Swift skills, fix it within a day and even submit a patch to the owner of the repository. But I could find and fix it only because the library and my app were written in the same language, and this was a language that I was familiar with. We adopted RN because we had a lot of web developers(hundreds) and wanted to enable them in contributing to our app. We explicitly didn't make it a goal to achieve code sharing, yet we did, to the tune of 90% of the code. Overall RN was successful for us. However, one thing became apparent immediately: the RN developers needed support from native teams. As soon as the RN developers hit a problem that required bridging native APIs or a bug that required platform knowledge, they end up blocked with no way to unblock themselves. Luckily we could create a team of platform experts dedicated to supporting these developers. This highlights the unfortunate paradox with cross platform tech. It's a great choice for solo developers or small startups looking to find product market fit and iterate quickly. They might be fooled into thinking that they can get by without learning the platform native methods and languages, only to find that they end up stuck when the leaky abstraction eventually leaks. On the other hand, a well resourced company that can dedicate a team of platform experts as support for the cross platform developers will not suffer this problem, but is cross platform the right choice for a well resourced company? Such a company has probably already found product market fit and is better of paying the higher cost of native development to build a higher quality app. A big takeaway from my RN experience is: One might expect that an RN developer can get away with knowing less about mobile than a native developer. Counter-intuitively, the opposite is true. A solo RN developer will, of course, need to know JS and React, but when the abstraction leaks they'll also need to be comfortable with Java, Kotlin, Swift, Objective-C, the respective build systems(CocoaPods & Gradle), and even C++. If one considers RN's origin, being an internal Facebook framework. It all makes sense. RN was built to allow more developers at Facebook to contribute to their apps, without requiring them to learn native technologies or languages. Of course, Facebook has the best imaginable team to support these developer, the RN team itself.

je42 5y ago
This totally true. I think however, Flutter does a better job in fixing platform related issues. Also, in my experience upgrade to a new version of RN was usually very painful, with Flutter so far it was straight forward.
nicoburns 5y ago
I think the way to set it up is to have the senior engineers on your RN team be the ones who know everything: they are experts in JavaScript, but they are also comfortable dropping down into Swift/Objective-C and Kotlin/Java when needed. Then you can have junior engineers who are more focussed on the JS side of things (at least to begin with). They key thing here being that the people who can unblock are on the same team as the people who may need to be unblocked and can thus prioritise doing so quickly. If you need extensive native code for custom modules (we haven't yet needed this at my work) then it would make sense to have native developers on each platform take a lead of that. But there should absolutely be people on your RN team who can do integration work and bug fixing independently of that team. I think the key is: if you're working with cross-platform tech then you ought to have cross platform developers.
- K0nserv 5y ago
  Absolutely, but this speaks to the paradox I think. Cross platform is an attractive choice, precisely when you don't have a such a person. For example, as a solo developer with no native knowledge who wants to ship an app or a small startup hiring their first mobile developer. Being proficient in all of Web(JS, React), Android(Kotlin, Java, Gradle), and iOS(Swift, Objective-C, CocoaPods) is a pretty significant ask for a single person too. Personally, I check two of those boxes(iOS and Web), adding Android as well would be a bit much.
  - nicoburns 5y ago
    Hmm... I don't necessarily think it needs to be a single person knowing everything. For example a team made up of you, someone else who knew android and web, and a bunch of people who only knew web would work really well I think. Those who were experts in the native platforms would be responsible for bringing the rest of the team up to speed (providing context, advice, pointing to learning resources, etc). As someone who came to a react-native project (as the lead) with a web and cordova background and no prior react-native or native platform experience, I've found that just knowing about the ios and android build systems and being able to add basic code to the AppDelegate (ios) and MainActivity (android) has been entirely sufficient for our needs. It would be different if we needed custom native modules (although I'm confident I could learn - I think learning something specific like that would be easier than trying to work out how to structure a whole native app), but then the react-native ecosystem is pretty broad these days. A lot of things are covered.

je42 5y ago

This totally true. I think however, Flutter does a better job in fixing platform related issues. Also, in my experience upgrade to a new version of RN was usually very painful, with Flutter so far it was straight forward.

nicoburns 5y ago

I think the way to set it up is to have the senior engineers on your RN team be the ones who know everything: they are experts in JavaScript, but they are also comfortable dropping down into Swift/Objective-C and Kotlin/Java when needed. Then you can have junior engineers who are more focussed on the JS side of things (at least to begin with). They key thing here being that the people who can unblock are on the same team as the people who may need to be unblocked and can thus prioritise doing so quickly. If you need extensive native code for custom modules (we haven't yet needed this at my work) then it would make sense to have native developers on each platform take a lead of that. But there should absolutely be people on your RN team who can do integration work and bug fixing independently of that team. I think the key is: if you're working with cross-platform tech then you ought to have cross platform developers.

K0nserv 5y ago
Absolutely, but this speaks to the paradox I think. Cross platform is an attractive choice, precisely when you don't have a such a person. For example, as a solo developer with no native knowledge who wants to ship an app or a small startup hiring their first mobile developer. Being proficient in all of Web(JS, React), Android(Kotlin, Java, Gradle), and iOS(Swift, Objective-C, CocoaPods) is a pretty significant ask for a single person too. Personally, I check two of those boxes(iOS and Web), adding Android as well would be a bit much.
- nicoburns 5y ago
  Hmm... I don't necessarily think it needs to be a single person knowing everything. For example a team made up of you, someone else who knew android and web, and a bunch of people who only knew web would work really well I think. Those who were experts in the native platforms would be responsible for bringing the rest of the team up to speed (providing context, advice, pointing to learning resources, etc). As someone who came to a react-native project (as the lead) with a web and cordova background and no prior react-native or native platform experience, I've found that just knowing about the ios and android build systems and being able to add basic code to the AppDelegate (ios) and MainActivity (android) has been entirely sufficient for our needs. It would be different if we needed custom native modules (although I'm confident I could learn - I think learning something specific like that would be easier than trying to work out how to structure a whole native app), but then the react-native ecosystem is pretty broad these days. A lot of things are covered.