Our team creates lots of mobile apps and some of them have the same functionalities across not only mobile, but also web platforms. Unfortunately, the cost of these multi-platform projects is usually higher than in case of one-platform solutions, as implementing features on each platform needs to be done by different software developers. Let’s say the client needs iOS, Android, and web application. That usually means the project will engage at least three developers. Tons of such ideas come our way, but sadly, clients simply can’t afford three solutions for the same business logic. Is there any other way to approach these requirements and craft multi-platform solutions?
Looking for tailored solution
It was more or less true, but the performance of this solution was way behind the native one. Frameworks like Cordova or PhoneGap are good for apps that are not performance-critical, but even the basic things like ListViews had trouble with smooth rendering. So we put that idea aside and focused on using Native technology (Swift for iOS and Java for Android platform).
Things changed a few months ago when we heard about React Native. Back then we knew React very well and had been using it on a daily basis to create web apps. React Native brought extra hype into front-end devs community, so we decided to spend some time exploring whether it was worth using or not. The word “Native” was intriguing as well. It indicated that this technology was close to Native solutions. We started to research and all the showcases mentioned a few strong reasons to go with React Native. Let me point these out and compare them with our own experience.
Existing production applications
There are tons of apps made with React Native working on production right now. Huge companies trusted it, including Facebook, Airbnb, and Instagram. This was a very big deal for us. When it comes to choosing tools, their popularity is sometimes a critical point. We had to make sure that the community is big enough and lack of solutions for simple problems wouldn’t slow us down. It was reassuring to hear that so many people used it and describe it as a great experience, so we decided to give it a try.
Three platforms and one tool to rule them all
The promise of a single, common codebase for business logic was very tempting. If you have read about React Native before, you know that this advantage is one of the most mentioned. We identified multi-platform features and saved lots of time, as we didn’t need to learn a new language or wait for one platform to catch up with another, while making the next, new feature.
Everybody was happy:
- our client who saved money and saw progress in making the app
- the whole team saw the advantages over the native mobile solution
We began to notice that components we created could be reused across different platforms or even apps, and calibrated for the client’s specific needs. Now we are making an Android app based on iOS and it turns out that transferring most features is a painless process.
As front-end developers, we know how tangled developer’s environment can be and how easy it is to get lost among different tools. Having that in mind, we were a little scared to come closer to React Native’s still unknown environment. We hoped it was similar to what we already knew about its ancestor. Almost every blog post we read mentioned how awesome React Native dev-tools are and this post is no exception. Build-in dev-tools - they are just so wonderful! Features like: inspecting elements, hot reloading, debugging JS code... they get the job done and make the developer’s experience so much better. The documentation of React Native is almost perfectly written and you simply can’t get lost in it.
When it comes to layout and styling, the mobile version of Flexbox is just as amazing as its web cousin. Styling components and having constant feedback on a mobile screen, without having to reload, is a lovely experience. It’s very familiar to what we have known from browser flow and we were very surprised to have it on the mobile.
What about mobile developers?
You may ask: are they even needed in this case?
The short answer is: yes, they are.
The longer one is: When it comes to creating an app, most clients want to optimize features/money ratio. Then it’s a good choice to stick with React Native, but without going into technical details, native Android or iOS solutions will always be ahead of us - React Native developers having front-end background. Creating high-quality software is a complex task and has lots of variables included, but the simplest rule is: if you have money, go with Native solutions and hire a mobile team. If you need to create an app that has cross-platform features and your budget is rather low, choose React Native.
From front-end developers’ perspective, little knowledge about native development made our learning curve steeper. Reading design guidelines for iOS Human Interface and Android Material design may be really helpful here - it bridges that gap. Mobile team’s ability to solve platform-specific problems was sometimes truly invaluable. Touching the native code without having any experience was slowing us down and there were many situations when Native helping hand salvaged us. Not to mention deployment related tasks!
Creating native mobile apps using React Native was a challenging, yet pleasing, experience. We had some worries about this technology, but in the end, it turned out outstanding. The community growing around React Native keeps us - developers - on safe ground. We are assured that we are not alone trying to solve new, appearing problems. What’s more, this technology is still moving forward and getting better every day. With more and more people using it, we are not worried that React Native will vanish and we are sure that our support for client’s app won't suffer.