Back to Articles 
When starting a new mobile app project, one of the first decisions to be made is the choice between using the traditional methods provided by Apple and Google versus a third party or open source cross-platform method such as React Native. This is an important decision as it can have a big impact on the cost of development and the speed at which the product can be brought to market, amongst other things.
Tacchi has been building iOS and Android apps and the web services that support them since 2010—over a decade of experience. In recent years we’ve moved from the traditional approach of creating separate code bases using Swift or Objective-C for iOS and Kotlin or Java for Android to writing a single Javascript codebase using React Native.
Over that time we’ve built up a lot of experience with React Native and how best to work with it in spite of some of its rough edges and idiosyncrasies. We’ve seen its benefits and drawbacks time and time again, and have been able to compare and contrast with that long history of traditional mobile development.
Overall, our experience has been very positive, as has the impact on our clients’ businesses, which is why we’ve been fully committed to React Native as our default approach to mobile application development for our clients for some time.
In this article I’ll share the key reasons for that move so that our potential clients can understand the business reasons for our recommendations, and our friends in the development community can learn from our experiences.
How we decided to start using React Native for client work
It’s our job to stay up to date with the latest technologies available and identify which we should be recommending to our clients. This means we have to spend time studying and prototyping in order to learn whether we should commit to a new technology or not.
By the start of 2017, React on the web had been around for a few years, and the nascent React Native, first released in March 2015, was starting to gain traction. We were skeptical about it being “just another compromised cross-platform toolset” that promised cheap and easy development at the expense of user experience. However, upon testing it out by building a few prototypes, we realised that it had a lot of potential. After a year of keeping a close eye on it and working with it internally, around the start of 2018 we decided it was time to start recommending it to clients for their mobile apps as our go-to solution.
We were very happy with the results of that decision soon after, as were our clients. Here are the main reasons why:
1. Reduced development costs
One of React Native’s main selling points is that a single React Native codebase, written in Javascript, can run on both iOS and Android with very little, if any, platform specific code.
In fact our experience, which is shared by some of the well-known tech companies that use React Native, is that a typical React Native app will have 95% or more of its code shared between iOS and Android.
This equates to one of the holy grails of software engineering: velocity, or “how much can be built in a given timeframe”.
With less code being written for the same feature set, less time and therefore budget needs to be used, or more functionality can be written for the same budget. This is particularly true thanks to the sheer breadth of libraries created by React Native’s amazing open source community. There’s a whole host of UI toolkits, wrappers for native APIs and third party integrations, and so on. This means that often React Native developers don’t just need to write less code, they often need to learn a huge amount less about the way these things work differently on those platforms as it’s all abstracted away and presented as a simple Javascript API.
In fact, in my experience open source support for React Native is so much stronger than that for Android that I’d prefer to write an Android app with React Native than with Kotlin!
Such a large percentage of code being shared between both iOS and Android means that it’s almost a case of “buy one get one free”. This means that when compared with the traditional dual codebase approach, only about half the code needs to be written. I say “about”, as there is a small amount of additional overhead still, such as working around some of React Native’s rough edges, still needing to test on both platforms (in particular Android due to its huge array of device types and manufacturers’ habit of customizing the OS and UI ), and so on.
Even if a product is intended to support iOS only to begin, it often still makes sense to build the product with React Native, as the option to support Android (and even the web with use of React Native for Web) with very little extra work at a later date is very attractive.
2. Faster time to market
A corollary to the aforementioned reduction in development costs is that the decreased time needed to build a product means that a team of the same size will complete the release in a shorter timespan. This means getting the product to users or customers earlier, thus creating important business value earlier.
In addition, as the Javascript code in a React Native app can be updated over the air without needing a traditional app store release (and the approval process that comes with it for iOS), releases can be made much more often, which can be very beneficial for a fast-moving startup.
3. Development team flexibility and a strong ecosystem to source talent from
Hiring and retaining great developers is hard, and can be costly and time consuming. Whether you have an existing development team or are building a team from scratch, at some point—assuming your business goes well—you’ll likely be hiring new developers and growing a sizable team. React Native benefits from a few key points here that should not be overlooked when committing to having a team look after an important mobile product.
Firstly, it primarily uses Javascript, the language of the web browser and many other places, thus one that many developers know intimately. Contrast that with Swift and Kotlin, which, unless they’ve worked with native mobile development already, most developers will have no experience with.
Secondly, writing an application with React Native is basically the same as React for the web, one of the most popular frontend development frameworks around. This means a React developer can be effective at contributing to a React Native project very quickly, if not immediately, as well as being able to bring their knowledge of complementary libraries such as Redux, Apollo, and so on.
The flexibility of such a team is very important. Instead of having three teams: frontend web, iOS, and Android, you could have one team of developers who are building and maintaining all three with just React and React Native (or if you’re really cutting edge, React Native for Web only!). While I would strongly suggest having at least one experienced iOS and Android developer on such a team to act as a technical specialist and UX gatekeeper for their respective platforms, having the majority of your team being able to contribute to web and mobile without retooling or reskilling is hugely valuable.
And one final point on this, in my experience having a typical software engineer get up to speed with React Native is much easier than Swift or Kotlin.
4. No compromise to user experience
The impact a poor user experience can have on a digital product’s business goals is common knowledge. Historically, early cross platform development tools such as PhoneGap, Cordova, Appcelerator’s Titanium, Xamarin, Unity (great for games, not for general applications as I’ve seen a few times), and so on have nearly always had some kind of major compromise. This has typically been regarding challenges in creating a platform-native UX for the supported platforms due to the use of HTML5 for rendering the UI, instead of the native platform frameworks.
It is a somewhat common myth that this problem extends to React Native. I have had a few developers and business owners mention this to me at local meetups too, so I really want to dispel that myth here.
In a nutshell, there’s no technical reason why a platform-native experience cannot be built using React Native. In fact, I’d challenge anyone to try one of the apps we’ve built in the last couple of years and show me any aspects that don’t fit with the host platform or feel “non-native”.
However, that’s not to say that there are no potential UX pitfalls to watch out for. In fact, there are some serious ones, in particular for those entering the world of mobile app development for the first time. For example web designers and developers who don’t have a strong understanding of platform-specific mobile UX practices (they should know Apple’s and Google’s guidelines intimately), or think that they can get away with the same techniques for handling inter-screen navigation that they use on the web. This is easily solved, though, by ensuring that the team that works on a React Native project has respect for the platforms they’re building for and invests time into learning how best to design for them and leverage the tools they provide instead of doing things the easy way. Related to this, I recommend checking out our article on handling navigation in React Native.
Conclusion
As you have hopefully learned, React Native isn’t just a cool new technology. It’s a production-ready toolset that can help reduce development costs, get to market faster, build a more powerful team, all while keeping the ability to craft the quality of user experience necessary for a competitive digital product.
All of these opinions are based on over three years of experience building apps with React Native and a decade of building with traditional methods for clients of all sizes, from large enterprises to solo-founded startups.
We still support some legacy Objective-C and Java codebases for our long-term clients, but since early 2018 all new mobile apps you can see on our portfolio (and many that we can’t show for contractual reasons) have been built with React Native.
That’s not to say that we would refuse to work with Swift and Kotlin, as we would welcome the opportunity to use them again if a client required it. Nor would we shy away from recommending them if it made strategic or technical sense for a particular project. However, thanks to the flexibility we have with including native code in React Native projects if needed, so far we haven’t come across such a situation.
And finally, if you’d like to talk about how we might be able to help your business create an amazing mobile or web app, please get in touch. We’d love to hear from you!