Why I’m betting on React Native for my next Startup
[UDPATE AUGUST/2017: I've changed my mind on the topic and we are not using ReactNative anymore. You can read my reasons behind it here.]
There is a scarcity of information about comparing the pros/cons of building mobile apps with React Native vs. fully native. You can either find people discussing how it compares when they did a prototype (not a full-featured app) or people trying to push an agenda one way or the other.
I spent the last three months pondering what I should do for DoctorLink, and I finally settled: React Native + Native.
I’m writing this as the person who’s heading the product and the engineering, so I looked at it from many perspectives, including long-term maintainability, the maturity of the platform, recruiting, team collaboration, etc. I consulted a dozen CTOs & VPEs to ask their thoughts on the topic. I combined that with my experience leading mobile teams building for Android and iOS.
This is not for you
My decision is not based on an all-encompassing view of how to build mobile apps, but in the requirements of building DoctorLink. If this was an experimental app or prototype, if I was making a game, if I expected a high-level of interoperability with other pieces of the ecosystem (e.g. Smartwatch), my conclusions might have been different.
This is also not a tear-down of the technology. There are quite of few of these posts out there, although most of them are crap because they focus on the wrong minutia or on short-term issues that are just a bug fix away.
Context on DoctorLink
To be clear, DoctorLink will be a pretty massive app, both regarding code (in the App itself) and the surface area of the UX. I expect in 3 or 4 years for us to be maintaining 500K-1M LOCs (excluding 3rd-party components). The user experience itself will be very modular depending on who the user is. Think an app more like Facebook than like Duolingo, with “sub apps” (e.g. Groups, Photos, Pages, Events, etc.). Our Mobile team will be anywhere from 6–12 developers, some working on “core” and some working on “sub apps.”
ICYMI: What’s React Native?
Google it. If you think it’s like PhoneGap, you don’t know what it is.
So why I’m committing to React Native?
On Uniformity of Experience
Some product managers might obsess about having the two mobile apps (Android and iOS) look the same to avoid creating a bad user experience. That’s a naïve view since (nearly) no one has two phones with them to keep comparing apps. The problem with experiences that are not uniform is not the same user being confused by one or the other; it’s by your content, functionality, and partners having to cope with what can be two distinct apps (sold as one). Customer support gets more complicated; sales pitches get more complicated; content marketing becomes harder; Even sprint planning takes a hit. You get the gist.
And it’s not hard to get your Android and iOS app to get out of sync if you have native code bases. First, it’s likely you have dedicated developers for each platform. When a developer goes on vacation, quits, or she's just more productive in implementing a new feature, the apps go out of sync. Over time, you are playing a catch-up game by sacrificing low priority issues, over-staffing, or just making excuses why they don’t have the same features. You can address this by throwing a lot of money into the problem, but you are just treating the symptom then. In some cases, that’s the right tactic.
With React Native (and Xamarin, Ionic, PhoneGap or whatever cross-platform solution) you significantly minimize this. Even if 20% of the code still needs to be native, it’s much easier to keep it going. And the reality is if done right, cross-platform development can get 90–95% code-share.
On Team Cohesion
I much rather have a “Mobile team” than an “Android” and “iOS” teams. You could aim to hire only developers who are excellent on both platforms, so they can seamlessly jump from one platform to the next, but that’s easier said than done. The overlap of developers who are proficient in both platforms is probably less than 5% of developers who feel they are proficient in just one.
On Maintenance
Two code-bases vs. one code-base. Any question? OK, I’m just kidding. You’ll have three code-bases actually, not one. Not only that, you’ll have a new class of problems, as in it works this way in iOS and that way on Android, so let’s put an “if” statement in the code. That’s still is a better set up IMHO because the feature’s code is kept in the same place. When you need to change a feature, you can visit a single place (again, you could have to visit three places, but if you’ve done cross-platform development right, you’ll understand the benefit).
On Recruiting
It’s very hard to recruit mobile developers. It’s even harder to recruit mobile developers who adopted React Native. The only people I want to hire at this point are those who have a Native mobile development background and decided to give React Native a try. So, my choice of React Native is counter-productive to fast recruiting. I’m so confident this is the right technology choice I’m willing to take a short-term hit. I also hope to establish our Mobile team as a thought-leader in modern mobile app development, using the best of each world (Native + React Native) and building the most successful and widely used React Native out there (well, excluding any apps by Facebook). Patience will pay off.
On Scalability (of the Technology)
Have you heard of CodePush? Holy shit! It’s amazing. I’ve been doing Server/Web development for two decades. The idea of having your code ready for production and need to wait days for it to reach your customers is daunting. CodePush, if done right, makes your Mobile development have near the same speed of your Web front-end development regarding CI/CD/DevOps. The dynamic of a team changes when they know they can fix a bug in a mobile device in 10 minutes. You get none of that going full native.
The power of fast deployment, combined with staggered roll-outs (just a % of your users), and the availability of rollback functionality is something that didn’t exist in the Mobile world. Mobile teams can now think different on their Sprint and Deployment strategy. This is game changing!
On Testing
Two completely separate apps mean two completely separate testing code, systems, and processes. There is no way around it. Anything above the API level will need a unique set of tests. With cross-platform, you can comfortably reduce that. It won’t be one testing system, but 60–80% of the tests will cover both platforms, so that’s up to 60% fewer tests to write and maintain.
On Migrating (Tech & Team)
Instagram wrote an excellent post of incrementally adopting React Native in their app. I’m starting from zero, so I don’t have to migrate anything, but knowing that we can combine React Native with Native code and go back-and-forth as we change our mind on what should be what is of great comfort. The simple examples would be something that would be faster, more elegant, or not possible with React Native, and that we would implement it natively on each platform; or, the feature that we had to implement natively before and now there is the ability to unify the code into a React Native component. All that without wholesale rewrites or big projects.
The second component of this is that React Native uses JavaScript. I honestly don’t like JavaScript. It’s just not a great language. But, I’ve been using it for 15+ years. It’s the universal programming language that more and more permeates every aspect of a developer’s life. So, it’s reasonably easy for an iOS or Android developer to pick up JavaScript. Not only that, but it’s faster and easier for an Android developer to learn React Native and develop for iOS than for this same developer to be proficient in UIKit/Swift/Xcode (same thing for an iOS developer building an Android app).
On Long-Term Viability
The momentum for React Native is growing. A year ago React Native was a neat idea. Now, it’s the reality of many apps in the App Store and Play Store. Facebook is putting many resources behind it, and the community is becoming stronger. I have no question in my mind the next 12–18 months we’ll see an explosion of tooling, components, books, best practices, and services for React Native developers and products.
What about Cordova, Xamarin or Ionic?
Ionic is an evolution of Cordova. Cordova is just not good. Been there, done that, it worked only in the early days and then you hit the bottleneck. The problem with these technologies is that they put a layer between the phone OS and the app (which is the WebView) that can have many limitations on what’s possible and the user experience. I wouldn’t rule-out those for other types of projects, but they won’t work for DoctorLink.
Xamarin is more like React Native in the sense that once it’s all compiled it runs native code. I have built a few apps with Xamarin, and I love that it uses C#/.NET (strongly typed + robust framework), but I find it to be missing something. Maybe it’s the bugs, or the inconsistencies throughout, or something else. I also think it’s harder to find developers for Xamarin than for React Native. I still use Xamarin for side projects & prototypes since I’m quite proficient in C#/.NET, but it’s not my choice for DoctorLink.
What don’t I like about React Native?
Did I mention JavaScript? Sure did. I don’t like it. You can use TypeScript to give it a little more robustness to the code base, but still is a very limited language with a very limited core framework. Compared to Python, Go, .NET, and Java the built-in libraries are just weak and incomplete. No wonder anything built with JS lives or dies by NPM. Date-time, Lists, Cryptography, Encoding, Math, and more libraries are consistent and solid in the four languages/frameworks mentioned above, but not in JS.
I also don’t like that React Native allows developers to mess up their separation of concerns. Most languages allow you to do that, but in some, it’s just harder; very easy in React Native. Finally, React Native is still developing the proper patterns for large scale projects. There are still very divergent opinions on how to structure files, separate components, architect the app, etc. We are at a phase of great innovation and experimentation for this framework, and, in time, we’ll go through a period of convergence and extinction. My hope is that I’ll hire incredibly smart developers who can see a year or two into the future and make the right architecture and structural choices for the app.
And… We are recruiting… 🚀
And just in case you are a Native iOS and/or Native Android developer, have dabbled with React Native and are interested in making a dent in the healthcare world, we are hiring here in London.
