React Native as a Strategic Technology Choice

When Im interviewing candidates for the mobile platform team (did I mention we have an opening?), as well when talking to current Mattermost employees heck, even when talking to random people on the street, one question keeps coming up:

Why did you decide to use React Native?

With the mobile v2 beta (fully written in React Native) out the door, it may be a good time to reflect a little on this technology choice, to see if we still feel we made the right call when we went this direction a few years ago.

Indeed, lets talk technology strategy.

But Zef, you may say this is is what the Hacker News front page is for, no? Sure, thats one strategy, but controversial statement alert theres potentially more to consider than just the hot tech du jour.

How should we approach making technology choices? What do we consider?

Lets use Mattermosts mobile application as a case study.

To be able to frame this discussion, let me start with a few sentence introduction to Mattermost. Mattermost is a suite of tools to streamline communication within developer organizations. At some point you could have crudely positioned it as a an open source Slack/Microsoft Teams alternative that you can host yourself today, at the product level weve expanded to also include Trello-like Boards and Playbooks to support recurring multi-step processes such as production incidents. And on the deployment side, we now also have a cloud-hosted version (which, as of 7.0 has a free tier).

What is relevant here: our product is significant in scope, its business critical to peoples day to day work (so it should, you know, work), we have an R&D team of around a hundred engineers and product people that builds it, and as we take open source seriously, we receive significant contributions from our open source community.

In this discussion, Ill largely leave aside the historical context in which this direction was taken some years ago, and look at it with fresh eyes. So, for the purposes of this exercise, let us for a few minutes imagine we have no mobile app yet, the world is our oyster. We can take any strategy we like. What path do we take?

We have to start with the existential question: do we need a mobile app at all?

Building one is going to be a significant investment, so the cheapest and simplest option is to simply not do it, right?

In 2022, this is a tough sell for a product that aspires to be the communication layer for modern-day developer teams. The world is increasingly moving to mobile, and while a lot of engineers time is still spent using laptops and desktops (while typing the codes, drawing the UIs, and dragging the cards), communication cannot stop when leaving a stationary machine. Checking and answering messages, adding some comments to cards, checking off items on your playbook run, all should be possible even while waiting outside your kids school to pick them up, or while using the restroom. This is the flexibility that we want to enable for the software teams of the future. And ourselves.

So not doing anything for mobile isnt an option. Sorry.

Next least-effort step up: making the web app work on mobile.

As it turns out, we did that. It still works, kinda, when you open Mattermost in your mobile browser. And theres still the Mattermost Classic app on the AppStore thats effectively a thin wrapper around the web app. Please dont use it, its not very good. Why is it not very good? Partially its because we didnt invest that much into it, but also because its still impossible to match a native experience using web technologies on mobile. It may have been Steve Jobs original vision for iPhone, 14 years ago, but it hasnt happened. And sadly, its not in most mobile operating system vendors interests to truly make it happen either, sadly. So yes, you can make it work. But is it going to be great? Likely not. And since Mattermost is an app youll want to spend a lot of your time in, we do need something great.

Next alternative option: building native apps for iOS and Android.

While not everybody is happy with it iOS and Android have won the mobile operating system wars for now. So, why not build native apps for those two? If you want great, this it the way to do it, right?

For sure, however theres two challenges with building native apps for two platforms:

First, its two platforms that dont naturally allow for a lot of code sharing. iOS native apps are built using Swift, Android apps using Kotlin and their APIs are fairly different. As a result you need to implement every feature three times: once in the web app, once for iOS and once for Android. Reality check: in our current react native strategy its already a challenge to prioritize implementing features in one mobile app (rather than just the web app). Now try to do that for two mobile platforms. Aint gonna happen. No sirree doodles.

Second, skills. We try to staff our feature teams with full stack developers right now. What does full stack mean? You know front-end (TypeScript and React) and back-end (Go). Finding people that are already fully familiar with this stack is much akin to finding unicorns, so we usually compromise: if youve done frontend and backend before, but with a slightly different stack, well assume youll pick up ours quickly enough. Great. However, now were going to develop native mobile apps for iOS and Android as well. We have two options: either we redefine fullstack to also include knowing Android and iOS in addition to web and backend, or we start staffing two entirely new roles: iOS engineer and Android engineer. As to redefining fullstack: good luck telling your people that they now also need to learn Swift and Kotlin (and all associated tooling), not everybody will be excited. As to staffing new roles: this is going to be a challenge too, because likely youll need to either add two extra engineers to each feature team, or create an iOS and Android team, which comes with its own whole slew of problems (that I wont get into now).

