Developing apps with React Native implies developments with a unique code for both iOs and Android.
Who is behind this technology?
The main driver is Facebook -a fact must also be borne in mind and which could be the subject of a new post regarding related implications- which the sector has, in principle, taken as a being a guarantee. In addition, companies like Instagram, Airbnb, Skype, Tesla or Uber (regarding Uber Eats) are already opting for this framework for their own apps.
To understand the impact that this technology can have on costs when developing an application for Android and iOs platforms, it is important to remember that a native app, with full functionality and quality, required so far programming a separate app for each platform: Objective-C or Swift for iOs and Java for Android – virtually doubling the production costs in the development and testing stages.
But, isn’t that what hybrid apps were doing?
The answer is NO. Hybrid apps (such as those developed with Cordova, Ionic, etc.) were basically running web apps in app browsers. One could say that it was about developing an app-like web and running it in a container called Webview. This technology is very useful for simple and ephemeral applications but it is, however, insufficient for apps that really need to use all the possibilities of mobile devices. This means functionalities such as the camera, asynchronous notifications, gps, nfc, motion sensors, offline running, etc. And the experience has never been as stable and smooth as with a native code-developed app. For this reason, none of the most widely downloaded apps in marketplaces have been developed with hybrid technology.
And how does React Native manage to provide a native experience with a single code?
In easy to understand terms, this technology offers in practice a ‘translation’ functionality, and executes the React Native code in Objective-C for iOs and Android Java. The user experience is therefore identical to the experience with a native application. Indeed, React Native is not a webview: everything run by the user on his device is absolutely native.
Then – should we choose React Native for our projects?
Should we then stop programming in native?
Native code is still currently offering a greater degree of independence, which large projects, for which costs are not a main concern, continue to value. It could also make sense to develop in native, without going through an “intermediate” framework, on projects with clearly different apps for different platforms. In any case, project objectives must always be assessed in order to decide, with an open mindset, which infrastructure and technology best meets the requirements on a case by case basis. In technology, being sectarian is not a positive thing.
Can everything be done with React Native?
Although –logically- one of the main concerns is knowing what can and cannot be done with React-Native, the answer is a resounding yes. The development community for this platform is constantly growing and Facebook’s own developers are constantly deploying new native features to expand possibilities. A further React Native advantage is that, if necessary -a potential functionality or the integration of a third-party service-, it is possible to integrate native code into a project: choosing React Native therefore does not mean giving up native code.
We have been offering this technology to our customers for months already and we have developed a number of projects with it. Legends is the first project developed by Cuatroochenta using this technology, and has already been launched on the market. In terms of design, the experience has not implied any changes, since the task was replacing technology without limiting user experience possibilities.