Native vs cross-platform development - should you choose?

If you have the task of developing some kind of mobile application, the choice of platform depends on two factors: “What programming languages do you know?” and “What are your challenges?”

When it comes to a single developer, he can’t make an iOS and Android app in anything other than React Native if he’s only familiar with Java Script. But using the cross-platform RN framework, a person can make a working application for two (or even more) operating systems.

Programming in a native environment requires knowledge of the appropriate languages. For Android, it is Kotlin and/or Java, and for iOS – Swift and/or Objective-C. In principle, it is possible to do with one of the two for each platform, especially since Google is actively developing Kotlin, and Apple is investing a lot of effort in improving Swift.

The situation with Flutter, another popular cross-platform framework, is interesting. To work with it, you need to know the typed programming language Dart. It is already quite popular in the ranks of programmers, especially – enthusiasts, so that the number of those who want to program in Flutter is increasing (among them – the creators of mobile versions of eBay, Aliexpress and even Meduza.io.

Thus, if we are talking about a small team or a proud freelancer in general, the arsenal of development will be limited by the competencies in programming languages that are already available.

Tasks requiring native development

The second aspect is the tasks to be performed by the development team. The advantage of cross-platform development is the speed (one application for two platforms) and cost of the project. But sometimes the customer needs other requirements are important:

Performance. If you want maximum performance from the application, only native development will work for you. Even though Flutter handles animation perfectly, you can only get the most out of the device’s computing subsystem in a native environment, without using intermediate libraries.

Application size. If it is necessary to make an application as compact as possible, for example, if you develop it for specialized devices, or in case of really big size of the application itself, native development will help to reduce it several times.

Support of low-level functions. At times, a developer needs to address smartphone components directly. This can concern a gyroscope, a compass, a fingerprint recognition module or any other hardware. This usually requires native programming. It also applies to encryption features needed for the banking sector.

Latest features. Finally, all platform innovations are reflected in native languages on release day. On frameworks, they appear a little later – if they are very important updates, and much later if they are something minor. Take virtual reality VR, for example – its support in RN and Flutter is only implemented at a basic level, and all the effects you can achieve only in native environments.

The nuances of complex projects

However, if the application is something more complex than displaying web content on a mobile device, you need to keep in mind that cross-platform frameworks are also associated with nativ.

Often you have to edit the code of some components or write your own modules in native languages. So in practice it turns out that native languages are not required in cross-platform development in most cases, but you still need to know them!

Mix – mix but not shake

Sometimes people ask me, “So why develop in RN or Flutter if you have to recruit native developers to the team anyway?” But this is only a superficial opinion, as the same RN has its own advantages when running projects. For example, it is much easier to describe the interface on React Native, and for many projects this is enough.

So, often the logic and low-level stuff is coded in Native, and the interface is created in Flutter or RN. For example, recently we needed to plug Yandex.Metrics into a project on React Native. But the RN didn’t have the current metrics – only the old version was supported, which didn’t work. We had to rework Java for Android and Objective-C for iOS to implement full support for Yandex.Metrics.

When we were developing an application for internet radio, the Android version used a player that did not support metadata in the stream and did not show the artist and the song name. We had to open the source code, write metadata processing and build the full module in Java to connect it to the RN application.