React Native has been trending in the tech news for a few years now. Since Facebook officially introduced it as an open source project, many corporations have leveraged it in development. It’s not surprising, as React Native holds a promise of building apps for multiple platforms at the same time. Even if only 40% of your codebase is shared between different operating systems, it still is a big save of time and, in consequence, money. But how does it stack up against Swift in practice?
Netguru builds digital products that let people do things differently. Share your challenge with our team and we'll work with you to deliver a revolutionary digital product. Create a product with Netguru.
Both complex and small projects can take advantage of React Native, so we decided to directly compare the RN framework with Swift to see what the actual benefits are. We initially developed a live translation app natively for iOS only. This simple app connects you to an interpreter. After the app had been successfully released commercially, the client started to consider further development for other platforms with the capability to quickly launch the app on new operating systems. The client’s goal was to gain a large market share. Therefore, we recommended that they give React Native a try, because it would enable us to develop the app for different platforms simultaneously and share parts of the codebase.
The development process was similar on both React Native and iOS. There were slight differences in terms of the sequence of consecutive tasks. However, they did not stem from the inherent specifications of the environments.
The biggest advantage React Native gained over native development in Swift was the time scope. It took approximately 1.5 months to build the same application with Facebook’s framework. The process could have been shorter, but as it was our first released RN application, the process also involved research on the technology. On the other hand, the project scope was smaller than in the case of Swift, because the team had already discussed all the details with the product owner. That said, if we excluded these two variables the project would have taken the same amount of time. As the analysed application was quite simple, it was compiled from one platform to another within just a few hours.
Coding in Swift was completed in two months, which is 33% slower than with RN. It might seem to be a tiny difference considering the project’s scope. However, when you think about developing an app for Android and iOS at the same time, the difference will be much larger. Obviously, it will still take approximately 2 months, but you will need two separate teams that will work concurrently on each platform (up to twice as many engineers).
When it comes to the design layout arrangement, it was more convenient in React Native. The framework offers hot reloading, which keeps the app running and facilitates injecting new versions of the files that you edited at runtime. This way, you don’t lose any of your states, especially when tweaking the UI.
On the other hand, React Native still lacks some components necessary for development. It is an open-source project, rapidly growing thanks to its active community and Facebook’s support. Many functionalities are still not available and using a library that was made specifically for the development on the specific platform might be required. RN offers the Native Modules tool as a response to these issues. In many cases, you will find a ready npm package waiting for you to solve your problems, but in other cases, you will have to build the required module yourself or hack some existing libraries to reach the expected result.
In the case of our app, we had problems with making shadows work, as the custom library was only available in beta version on React Native. Therefore we had to come up with our own solution to make it look the same as it was in the native application.
In the last step, we ran performance tests to verify which framework was more efficient. We compared three variables: allocated memory, CPU usage and energy impact during different actions in the application: the first run, taking a call, and opening an URL from the app. We also compared the speed in opening and scrolling the language list to call (in frames per second).
There were no differences when it comes to the CPU usage and energy impact. We noticed that the application written in RN allocated more memory than the one written in Swift. Statistics show that RN apps require about 20 MB of memory to run RCTBridge and its other components. The application logic is kept in the memory as well. Despite the slight difference in the allocated memory, both applications ran smoothly and had a similar graphic performance. Both apps behaved in the same way on all tested tasks.
As proved in our case study, there are no major differences in React Native and native development, whether it comes to the performance or development process. RN has its advantages over Swift and vice versa. RN offers one advantage that is hard to argue against: it does significantly decrease the development time when you want to scale for multiple platforms, and as a result, saves you a lot of money. Many argue, though, that you still need to use native components and you can’t share more than 30% of the code in the case of more complex apps with platform specific UIs. But still, even if it is only 30%, it is a big saving. If you want to develop your next app for both iOS and Android, and potentially other platforms in the future, consider React Native – it can help you save time and money.
Technical experts: Michał Mokijewski, Piotr Torczyński. Editing: Natalia Chrzanowska. Writing: Natalia Chrzanowska.