Lets be clear, though. Given unlimited time and resources, building separate native experiences for iOS and Android is the best solution. But youll be shocked to learn we aint got neither of those.

So, we have to compromise somewhere. Is there a middle ground that still has a good set of trade-offs?

Enter cross platform apps. Today there are three somewhat serious contenders:

1. Metas React Native
2. Googles Flutter
3. Microsofts Xamarin

Let me quickly go over these in reverse order. Xamarin allows you to build cross-platform (iOS, Android, but also macOS and Windows apparently) apps using C# and .NET. This is a viable option, but from where were standing it doesnt seem to have the same size mindshare compared to the other two alternatives especially in the open source sphere. Even if it would be the technically superior option to the alternatives, we have to think beyond that: how do we hire for this skill set, and can we attract a community of open source contributors to such a code base? Of the three, this is likely the riskiest option.

Then, theres Flutter. Like Xamarin, Flutter allows you to build cross-platform apps (iOS, Android, MacOS, Linux, Windows and Web) using Dart. Flutter has been growing in mindshare quite a bit lately, and Google seems invested in it. Its conceivable that if wed truly be able to start with a clean slate, we could build clients for all platforms (desktop, web, mobile) from a single code base using Flutter. However, here its probably wise to step back in todays reality for a second: is that realistic? Would we be willing to wipe the slate clean and build everything from absolute scratch (at a technical level)? And convince all our engineers to drop their years long investments in front-end skills, and start from scratch again using Flutter and Dart? And similar to Xamarin, would we be able to hire for this, would we be able to attract an open source community around this?

Academically an attractive option, but risky and something that would likely consume years of engineering effort. And who knows, by that time Mattermost may be a metaverse (matterverse) company, or gaming company (again), or a fishing company, in which case all this will have been in vain.

And then at last: React Native. Like Flutter and Xamarin, React Native enables you to build iOS and Android (and at some point desktop apps) using JavaScript/TypeScript and React. TypeScript and React, you say, that stack sounds familiar. Oh wait, thats pretty close to what we use for the frontend! Ive been murmuring a fair amount about skills and fullstack, and this is exactly where the React Native option shines. If you know React (and all of our fullstack engineers do), you can pick up React Native likely in a matter of days. Yes, its a bit of a pain to set up the development environment and to learn some of the specifics, but if we want to stick to the idea of fullstack engineers and not start from scratch (like with the Flutter option), this is actually our most viable option.

And thats pretty much the model we employ at Mattermost right now, and we have the organizational structure to support it:

1. Feature teams consist primarily of fullstack engineers that can (relatively) freely move between web, server, and mobile. They generally dont need deep expertise in all these areas, because the platform teams are here for support. This allows feature team to flexibly deliver features end to end.
2. Platform teams (web, desktop, mobile, QA) consist of more specialized engineers, they do have deep knowledge of their particular areas (or at least are good at pretending). If there are hard technical issues to solve (performance, architecture, scale) these teams can handle or at least support it where necessary.

So there you have it: React Native still seems like the best option we have given our constraints:

1. It leverages the skills we have in the company and can realistically hire for (React).
2. It gives us a shot to deliver features across all our clients with reasonable effort.
3. This comes at the cost of not having a 100% tailored experience, but somethings gotta give.

Does that mean React Native is the answer for your organization as well? Thats for you to figure out, but here a few dimensions to consider:

1. The technology intrinsics: can we use this technology to build what we need to build in a productive way? Is it stable and reliable?
2. The technology context: Is there a community? Will it still be around 10 years from now? Can I Google a random problem and find the answer on stack overflow?
3. Your organizations and market reality: Do we have the skills to use the technology in house, or will we able to gain them quickly, e.g. through training or hiring?

Yeah, thats tricky... So maybe that whats on Hacker News today strategy is not such a bad option after all...