Wherever you go, you hear “startup this, startup that” and you start to feel that startups pop up like mushrooms? Or maybe you yourself are the proud owner of the brand new shiny business? Well, startups come and go. To be more specific, 90% of them fail. Sorry, but it’s the brutal truth. People tend to have these brilliant ideas and those ideas tend to be the only thing they have while starting a business. Think – competition, think – raising funds.
Important questions should be asked when planning to start a business. We live in a technological world, so a lot of startups decide to build a platform or mobile app. For the latest there is a very popular decision to make these days – what framework should I choose to develop my mobile app with?
What if your product would evolve according to your users’ feedback? Or would you rather risk using technologies with less functional development capabilities? We have some suggestions for you.
React Native & Real Native – so close and yet so far
A Native App, as its name indicates itself, means that the app is developed directly for a specific platform. If you want to reach both iOS and Android users – you have to develop two apps separately. In the case of Android, you would, therefore, use Android Studio, along with Java and Kotlin languages. On the other hand, for iOS, the Integrated Development Environment is Xcode, with an option of both Objective-C and Swift languages.
Seems like it’s a perfect tool for mobile apps development. However, it should be remembered that iOS and Android user experience is different in a fundamental way. Hence the app should leave its users with a natural feeling.
What about the features not supported by React Native library? Well, there is an option to write a Native Module using the corresponding language and link it to the React Native codebase.
React native as the coolest kid on the block
What is the React Native phenomenon? What makes it more and more popular among big companies? How is it different from other mobile app development frameworks?
Do you remember how different iOS and Android were a couple of years ago? It was almost impossible to connect those two worlds. React Native has made the dream of having one cross-platform framework came true. As the first framework for iOS and Android, it made it possible to reach similar efficiency, speed and look. The apps can feel very alike. Examples? There are a lot of React Native build apps that you already know or use, such as Instagram or Airbnb.
What else makes Real Native so popular right now? As you only develop one app for both iOS and Android it would take less time and a smaller team. Regression test would take twice less time and the same applies to fixing bugs.
Great, isn’t it? But here the question arises – is this mobile framework suitable for all kinds of projects? Well, of course, not. There are a lot of considerations that need to be taken before making a final decision – React Native or Real Native? Those are for instance your current coding proficiency, the scope of your app, and the duration of your project.
Final battle – React native vs. real native
The clue of this article is to show you the differences between developing a mobile app in React Native and Real Native. Without further ado, let’s check the pros and cons of both frameworks.
As you can see above, both Real Native and React Native come with a lot of pros, however in the case of cons we think that React Native has a little bit more of them.
Real Native stands out when it comes to access to all APIs and functionalities without any extra layers mapping. There is also a vast choice of third-party libraries. Bigger community helps in improving the development of the app and the app itself. As some functionalities can be developed only in native frameworks, developers need to know them either way. Native frameworks exist longer so they had more time to gain the interest of users, what makes it safer in terms of updating. Strict languages allow for easier bug detection and if you know one of them it would be easier for you to learn another one.
With all of those benefits there is one big drawback – if you want to have your mobile app available on iOS and Android, it means you have to develop two separate applications. That means more time and money, bigger team and twice more time needed for updates.
In contrast to Real Native frameworks, with React Native there is a problem in accessing some of the APIs. Features that are not supported can be developed through native modules, however, it requires from developers the knowledge of native languages. The result is code duplication and also discontent of the developers who wanted to avoid native languages. React has also less third-party libraries, worse access to other native apps and often trouble in matching design guidelines for both iOS and Android. And what if Facebook decides one day to stop making updates to React?
Of course, I didn’t manage to present all of the pros and cons, but I’m sure that is enough to show you the difference between those two frameworks and answer at least some of your questions.
Breaking news – Airbnb breaks up with React Native
A couple of weeks ago Airbnb published a lengthy blog post to share their experience with React Native. They also explained their decision to stop using it in favour of a Swift / Obj-C / Java / Kotlin.
Since 2016, any conversation on “Should we use React Native?” usually ended up with pointing out that Airbnb, a world-class company has made a big investment in React Native mobile app development. Back then, they knew exactly that mobile is the future, but as they admitted, the number of their mobile developers was to low. They perceived React as a good opportunity and they took it.
After two years of using React Native, a top-tier company, with the proven care of their product’s higher quality took a close look at their investment and chose the other way. This decision certainly has a big impact on those who are considering to chose React Native as a framework for their mobile apps development.
That may seem even worse when you think that Airbnb had been a big contributor to the React Native Open Source. Both react-native-maps and Lottie are very important libraries (included in the Expo SDK), originally developed by Airbnb. Leland Richardson was one of the most prominent figures in the community before moving to Google. Contributors like him would certainly be missed.
Don’t get me wrong, the post describes React Native as a pretty good framework, just not suitable for Airbnb anymore. What went wrong? Among others, they blame React’s immaturity, the lack of type safety, error-prone refactoring, couple of inconsistencies, problems with functionalities that didn’t exist yet. And that is just a start of the long list.
You may probably ask in which cases you should use react or real native? But can React Native be successfully used for building any kind of app? Choosing a framework at the beginning of a mobile project is very important because not everyone has the budget like Airbnb and a few other big companies to build applications in one technology and then try to switch to another, often also as part of an experiment.
Our opinion on this dramatic choice
As React Native is not officially supported by either Apple or Google, there’s a question if new iOS and Android announcements would work with React Native and if the answer is yes, what would be the quality of it. For now, we believe that using Real Native framework would be a safer choice. This is because it’s hard to imagine iOS and Android supporting framework that is not created by them – as you know React Native is Facebook’s technology. In contrary, native frameworks target specific platforms, so they can take a complete advantage of mobile device’s capabilities. In our opinion – Real Native has its renaissance after a React Native boom.
Rate this post:
To be React Native or Real Native – that is the question for a mobile startup
5 (100%) 2 vote[s]
Jacek Knaflewski CEO of ITgenerator, deeply passionate about helping companies transform their businesses through modern technologies.