Skip versus React Native
Case Study: React Native vs Dual Native
https://medium.com/@jpmtech/react-native-vs-dual-native-i-learned-both-so-you-dont-have-to-d6655d4e557e
If you have ever wanted to learn the tradeoffs without having to take the time to learn everything yourself or if you want to see both sides of common arguments, start here. This article takes a short break from my normal tutorial style of article and I share my experience with and opinions on cross platform vs dual native.
The text of cross platform vs dual native with emojis of a crossing symbol and an apple and android emoji
Before we get started, please take a couple of seconds to follow me and đź‘Ź clap for the article so that we can help more people learn about this useful content.
I want all my code to be in one repository
This is one argument that I have heard from the fans of many cross platform. While it is true that React Native does have a single codebase, they do the same thing that dual native developers do when they want both projects in a single repository. They put the iOS files in a folder labeled iOS, and the Android files in a folder labeled Android, and both folders are placed into the main project folder (something like My-App) that gets stored in the repository.
Cross platform vs dual native file structure
I don’t Want to have to learn multiple languages to build an app
This is the premise and desire behind every cross platform solution. The truth is, most cross platform solutions will compile the code down to some sort of native code. In the case of React Native, it compiles the iOS code down to ObjectiveC. This is important to know because if you want to add any kind of native feature to your app without installing a 3rd party dependency, you will have to learn the much older languages that these frameworks compile down to.
On the native side, we have two languages: Swift and Kotlin. At my day job, we already used Kotlin for most of our back end services, so when we started working in the mobile space we really did add only one language.
All our web developers can build a mobile app and we won’t have to hire anyone new
While many web developers probably know React, building a web page is different from building a mobile app (🤯 mind blowing, I know). For example, mobile apps have light and dark mode, dynamic font sizes, built-in screen readers, offline mode, and many more options that web developers just don’t have to consider in their day to day work. If you don’t have people who are experts in the space, you will be missing out on a lot of ways to make your app the best it can be.
Another thing to consider here is the app stores that you will need to deal with. Taking someone from a web context who is used to shipping a change that is instantly applied to every user, is drastically different to the release process for mobile apps. A friend once described the process of releasing apps to the Store and said it reminded him of how the old AOL discs used to be sent in the mail (if you have never heard of this, ask your parents or grandparents about it), the process was that each time you got a new disc, you could update your install for AOL. Similarly, in the app stores you make a change, and send that change out into the world and users can choose to install the update or not. This also brings us to the app stores — web devs building mobile apps will need to learn the ins and outs of the various app store review processes, understand the guidelines for the app stores (so your builds aren’t constantly blocked by Apple and Google), privacy requirements, mobile architectures, and many other details that they have never had to be concerned with in the web reality of releasing the update and moving on to the next thing.
It isn’t as complicated to learn dual native development as you may think either, in fact I write dual native code for my job everyday (along with some web development and back end development). I am proof that you don’t need to hire more people for mobile development, you should look for someone who has a strong passion for mobile development, with a willingness to do what it takes to get the job done. For a side by side comparison of several components built in both SwiftUI and Jetpack Compose check out my article here.
I can use the dev tools and IDE that I’m used to
Most people have their favorite IDE (or text editor in the case of Visual Studio Code) that they love to use. While cross platform tools like React Native allow you to use the same web dev tools that you know and love, you will still need to download both Xcode and Android Studio at a minimum for the simulators, but they will also be helpful when trying to debug platform specific issues (which you will more than likely run into). Which means you will already have the tools to write native code, why not just use them to write native code?
Write the code once, run it everywhere
This is probably the biggest draw for developers and leadership alike to use or push for a cross platform solution. The problem I saw with this is that the developers would prefer one platform over the other, and they would always test their code in the single platform, and would often forget to check the code in the other platform. This led to many different kinds of bugs, some that were hidden for months to us as the developers, but made it into the hands of our users. Cross platform solutions like React Native aren’t perfect and can miss things in various platforms. These issues may be caught with tests in CI/CD, if your CI/CD supports running code in a simulator/emulator, or they could have been caught if we had run our solution on both platforms.
Usually cross platform development with React Native turns into “write once, debug everywhere.”
One of the benefits of dual native development is that it forces you to ensure the solution works on both the iOS and Android platforms every time.
Cost of software
While most people evaluating cross platform solutions just look at the number of developers problem and the upfront costs of creating an app, that is not where the majority of the costs hide. Most of the time, getting a basic proof of concept to run isn’t the hard part (expensive part) of building an app. The most expensive part lies in the long term maintenance, bug fixes, and improvements to the app. As you will see below, Facebook/Meta who created React Native have jumped in and out of their own cross-platform solution due to many issues with it, leaving me to believe that it won’t be around for any kind of long term use.
On the dual native side, Apple allowed developers to start writing code for their apps using ObjectiveC when they released the App Store in 2008, and you can still use ObjectiveC to build apps today (even though there are faster, safer, and better ways of building apps today using Swift and SwiftUI). If you’re looking for long term support, and you want your app around for a long time and be easier to update and maintain, you can’t beat dual native development.
I can rely on a large open source community and third party frameworks
As we mentioned before, Apple still supports the language that they originally launched with over 15 years ago, and Swift is open source too. If you want a large community and long term support, you can’t beat that kind of track record.
Looking at cross platform solutions though, the landscape has lost many options along the way. Years ago, Cordova, Phone Gap, and Ionic were the best ways to build cross platform solutions. Now we have moved on to things like React Native, Kotlin Multi-platform, and Flutter (the last two options are both owned by Google) and the first was created by Facebook (now Meta). The interesting thing about all of these cross platform options is that the creators of all of these platforms have been hesitant in their support of these options in one way or another.
Examples of companies leaving React Native and supporting native
Facebook didn’t Like that messenger was slow, unresponsive, and had a large app size, so they replaced several cross platform components with the native ones — https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/
Airbnb moves away from React Native to native — https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
Intuit leaves React Native for native — https://medium.com/intuit-engineering/bye-react-native-hello-native-61fbe81515d0
Realtor.com swaps from Flutter to native — https://techblog.realtor.com/from-flutter-to-full-native-how-we-optimized-performance-and-user-experience-for-realtor-coms-mobile-app/
Meta used Jetpack Compose for their Threads app — https://android-developers.googleblog.com/2023/10/meta-built-threads-in-only-5-months-using-jetpack-compose.html
Android devs were asked “What are the plans for Jetpack Compose? Are there plans to make it multi-platform like Flutter is today?…” their response “…Jetpack Compose … is the present and future of Android UI…” — https://youtu.be/_gL7XZy_XsY?t=2895
Android devs said “Compose is the future of modern UI development in Android” — https://youtu.be/_gL7XZy_XsY?t=3584
Android devs said “Compose is the future…” — https://youtu.be/pou4o1X1DI4?t=2785
Apple Says “The best way to build an app is with Swift and SwiftUI” — https://developer.apple.com/videos/play/wwdc2022/102/?time=1760
If you want to see other companies that support native development, check out this site: https://mobilenativefoundation.org/
There are other issues that come from relying on 3rd party libraries. Issues like security problems (you should always inspect 3rd party libraries before using them), and being at the mercy of the 3rd party to rely on your code working. Meaning that if they decide your problem with the library isn’t something they want to work on, you will have to fork their library and keep it up to date yourself, or wait for enough people to complain before the issue gets fixed.
Pros of React Native:
If you know React and you don’t mind learning a lot about old mobile code and how the mobile space operates, you can get a decently working app, but you may have trouble with it the longer you maintain the app.
Pros of Dual Native:
- Performance — you will be using the components closer to the metal, and they will be more performant by default
- Debugging and maintenance — maintenance for native apps, is usually as easy as clicking a button that says “update”. For debugging, both platforms have IDEs capable of inserting break points into the code as it runs so that you can easily inspect any value in any area of your code.
- Live Previews — both iOS and Android have live previews that automatically reload and allow you to see the changes in your code instantly.
- Small app size — Not only does this save on energy consumption, but it also allows your app to be accessible to more people all over the world.
Cons of React Native:
- Performance — at the time I was working in React Native we had a JavaScript expert on our team. This expert spent a good portion of his time trying to make the app more performant. Even the creators of React Native had to pull in the native components to make their app more performant as we saw in the article linked above.
- Hot reloading — hot reloading can be very buggy depending on which side of the JavaScript bridge you are working on. You may be trying to fix something on the wrong side for a while before you realize that you just needed to restart the simulator only to find that your code had been working for a while, but you didn’t know it because the bridge was broken.
- No live preview — this means that each time you want to see a change to your UI, you will have to restart the simulator, or hope you are working on the correct side of the JavaScript bridge.
- Large App Size — another side effect of pulling in 3rd party libraries (including React Native) is that your users have a large app to download from the app stores. This may not be a big deal in America or the UK, but in the emerging markets (which make up 85% of the population) this is a big deal for a lot of users.
- Difficult to maintain/debug — with cross platform solutions like React Native, debugging is very difficult. The problem you are trying to find may be in the JavaScript code, it may be on the native side of the code, it may be in a 3rd party library, it may be in one platform and not the other (even though both should be run by the same code), or it could be a connection anywhere between any of those connection points.
This is the largest downside I have seen for cross platform development options.
Development is part science, part art. With native development, you are picking a paint brush up with your fingers, and painting on the canvas. With cross platform solutions, it is like you are picking up a reaching tool and using that to hold the paint brush to paint on the canvas. You can do it that way, but why you would want to put something extra between you and what you are working on?
Cons of Dual Native
If you aren’t already using Kotlin, you may have to learn up to two languages, which will take a little time. Kotlin and Swift are fairly similar, but Jetpack Compose and SwiftUI are nearly identical UI frameworks for each platform.