Why We Chose React Native
The story of a startup technology choice
I first met James Eder, the founder of Causr, in November of 2015.
Sipping coffee in a cosy London café, I listened with interest to his ambitious idea of creating a mobile app to help millions of people make meaningful connections with interesting people nearby.
A few months later, in February 2016, we met again. James had managed to get a simple web-based ‘alpha’ version built to demonstrate the concept.
The prototype was limited in lots of ways but, since James is not technical himself, I was impressed by what he’d achieved. I like people who get stuff done.
James was now looking at how best to build the next version of Causr and we agreed that I’d help him.
One question soon came up… which technology would we use for the next version of the app?
Our Starting Point
Here’s where we stood, back then in February 2016:
Cash
James had spent a small amount of money on getting his MVP built and was speaking with some potential angel investors who he hoped would put £100K or so into the idea.
Technology
The alpha version had been built by a small team of quite inexperienced developers who had gone through the Founders And Coders programme. It had been their first commercial project.
The alpha was written as a Node.js app which served both a web front-end and the back-end API that talked to it. It was great as a way to explain the concept of Causr and start testing the UI but we didn’t feel committed to building upon it.
Team
For the time being, the team was James and me:
- James had previously set up and run a successful business and had a clear vision for what the app should do.
- I had been co-founder and CTO of a number of online businesses and would be providing the technology knowhow and experience.
We could also get a little help from the Founders and Coders developers who had built the alpha version of the app.
Product Designs
James had created some detailed mockups of the screens he had in mind for the app and had received a couple of initial quotes from agencies to potentially build the app.
Goals for the App
Ultimately, James wanted the new version of the app to help him test his hypotheses about Causr, get some early traction, and excite stakeholders enough for him to raise a new round of funding and start building a team around him.
We identified a few things we wanted from it:
- iPhone required; Android to follow: Given our initial target user base, we definitely wanted something that could be used on iPhones; 80% of our test users were on iOS so we decided to launch with the iOS version first. Once launched and with the learnings from iOS, the plan was to then build and launch Android.
- Slick UI: We wanted the user interface to be sufficiently polished that it wouldn’t be getting in the way of people using the app. We were prepared to trade extra functionality for UI polish.
- Something to build on: Ideally, we wanted a platform we could iterate and build on over time.
What we Wanted from a Technology Stack
Given our situation and with our rough requirements in mind, I started to look at which technology we should use to build the new version of the app.
I felt we wanted:
- Strong technical underpinnings: We wanted a stack based on sound, up-to-date technical principles.
- Good support (now): The stack needed to be something developers could be productive in immediately.
- Great prospects: We wanted technology that would be extremely well supported for the next 3–5 years, at least. Ideally, it should be one of the leading tech stacks for that period.
- iPhone & Android support: We wanted a good way to support both iPhone and Android.
- Access to phone features: We needed a tech stack that would allow us full access to phone features such as location and notifications which we knew could be important to the Causr concept.
- Potential for UI polish: The stack shouldn’t prevent us building a really slick UI.
- Developer availability: We needed to be able to access great developers with experience in the technology, ideally in the UK.
The Technology Options
I started looking into our options by consulting a wide range of resources — people I knew, publicly-available articles and data, as considering my own direct experience.
Three alternatives seemed worth considering for the front-end of our app:
- Native iOS: A native iOS app written in Swift or Objective-C
- Cross-browser framework: An app built using a cross-platform framework such as Ionic
- React Native: An app written using a new but potentially promising technology from Facebook called React Native
Each of these options had obvious pros and cons but, ultimately, we chose React Native.
Here’s what we looked at and how we came to our decision…
Technical Underpinnings
From the start, I liked React Native’s approach.
Compared to other mobile app development technologies, React Native was the first that really appealed to me.
It had a number of aspects I liked:
- Rapid edit/test turnaround time: Getting fast feedback on whether a piece of code works or not is, in my experience, an incredibly important factor in developer productivity. React Native promised near-instant turnaround: a big advantage over something like the iOS Swift environment.
- One language for iOS and Android: React Native allows developers to write in one language to create both iOS and Android apps. This allows you to have fewer skill sets within your team.
- Common code between iOS and Android: React Native allows much of the code of an app to be shared between both platforms, with platform-specific code at times to deal with things like UI differences. People who had discussed their experiences with React Native were reporting around 80% shared code. Needing less code could be a big win in terms of productivity.
- Based on another strong technology: The React.js JavaScript library had already gained a huge amount of momentum, with other libraries copying some of its principles. This meant lots of developers were becoming familiar with some of the key ideas that would translate well to React Native.
- Possibility of instant app updates: React Native offered the potential to update apps instantly via an update to the app’s JavaScript rather than submitting a new version to Apple’s App Store and go through the submission process for each revision.
- No restriction on access to native features: Out of the box, the React Native framework provided ways to access most common phone features. If necessary, though, the framework also allowed developers to write their own native code modules to access other features.
- Created by smart people: Coming out of Facebook, I had confidence that the framework was well written.
- Fast-growing ecosystem: Although developed by Facebook, it already had support from a number of other large companies, including Samsung and MicroSoft.
Nothing is perfect, of course. React Native also had a number of negatives:
- Dependent on Facebook: React Native was still heavily dependent on support from Facebook. The Facebook team were driving its development and, were they to decide it was no longer the right platform for them, it wasn’t at all clear there’d be enough momentum in the rest of the community to keep React Native going as a leading development platform. This concern was highlighted by Facebook’s unexpected move a month before to shut down its Parse service.
- Immature technology: React Native was still very immature as a technology, so would likely be buggy and would have a poor ecosystem of supporting libraries, online tutorials, StackOverflow answers, etc.
- Very few developers: At that stage there were very few developers who had any kind of experience with React Native, let alone writing production-grade apps.
- Ambiguous license: There was some ambiguity about the wording and implications of React Native’s license, particularly if we were ever in a competitive situation with Facebook or being considered for acquisition by one of Facebook’s competitors. We took the view that this risk was small.
Personal Opinions
To help inform our decision, I gathered opinions from a range of people with experience of mobile app development, including fellow CTOs, experts from mobile app development agencies, and startups and developers already using React Native.
There was a mixture of advice.
CTOs: Broadly speaking, the CTOs encouraged me to be wary of anything too ‘new’ and recommended the tried-and-tested approach of developing separate native iOS and Android apps.
Agencies: Some experts from mobile app development agencies argued for using a cross-platform framework such Ionic, saying that high-quality UI could now be achieved this way and that it would allow for rapid development. Others had experimented with React Native and were excited by its potential.
Startups: The people I spoke with who were using React Native were generally very happy with their choice to use it. They didn’t seem to be finding the immaturity of the technology problematic.
Conclusions: Inconclusive, but reassuring regarding the potential immaturity React Native.
Trends
One of the factors that most affects how useful a technology is to a business, is the strength of the ecosystem around it.
Using a very popular technology means that, whatever you’re doing, people will have done something like it with that technology before. Often there are online tutorials to follow and libraries available that you can use. If you’re using a less-popular technology, that won’t be the case and you’ll need to figure things out and write those libraries yourself. This can quickly get very costly.
Whenever I’m making an important technology choice, I like to review trend data. This data often needs a bit of interpretation, but can be helpful to get a sense of whether interest in a technology is increasing or declining.
One trend that can be interesting to look at is the percentage of StackOverflow questions being asked about a particular topic over time.
Back in February 2016, the trend for React Native was very positive. More and more people were asking questions about the technology:
Growth in interest in (the slightly more established) React.js was also very strong:
Looking at Google Trends data, the picture was similar:
Conclusions: Interest in React Native was clearly growing strongly — a positive signal (though there was no guarantee that this would continue).
Real-World Examples
As another sense-check to see if React Native really was up to the job we had in mind for it, I decided to look at what other people had created with it.
If no-one but Facebook had created a decent app with the technology, then that would have been a big warning sign.
The React Native website handily provided a ‘showcase’ page with links to various apps that had been created in React Native. I downloaded and tested all that I could. Most were terrible. A small number, however, were good and had snappy UIs.
Conclusions: It was possible to create good production-grade apps with slick UI using React Native. (It was also, of course, possible to create bad ones!)
Making Our Decision
As with most interesting decisions, there were tradeoffs to consider.
There were lots of good reasons for choosing React Native. And several risks with doing so.
The reasons for choosing it included the compelling cross-platform story and the rapid edit/test cycle it would allow.
The biggest risk was the immaturity of the technology. People we knew were trying it out and finding it okay, so that reassured us. Nevertheless, we anticipated a few technical bumps along the way as we ran into areas where the framework was still being developed.
We weighed up the pros and cons and made our decision:
We decided to use React Native.
How Has Our Decision Turned Out?
It’s now 9 months since we made the decision to use React Native.
What’s happened since then?
After helping James pick an app development agency to do the actual build, I’ve been playing an advisory role as technical questions have arisen.
As James sees it…
“Using react native has enabled us to build a stable and robust platform to take Causr to market. It’s interesting to see interest in React Native continue to grow and it’s been great to be able to work with SimpleWeb on such a new technology.”
What’s Next?
React Native continues to go from strength to strength, looking like a more and more compelling option for many app development scenarios.
I’m excited about the potential for the technology and looking forward to seeing where it goes.
As for Causr, James is looking for a lead developer and to build out the team. If you’re passionate about your craft and interested in using technology like React Native to help people around the world make valuable connections, then get in touch now and find out more here: https://goo.gl/kKOywb
Causr is a location-based app helping professionals connect on the go. Our vision is to create millions of meaningful connections for people nearby, all around the world, everyday. Download the app to see who’s nearby and start connecting today. Now available on the Apple App Store.
