Native or not? 4 myths about cross-platform development
Smartphones continue to win more and more space under the sun, not only as a tool for consuming photos of cats, but also as a working tool. Therefore, the demand for mobile development is growing. It is considered that Tru and Cool are Objective-C / Swift for iOS and Java / Kotlin for Android. There is no question, tru and cool, but there are a large number of real-world scenarios in which the use of cross-platform frameworks is more preferable in comparison with native tools. More under the cut!
Note: we continue the series of publications of the full versions of articles from the magazine Hacker. Spelling and punctuation of the author saved.
')
I give the word to the author.
Some developers expect from the cross-platform frameworks to solve all their life problems, while others perceive them with hostility. In both "warring camps" there are misconceptions caused by a lack of understanding of how and what works. This adds fuel to the fire, because instead of technical arguments in the course are emotions.
Also among developers, especially beginners, there are many myths about cross-platform mobile frameworks. In our article we will analyze the most popular ones. But first, let's look at mobile development through the eyes of a business that gives money to the whole IT blackjack.
Historically, there has always been competition in the computer market, and each manufacturer provided an optimal set of so-called native (native) tools for developing applications for their operating systems and devices.
Native tools = provided by the owner of the ecosystem.
All other signs of “nativeness” are SECONDARY - the behavior and interface of applications, access to OS capabilities, performance, and so on.
Moreover, it almost always turned out that native tools are incompatible with each other not only at the level of development languages, agreements and architectures adopted, but also at the level of operating systems and libraries. As a result, to implement the same algorithms and interfaces, it was required to write an application for several environments in different programming languages, and then support it on the basis of “one team per platform”. At the same time, the capabilities and appearance of applications on different platforms are almost always 90% identical. Compare for the sake of interest the implementation of your favorite programs for iOS and Android.
The second important point is the availability of the necessary knowledge and experience within the team: if they are not there, then it will take time to learn.
In order to solve both of these problems, cross-platform development tools (not only mobile) have appeared on the market for a long time, offering:
- maximize the common code base in a single programming language to make the product easier to develop and maintain;
- use existing competencies and specialists to implement applications on new platforms.
Since there are a lot of programming languages ​​(and environments) now (and specialists who speak these languages), there are a fair amount of tools for cross-platform development. As an example, we will focus on the popular in our area PhoneGap, Xamarin, React Native and Q t.
Now you can talk about myths.
The most frequent myth disturbing the minds of beginning developers is associated with the belief in supersonic algorithms (and the superprogrammers who created them), which magically transform cross-platform applications into native ones. Something in the spirit of "converting JavaScript code into Swift and further compiling already Swift applications." This myth is also fueled by the developers of cross-platform tools, promising the creation of “native applications”. And it’s not that someone is cunning here, but a rich imagination and lack of understanding of the basic mechanisms sometimes lead the developers to think about shamanistic techniques.
The main principle underlying cross-platform solutions is to divide the code into two parts:
In order to connect the “native” world and the “cross-platform” world, it is necessary to use a special bridge **, it defines the possibilities and limitations of cross-platform frameworks.
When using bridge, performance is always reduced by converting data between “worlds”, as well as converting API calls and libraries.
So, all cross-platform applications must have a native part, otherwise the operating system simply can not run them. So let's take a closer look at what system APIs and mechanisms are provided by iOS, Android and Windows themselves. Moving on to the next myth.
So, we have a cross-platform part of the application that lives in a virtual environment and interacts with the operating system through the framework infrastructure and the bridge.
All operating systems: iOS, Android and Windows UWP - provide access to the following subsystems (sets of system APIs):
Cross-platform applications have a native part and the same full access to system APIs as native applications. The difference is that the call to the system method goes across the bridge and the framework infrastructure:
WebView - the application lives in its web browser by analogy with a one-page website. No access to native controls (buttons, lists, etc.), all based on HTML / CSS / JavaScript. On the other hand, a web developer will feel like a fish in water.
JavaScript engines have become popular relatively recently, since in iOS, a similar mechanism was added only in version 7.0. Of the features it is worth considering the need for serialization in JSON of complex data structures that are transferred between the JavaScript and Native environments. If we briefly describe a similar class of solutions, then the JavaScript environment executes the JS code that controls the native application.
OpenGL ES and DirectX are low-level subsystems and are used to draw the user interface in games and, for example, Qt / QML. That is, when using OpenGL / DirectX, developers themselves draw controls and animations that can only be similar to native ones. On the other hand, it is a low-level subsystem with very high performance, so it is used in cross-platform game engines.
All cross-platform applications have a native part, and therefore potentially the same full access to the system APIs as the “native” ones. Also, cross-platform applications are assembled and packaged with “native” tools in “native” installation packages. The key question is how the interaction between the cross-platform part and the native part is organized. For example, inside WebView or using Open GL ES / DirectX there is no possibility to create a user interface with fully native look'n'feel, but at the same time there is full access to GPS, Push notifications and other functionality. And the JavaScript or C # code is quite free to control the native application and its behavior, providing a fully native look'n'feel.
If to summarize, then yes, it is “non-native” from the point of view of the development tools used (not from Apple, Google). But an application can be completely native in terms of accessing system APIs and provide a fully native look and feel. And we are moving to the next myth.
It should be understood here that native APIs are not considered crutches by default (although there are different opinions here as well), therefore all indignation is directed to the cross-platform part. Obviously, the execution environment (for example, WebView, JavaScript-engine or Mono) is also difficult to call a crutch - adult mature solutions with a long history.
It seems that the crutch is called the way the cross-platform part integrates with the native. To better understand how various frameworks work, we will use PhoneGap, Xamarin, Qt and React Native as examples of the operating system mechanisms used to link cross-platform and native parts.
We start with PhoneGap. Below is the top-level architecture of the application based on this framework.
The application on PhoneGap is in fact a native application that displays WebView as the only UI control. It is through him that the interaction with the native part takes place. All standard WebView in iOS, Android and Windows UWP support the ability to add their own native handlers for JS properties and methods. At the same time, the JS code lives in its isolated environment and does not know anything about the native part — it simply jerks the necessary JS methods or changes the necessary JS properties. Everything is inside the standard Web DOM, to which new elements are simply added that are associated with the native implementation.
Next, consider React Native.
When creating applications on React Native, the developer will almost always need to implement the native part in Objective-C, Java or C #, and the management of the native application will come from JavaScript. In fact, the JavaScript engine is a WebView element that is available separately. The interaction goes through the same JS-bridge, as is the case with PhoneGap. However, in React Native, the JS code controls not the Web DOM tree, but the native application.
It is necessary to take into account that due to the limitations of iOS (there is no possibility to implement JIT), JavaScript code is interpreted on the fly and not compiled. In general, this does not really affect performance in real applications, but it’s worth remembering.
Now consider the classic Xamarin.iOS and Xamarin.Android, since Xamarin.Forms (supporting Windows UWP) is an add-on to them.
Xamarin uses the Mono library to interact with the target operating system, which allows you to invoke native code using the [P / Invoke] mechanism (https://en.wikipedia.org/wiki/Platform_Invocation_Services). It is also used to communicate with native APIs in iOS / Android. That is, C # wrappers are created for all public native API methods, which, in turn, call system APIs. Thus, from the Xamarin application, you can access all system APIs.
And finally, consider Qt, since there are a lot of questions about it from experienced developers.
Qt is a “thing in itself,” there are both advantages and limitations. Qt libraries simply connect to the C ++ system APIs that exist on all operating systems. For drawing the user interface, low-level mechanisms are used, but its own graphics engine that supports stylized “under a native”. At the same time, on Android, you have to access the Java API via a special bridge (JNI bridge), and for Windows UWP you use the Open GL ES to DirectX call converter, since Open GL is not available for UWP.
To summarize: all cross-platform frameworks use the standard native features of operating systems, are mature, are created by experienced teams and the open source community with the support of the giants of the IT industry. Finally, the time has come for the strongest argument.
An important trump card that people like to use in disputes about cross-platform frameworks is poor performance. Again, it depends on what to compare and in which parrots to count.
Recall that the feature of cross-platform applications lies in the parallel existence of two worlds connected by a bridge:
Thus, when comparing performance, you need to consider the speed of work:
If you type in the search engine, for example, react native vs swift performance, then you can see a lot of different tests, and many of them point out that performance drops dramatically with the active use of the bridge, including the active manipulation of the UI from the cross-platform code. For Xamarin, the situation looks the same - the cross-platform part is very fast and comparable to the native one in data processing, however, when using a bridge, performance may drop. Qt generally works at the C ++ level, which is fast on its own. If, however, we consider solutions based on PhoneGap, then the performance here will strongly depend on WebView, but still you should not actively change the UI in JavaScript code or conduct scientific calculations.
Slow? Yes, there may be a drop in performance due to inept interaction with the operating system through the bridge. However, the cross-platform worlds themselves are as fast as the native ones.
Today we reviewed the device of popular cross-platform mobile frameworks and dismantled the main myths with which they are surrounded.
Stay in touch and write questions in the comments!
Vyacheslav Chernikov - head of development at Binwell . In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone.
Articles Vyacheslav you can also read the blog on Medium .
We remind you that this is the full version of an article from Hacker magazine .
Note: we continue the series of publications of the full versions of articles from the magazine Hacker. Spelling and punctuation of the author saved.
')
I give the word to the author.
Some developers expect from the cross-platform frameworks to solve all their life problems, while others perceive them with hostility. In both "warring camps" there are misconceptions caused by a lack of understanding of how and what works. This adds fuel to the fire, because instead of technical arguments in the course are emotions.
Also among developers, especially beginners, there are many myths about cross-platform mobile frameworks. In our article we will analyze the most popular ones. But first, let's look at mobile development through the eyes of a business that gives money to the whole IT blackjack.
Why do we need cross-platform tools?
Historically, there has always been competition in the computer market, and each manufacturer provided an optimal set of so-called native (native) tools for developing applications for their operating systems and devices.
Native tools = provided by the owner of the ecosystem.
All other signs of “nativeness” are SECONDARY - the behavior and interface of applications, access to OS capabilities, performance, and so on.
Moreover, it almost always turned out that native tools are incompatible with each other not only at the level of development languages, agreements and architectures adopted, but also at the level of operating systems and libraries. As a result, to implement the same algorithms and interfaces, it was required to write an application for several environments in different programming languages, and then support it on the basis of “one team per platform”. At the same time, the capabilities and appearance of applications on different platforms are almost always 90% identical. Compare for the sake of interest the implementation of your favorite programs for iOS and Android.
The second important point is the availability of the necessary knowledge and experience within the team: if they are not there, then it will take time to learn.
In order to solve both of these problems, cross-platform development tools (not only mobile) have appeared on the market for a long time, offering:
- maximize the common code base in a single programming language to make the product easier to develop and maintain;
- use existing competencies and specialists to implement applications on new platforms.
Since there are a lot of programming languages ​​(and environments) now (and specialists who speak these languages), there are a fair amount of tools for cross-platform development. As an example, we will focus on the popular in our area PhoneGap, Xamarin, React Native and Q t.
Now you can talk about myths.
Myth 1. Magic
The most frequent myth disturbing the minds of beginning developers is associated with the belief in supersonic algorithms (and the superprogrammers who created them), which magically transform cross-platform applications into native ones. Something in the spirit of "converting JavaScript code into Swift and further compiling already Swift applications." This myth is also fueled by the developers of cross-platform tools, promising the creation of “native applications”. And it’s not that someone is cunning here, but a rich imagination and lack of understanding of the basic mechanisms sometimes lead the developers to think about shamanistic techniques.
The main principle underlying cross-platform solutions is to divide the code into two parts:
- cross-platform , living in a virtual environment and having limited access to the capabilities of the target platform through a special bridge;
- native , which provides application initialization, management of the life cycle of key objects and has full access to system APIs.
In order to connect the “native” world and the “cross-platform” world, it is necessary to use a special bridge **, it defines the possibilities and limitations of cross-platform frameworks.
When using bridge, performance is always reduced by converting data between “worlds”, as well as converting API calls and libraries.
So, all cross-platform applications must have a native part, otherwise the operating system simply can not run them. So let's take a closer look at what system APIs and mechanisms are provided by iOS, Android and Windows themselves. Moving on to the next myth.
Myth 2. Native!
So, we have a cross-platform part of the application that lives in a virtual environment and interacts with the operating system through the framework infrastructure and the bridge.
All operating systems: iOS, Android and Windows UWP - provide access to the following subsystems (sets of system APIs):
- WebView (the web browser built into the application) is used in PhoneGap-based hybrid applications and is actually the local web site execution environment;
- JavaScript engines are used in React Native and its counterparts to quickly execute JS code and exchange data between Native and JS;
- OpenGL ES (or DirectX) is used in game engines and Qt / QML or equivalent applications for drawing the interface;
- The UI subsystem is responsible for the native user interface of the application, which is important for React Native and Xamarin.
Cross-platform applications have a native part and the same full access to system APIs as native applications. The difference is that the call to the system method goes across the bridge and the framework infrastructure:
WebView - the application lives in its web browser by analogy with a one-page website. No access to native controls (buttons, lists, etc.), all based on HTML / CSS / JavaScript. On the other hand, a web developer will feel like a fish in water.
JavaScript engines have become popular relatively recently, since in iOS, a similar mechanism was added only in version 7.0. Of the features it is worth considering the need for serialization in JSON of complex data structures that are transferred between the JavaScript and Native environments. If we briefly describe a similar class of solutions, then the JavaScript environment executes the JS code that controls the native application.
OpenGL ES and DirectX are low-level subsystems and are used to draw the user interface in games and, for example, Qt / QML. That is, when using OpenGL / DirectX, developers themselves draw controls and animations that can only be similar to native ones. On the other hand, it is a low-level subsystem with very high performance, so it is used in cross-platform game engines.
All cross-platform applications have a native part, and therefore potentially the same full access to the system APIs as the “native” ones. Also, cross-platform applications are assembled and packaged with “native” tools in “native” installation packages. The key question is how the interaction between the cross-platform part and the native part is organized. For example, inside WebView or using Open GL ES / DirectX there is no possibility to create a user interface with fully native look'n'feel, but at the same time there is full access to GPS, Push notifications and other functionality. And the JavaScript or C # code is quite free to control the native application and its behavior, providing a fully native look'n'feel.
If to summarize, then yes, it is “non-native” from the point of view of the development tools used (not from Apple, Google). But an application can be completely native in terms of accessing system APIs and provide a fully native look and feel. And we are moving to the next myth.
Myth 3. Crutch on a crutch
It should be understood here that native APIs are not considered crutches by default (although there are different opinions here as well), therefore all indignation is directed to the cross-platform part. Obviously, the execution environment (for example, WebView, JavaScript-engine or Mono) is also difficult to call a crutch - adult mature solutions with a long history.
It seems that the crutch is called the way the cross-platform part integrates with the native. To better understand how various frameworks work, we will use PhoneGap, Xamarin, Qt and React Native as examples of the operating system mechanisms used to link cross-platform and native parts.
We start with PhoneGap. Below is the top-level architecture of the application based on this framework.
The application on PhoneGap is in fact a native application that displays WebView as the only UI control. It is through him that the interaction with the native part takes place. All standard WebView in iOS, Android and Windows UWP support the ability to add their own native handlers for JS properties and methods. At the same time, the JS code lives in its isolated environment and does not know anything about the native part — it simply jerks the necessary JS methods or changes the necessary JS properties. Everything is inside the standard Web DOM, to which new elements are simply added that are associated with the native implementation.
Next, consider React Native.
When creating applications on React Native, the developer will almost always need to implement the native part in Objective-C, Java or C #, and the management of the native application will come from JavaScript. In fact, the JavaScript engine is a WebView element that is available separately. The interaction goes through the same JS-bridge, as is the case with PhoneGap. However, in React Native, the JS code controls not the Web DOM tree, but the native application.
It is necessary to take into account that due to the limitations of iOS (there is no possibility to implement JIT), JavaScript code is interpreted on the fly and not compiled. In general, this does not really affect performance in real applications, but it’s worth remembering.
Now consider the classic Xamarin.iOS and Xamarin.Android, since Xamarin.Forms (supporting Windows UWP) is an add-on to them.
Xamarin uses the Mono library to interact with the target operating system, which allows you to invoke native code using the [P / Invoke] mechanism (https://en.wikipedia.org/wiki/Platform_Invocation_Services). It is also used to communicate with native APIs in iOS / Android. That is, C # wrappers are created for all public native API methods, which, in turn, call system APIs. Thus, from the Xamarin application, you can access all system APIs.
And finally, consider Qt, since there are a lot of questions about it from experienced developers.
Qt is a “thing in itself,” there are both advantages and limitations. Qt libraries simply connect to the C ++ system APIs that exist on all operating systems. For drawing the user interface, low-level mechanisms are used, but its own graphics engine that supports stylized “under a native”. At the same time, on Android, you have to access the Java API via a special bridge (JNI bridge), and for Windows UWP you use the Open GL ES to DirectX call converter, since Open GL is not available for UWP.
To summarize: all cross-platform frameworks use the standard native features of operating systems, are mature, are created by experienced teams and the open source community with the support of the giants of the IT industry. Finally, the time has come for the strongest argument.
Myth 4. Slow
An important trump card that people like to use in disputes about cross-platform frameworks is poor performance. Again, it depends on what to compare and in which parrots to count.
Recall that the feature of cross-platform applications lies in the parallel existence of two worlds connected by a bridge:
- PhoneGap: HTML / JS and Native Java / Objective-C / C #;
- React Native: JS and Native Java / Objective-C / C #;
- Xamarin: Mono and Native Java / Objective-C;
- Qt: C ++ and Native Java / Objective-C.
Thus, when comparing performance, you need to consider the speed of work:
- cross-platform part;
- native part;
- the bridge.
If you type in the search engine, for example, react native vs swift performance, then you can see a lot of different tests, and many of them point out that performance drops dramatically with the active use of the bridge, including the active manipulation of the UI from the cross-platform code. For Xamarin, the situation looks the same - the cross-platform part is very fast and comparable to the native one in data processing, however, when using a bridge, performance may drop. Qt generally works at the C ++ level, which is fast on its own. If, however, we consider solutions based on PhoneGap, then the performance here will strongly depend on WebView, but still you should not actively change the UI in JavaScript code or conduct scientific calculations.
Slow? Yes, there may be a drop in performance due to inept interaction with the operating system through the bridge. However, the cross-platform worlds themselves are as fast as the native ones.
Conclusion
Today we reviewed the device of popular cross-platform mobile frameworks and dismantled the main myths with which they are surrounded.
Stay in touch and write questions in the comments!
about the author
Vyacheslav Chernikov - head of development at Binwell . In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone.
Articles Vyacheslav you can also read the blog on Medium .
We remind you that this is the full version of an article from Hacker magazine .
Source: https://habr.com/ru/post/350262/
All Articles