The main principle underlying in cross-platform solutions - separation of code into 2 parts:
cross-platform, living in a virtual environment and having limited access to the capabilities of the target platform through a dedicated bridge;
native, which initializes the application life-cycle management of key facilities and having full access to the API system.
In order to bridge the gap between the world of “native” and the world “cross platform”, you must use a special bridge. And as we will see in Chapter 3, it's the bridge that defines the capabilities and limitations of cross-platform frameworks.
NOTE: Using bridge always has a negative impact on performance by transforming data between worlds, as well as converting API calls and libraries. By itself, the “cross-platform” world is comparable with native performance
So, all cross-platform applications must have a native part, otherwise the operating system simply will not be able to run them. So let's take a closer look at what API systems and mechanisms are provided by the iOS, Android and Windows.
We'll start our review of the iOS operating system, which is based on Mac OS X, created from the NeXTSTEP OS, a full-fledged Unix-system. Therefore, iOS should be considered as a full-fledged Unix system without the command line. Low level native interfaces in iOS are implemented by analogy with the Unix and C language.
For an native iOS developer, the choice of languages is limited to Objective C and Swift, because native tools and APIs are implemented for them. You can also use the C/C++, but it will be either from the urgent need (there is an existing code base) or from a strong curiosity, because you need high qualification and writing decent code-base. The high level architecture of iOS is shown below.
Additionally, in the diagram, we noted the subsystems that are important for cross-platform frameworks:
WebKit is used in hybrid applications based on PhoneGap or similar to run applications and actually performs the runtime environment of web applications;
OpenGL ES is used in games and applications on Qt/QML or similar to render the interface;
UIKit is responsible for native user interface of the application, which is important for ReactNative and Xamarin.
Android is also a Unix-based system, and mostly based on Linux, with all its pros and cons. However, Android is not totally based on Linux, because on top of the core, OS created its own infrastructure, including a Java Virtual machine (Java Virtual machine, JVM) to run applications. The JVM acts as an intermediary between the user code and a set of API systems available for Java applications. Kotlin language support is built on the infrastructure which is available to Java.
As you can see, there are 2 sets of APIs available for Android developers: Native Development Kit (Android NDK) and Android SDK.
Using the NDK you can get an access to low level APIs of Android. The development is in C/C++.
When using the Android SDK, a developer is inside the Java machine Dalvik (or Android Runtime, ART) and have only the features that Java API provides.
The link between low-level libraries (C/C++) and Java infrastructure is the special JNI Bridge (Java Native Interface), which allows two worlds to interact with each other. JNI acts as a single and universal connection, however, as any bridge, leads to a decline in performance if used inefficiently.
NOTE: JNI reduces application performance when a large flow of commands and data are transmitted through the bridge
Android itself, until recently, used JIT for Java applications, which did not have the best impact on performance. Starting with version 5.0, Android added the mechanism of AOT-compile bytecode (as part of ART) that has improved the behavior of programs, but did not remove restrictions of JNI bridge. Looking ahead, we note that JNI is used in applications with Xamarin and Qt.
Finally, let's look at the Windows UWP architecture, which is the most omnivorous and provides a large number of different interfaces and interaction mechanisms, including Windows Bridges (https://developer.microsoft.com/en-us/windows/bridges)
The system also has a WebView and is suitable for PhoneGap applications. There is no OpenGL ES implementation, only DirectX is available instead.
As “strange” solutions in Windows are also available in a variety of technologies bridging, for example, to run self-hosted sites (https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps) as local apps and classic Win32 desktop programs or iOS apps (https://developer.microsoft.com/en-us/windows/bridges/ios).
It is important for us that Windows UWP provides all the necessary mechanisms for PhoneGap, and Qt ReactNative. If we consider the "Classic Xamarin", it works only in iOS/Android (in Windows C#/.NET and, therefore, are native), however, the Xamarin.Forms functioned perfectly over native Windows UWP API, but we will talk further about it in Section 3.5.