Few can resist the desire to work less and get more. This desire, fulfilled in a positive way, leads to progress. One of the attempts to achieve this was cross-platform mobile application development.
With the growing popularity of smartphones, tablets, e-books and netbooks, mobile platforms are becoming more and more relevant – from responsive website layout to full-fledged application.
Let’s see what variants of this technology will be popular in 2021, and which one will win the Flutter VS Xamarin VS React Native battle?
A framework with a long history. Initially developed separately, later it was acquired by Microsoft. Since it is “not in JS”, it is not very popular. Unlike JS frameworks, C # code compiles, and this allows it to run a little faster. It also has two architecture options.
Here, the UI layer is developed separately for both platforms, and the business logic is common. This option will be interesting if you want to make the most native application in terms of UI (taking into account all the guidelines), and save on duplicating business logic by reusing existing developments.
At the same time, it requires a team of developers who can write the UI part for both platforms separately. Continued development of Xamarin with UI coverage does not require writing separately.
Creative kits are available to suit all tastes. There is a free Visual Studio Community Edition and a paid subscription version of Visual Studio Professional for $ 45 per month.
Debager, hot-reload (only for layout), layout editor – everything is available. However, the development language and the relative cost of the web-production tools make Xamarin less common outside of the Microsoft ecosystem.
The first release took place in 2015. It is almost the only cross-platform JS framework that does not give us a choice and only offers React as a development framework. Its appearance confirms that React can be fed to any engine for rendering a virtual tree house.
The first implementation of this approach was the result of a hackathon and eventually continued its development in Open Source. At the moment it is very popular, not least thanks to “React” for the Web.
The general architecture is very similar to NativeScript, only the bridge is 100 meters higher up the river. Native plugins are written on the platform side, and only parameters are passed through the bridge. Between JS and the platform, there is Yoga, a cross-platform engine that implements the flex-box layout on the target platform.
Technically, React Native is very similar to what front-end developers are used to seeing on the Web.
The framework is actively developing: releases appear every 3-6 months. In version 0.61.0, the hot reload mechanism has been updated, which allows you to work more efficiently. Not too long ago, version 0.62.0 was released which added fbflipper integration out of the box.
Hopefully, this initiative will get a worthy continuation, as so far the developer’s arsenal of tools has been like a patchwork quilt. Initially, only the browser console is offered, you can also use react-native-debugger or reactotron, which provide additional tools for creating (Redux inspection, MobX, Apollo Cache).
Of the features: sometimes there are differences when displaying in iOS and Android. All is well in most cases, but it is worth testing features on both platforms before completing design.
The widgets provided by the platform are sometimes quite different. In the case of switches, the mechanics and general principle of operation are the same, in the case of a picker, the differences are dramatic. If you need this kind of mechanics, you have to resort to the services of modules.
The last ones to consider are native-like frameworks. What sets them apart is that they don’t use built-in widgets at all. Instead, they paint everything on their own. One of the newcomers to this category is Flutter. In the process of preparing this article, I was surprised to find that since 2011 a similar framework has been developing in Python that implements the same concept – Kivy.
Alas, this framework lacks funding and community. For example, the implementation of Material UI has not been developing for 3 years, and the initiative was intercepted by our compatriot.
The first release took place at the end of 2018. The platform is quite young, but it is actively developing: quarterly releases, active development of the Dart language, rich developer tools, amazing hot reload, online editor for animation, specialized CI / CD – all this was available from the first day of version 1.0 release.
The key specificity of this type of architecture is the ability to independently render pixels, control gestures and animations. Flutter uses two functional widget sets, Material for Android and Cupertino for iOS, which allows it to skillfully render UI components on both platforms.
Thanks to this architecture, support for “anything” is declared, in theory. In practice, iOS and Android are well supported. The Web is actively developing. In fact, success in the web field will determine the further popularity of the framework around the world.
At the moment there is Web support in beta, and it gets better every day. Performance is one of the concerns. With the flag FLUTTER_WEB_USE_SKIA = true production the efficiency increases significantly.
The agony of choice
The choice of a specific solution will be dictated, rather, not by the pros and cons of the framework, but by the overall picture and goals of the project.
A cross-platform can be called a compromise between creating separate development teams and getting a quality result. The technology is also suitable for start-up projects.
In both cases, you will choose based on what is in the asset, and not for the sake of the prospect of obtaining a spherically ideal product.
An asset means an existing product (code that can be reused), the competencies of employees, the popularity of the framework (hiring new employees, developing the framework and plugins).