When I’m 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, let’s talk technology strategy.
“But Zef,” you may say “this is is what the Hacker News front page is for, no?” Sure, that’s one strategy, but — controversial statement alert — there’s potentially more to consider than just the hot tech du jour.
How should we approach making technology choices? What do we consider?
Let’s use Mattermost’s 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 we’ve 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, it’s business critical to people’s 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, I’ll 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 engineer’s 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 kid’s 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 isn’t 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 there’s still the Mattermost Classic “app” on the AppStore that’s effectively a thin wrapper around the web app. Please don’t use it, it’s not very good. Why is it not very good? Partially it’s because we didn’t invest that much into it, but also because it’s 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 hasn’t happened. And sadly, it’s not in most mobile operating system vendor’s 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 you’ll 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 there’s two challenges with building native apps for two platforms:
First, it’s two platforms that don’t 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 it’s 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. Ain’t 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 you’ve done frontend and backend before, but with a slightly different stack, we’ll assume you’ll pick up ours quickly enough. Great. However, now we’re 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 you’ll 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 won’t get into now).
Let’s be clear, though. Given unlimited time and resources, building separate native experiences for iOS and Android is the best solution. But you’ll be shocked to learn — we ain’t 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:
- Meta’s React Native
- Google’s Flutter
- Microsoft’s 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 we’re standing it doesn’t 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, there’s 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. It’s conceivable that if we’d 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 it’s probably wise to step back in today’s 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, that’s pretty close to what we use for the frontend! I’ve 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, it’s 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 that’s pretty much the model we employ at Mattermost right now, and we have the organizational structure to support it:
- Feature teams consist primarily of fullstack engineers that can (relatively) freely move between web, server, and mobile. They generally don’t 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.
- 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:
- It leverages the skills we have in the company and can realistically hire for (React).
- It gives us a shot to deliver features across all our clients with reasonable effort.
- This comes at the cost of not having a 100% tailored experience, but something’s gotta give.
Does that mean React Native is the answer for your organization as well? That’s for you to figure out, but here a few dimensions to consider:
- The technology intrinsics: can we use this technology to build what we need to build in a productive way? Is it stable and reliable?
- 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?
- Your organization’s 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, that’s tricky... So maybe that “what’s on Hacker News today” strategy is not such a bad option after all... 🤔
Top comments (0)