A second look into React Native. What do you do when React Native reaches its limitations?
A while ago we wrote this article explaining the pros and cons of building an app using React Native vs. Native Script, and it seems to us that most of you got us, and the internet wrong. Although we do not consider ourselves as a one-point stop and as knowing it all, we believe it’s part of our job to get things clear on this regard.
React Native has managed to build quite a reputation around the fact that it helps businesses and startups cut on development costs. From this perspective, we totally get all the fuss and buzz that's going on. Everyone wants to cut costs — we can't blame them, you can't blame them either.
Developers around the world are looking for ways to make their job easier. On the other side, businesses understand that if they want their product to get anywhere near success they need to pitch their product to both iOS and Android markets. This means designing and developing the same product so as to be functional on different platforms.
Are we taking a drawback from React Native?
Yes, you might be right, we do not believe that Facebook's React Native is the future of all app development and in some instances, we might advise you to go all in for the Native Script. Here is our why:
Native Script Supports all APIs, and this makes our work easier.
To us, this is priceless. Whilst React Native only supports some of the most frequently used APIs, building an app using Native Script gives us access to a full set of APIs. This way we don't have to depend on external factories or third parties, as everything can be accessed through real native framework.
To top this up, we actually don't have to worry about any updates coming up as there is no extra layer mapping the functionality. Simple, huh?
Native Script takes a bit more time to develop and test, but it makes it easier for us to detect errors.
So, the question comes, which side are you on?
To put it in a nutshell, we'll say that the native languages that we use to develop apps that will later on be featured in the App Store and Play Store are, for some "unknown" reasons called strict languages. This makes it easier for us to correct and detect any hidden errors.
Because all these languages including Swift and Kotlin are strict, we even find it easier to transition developers from iOS development to Android development. Which gives us some sort of flexibility when creating technical teams for certain products.
We ❤ being part of big communities
Native Script has been here since the beginning. It's been used, reused and tested so many times by so many developers. It became pretty hard to say that you're facing a problem that hasn't been solved before, and this is helping our developers get through challenges.
Our end thoughts?
Here's the deal. If you already know that you will be needing your MVP to only be available to iOS or Android users than it makes perfect sense to develop your app to only be available in one of the stores. Developing for a single platform is quicker and will involve lower costs.
If you need to deliver on both iOS and Android and cut costs at the same time, consider React Native.
If you're still not sure what to use (it happens to us sometimes) we would be more than happy to talk you through this. We won't have all the right answers, but we'll give you our two cents.
