Lecture 34 min.
Cross-platform software is software that runs on more than one hardware platform and/or operating system. A typical example is software designed to run on both Linux and Windows.
Most modern high-level programming languages can be called cross-platform. For example, C, C++ and Free Pascal are cross-platform at the compilation level, that is, compilers exist for these languages for various platforms. Provided the code is of proper quality, this makes it possible not to rewrite the program's core engine; only the special system-dependent parts change.
Standardized runtime libraries are no less important for cross-platform development. In particular, the C standard library has become a standard (see POSIX). Major cross-platform libraries include Qt, GTK+, FLTK, STL, Boost, OpenGL, SDL, OpenAL and OpenCL.
Back in the early days of the PC, IBM made its personal computer compatible with CP/M. This made it possible to run existing programs on it.
PHP, ActionScript, Perl, Python, Tcl and Ruby are cross-platform interpreted languages; their interpreters exist for many platforms.
The Java Virtual Machine and .NET runtime environments are also cross-platform, but their input is not source code but intermediate code. Therefore, programs written in Java and C# can be run under different operating systems without prior recompilation.
On different operating systems, regardless of how cross-platform operation is technically achieved, standard interface elements have different sizes. Therefore, simple fixed positioning of interface elements is not possible, since under another OS they may overlap each other. There are several approaches.
In any case, at least minimal testing is required under other operating systems, since layout errors are possible.
There are several types of applications that developers use.
In effect, a mobile web app is a website opened on a gadget (a smartphone or tablet) using a mobile browser.
Advantages of mobile web apps:
Disadvantages of mobile web apps:
A native app is an application developed specifically for one platform (Android, iOS, BlackBerry).
Advantages of native apps:
Disadvantages of native apps:
A hybrid app is a combination of a native app and a mobile web app. It can be defined as displaying the content of a mobile site in an app format.
Advantages of hybrid apps:
Disadvantages of hybrid apps:
These apps are called native because they are written in the programming language that is native to a particular platform. For Android this language is Java, whereas for iOS it is Objective-C or Swift.
Native apps reside on the device itself and can be accessed by tapping an icon. They are installed through an app store (Google Play on Android, the App Store on iOS, etc.).
They are developed specifically for a particular platform and can use all the capabilities of the device: the camera, GPS sensor, accelerometer, compass, contact list and everything else. They can also recognize standard gestures preinstalled by the operating system, or entirely new gestures used in a specific app.
Because native apps are optimized for a specific OS, they blend seamlessly into any smartphone, offering high speed and performance.
Native apps can access the device's notification system, and, depending on the purpose of the native app, it may work entirely or partially without an Internet connection.
| Pros of native apps: | Cons of native apps: |
|
|
Examples of native apps:
The first example is the Shazam app, which identifies a song playing on another device and looks up information about it:
The second example is the Instagram app:
In fact, mobile web apps are not applications as such. A web app is essentially a website that has been adapted and optimized for any smartphone. To use it, it is enough to have a browser on the device, know the app's address and have an Internet connection (which is how the information in this type of app is updated).
When launching mobile web apps, the user performs all the same actions as when visiting any website, and also gets the option to "install" them on the home screen by bookmarking the website page.
Web apps are cross-platform, that is, they can function regardless of the device's platform. Their trump card is also that they do not use the device's software. And because they are a mobile version of a site with enhanced interactivity, web apps do not take up precious space in the smartphone's memory.
Web apps became widely popular when HTML5 began to develop and people realized that they could access many of the features of native apps simply by visiting a website through an ordinary browser. Today it is hard to say where exactly the clear boundary between web apps and ordinary web pages lies, since HTML5 functionality grows every day and more and more sites use it.
Web apps are developed using tools and frameworks that have become traditional. As a result, their development process has accelerated significantly in recent years. Moreover, there is no shortage of specialists in developing them.
At the same time, web apps can be criticized for being unusable without the Internet. This also leads to another drawback: their performance, which is average compared with other types of apps. Moreover, it depends on the capabilities of the service provider's Internet connection.
| Pros of mobile web apps: | Cons of mobile web apps: |
|
|
Examples of mobile web apps:
Hybrid apps are a combination of web and native apps. This refers in particular to their cross-platform nature and access to smartphone functionality. Such apps can be downloaded only from marketplaces such as Google Play and the App Store. At the same time, they have the option of updating information offline, while an Internet connection is required for them to work. Without it, the web features simply do not work.
Among many companies, the choice most often falls on developing a hybrid app. This is understandable, because hybrid apps can combine the advantages of native apps with the technological relevance provided by the latest web technologies. However, unlike native apps, the cost of creating hybrid ones is an order of magnitude lower, and development speed is higher. The kinship of hybrid apps with web apps, in turn, bears fruit in that changes can be made to them easily and quickly. That is, developers do not have to resubmit the app to the store to fix bugs in the previous version, as is the case with native apps.
Developing a hybrid app also looks promising because it involves creating it for two platforms at once. As a result, this spares you the headache of developing a separate app for each OS. Is this a decisive factor? Certainly.
Among other things, it should be noted that the quality and capabilities of hybrid apps depend, first of all, on the framework the developer uses. It is also worth paying due attention to the factors that make hybrid apps the preferred option compared with the others.
So, it is worth developing one if:
| Pros of hybrid apps: | Cons of hybrid apps: |
|
|
Examples of hybrid apps:
The first example is the HeartCamera app for iOS, which lets you decorate a photo with hand-drawn hearts and the like.
The second example is the TripCase app, an organizer for planning trips.
Historically, the computer market has always been competitive, and each vendor provided an optimal set of so-called "native" tools for developing applications for its own operating systems and devices. "Native" development tools provide maximum performance and full access to the capabilities of the operating system.
However, it often turned out that these tools were incompatible with each other not only at the level of the development language, accepted conventions and architectures, but also at the level of the mechanisms for working with the operating system and libraries. As a result, to implement the same algorithms and user or business scenarios, it was necessary to write an application for several environments in different programming languages. For example, if you need to support 2 platforms, the labor costs and the team size have to double. On top of that, the budgets for support and development double as well. It can be added that many companies have already accumulated a large code base that they would also like to carry over into new solutions.
The second important point is having the necessary competencies (knowledge and experience) within the team; if they are lacking, time will be needed for training.
To solve both of these problems, cross-platform development tools appeared on the market, offering to:
maximize the shared code base in a single programming language, so that the product is easier to develop and maintain;
use existing competencies and specialists to implement applications on new platforms.
Since there are now a great many programming languages (and environments), and specialists who know these languages, there is also a fair number of cross-platform development tools. In this book we are interested only in tools for creating mobile business applications, so in the following chapters we will look in more detail at how they work. For now, let us look at each of the advantages of cross-platform development in a bit more detail:
Shared code base. Depending on the chosen tool, the developer will be able to share between platforms: application resources (images, fonts and other files), data-handling logic, business logic and the interface description. While resources and logic (data processing and business logic) are fairly straightforward, you need to be more careful with the interface, since each platform has its own guidelines and requirements.
Reusing existing competencies and the existing team. Here it is worth considering not only the programming language, but also an understanding of how the iOS/Android/Windows operating systems work, as well as the set of additional libraries and development tools.
So, "native" tools are provided by the ecosystem owners themselves and let you get the most out of the capabilities of the target operating system, have full access to native APIs, offer optimal performance, and require a separate development team for each platform.
Cross-platform frameworks reduce labor costs and speed up app releases when support for several platforms is required at the same time, and the necessary competencies are available (or being developed). In the long run, cross-platform solutions will save a considerable number of person-hours, but for that you should take into account the specifics of the chosen tool.
The main principle underlying cross-platform solutions is splitting the code into 2 parts:
a cross-platform part, which lives in a virtual environment and has limited access to the capabilities of the target platform through a special bridge;
a native part, which handles application initialization and the lifecycle management of key objects, and has full access to system APIs.
To connect the "native" world and the "cross-platform" world, a special bridge must be used. And as we will see in Chapter 3, it is the bridge that determines the capabilities and limitations of cross-platform frameworks.
IMPORTANT: Using a bridge always has a negative effect on performance because of the data conversion between the "worlds" and the conversion of API and library calls. The "cross-platform" world itself has performance comparable to the "native" one.
So, all cross-platform applications must have a native part, otherwise the operating system simply will not be able to launch them. Therefore, let us look in more detail at which system APIs and mechanisms are provided by iOS, Android and Windows themselves.
We will begin our overview of operating systems with iOS, which in turn is based on Mac OS X, which was built from NeXTSTEP OS, a full-fledged Unix system. Therefore, iOS should be regarded as a full-fledged Unix system without a command line.
Low-level native interfaces in iOS are implemented in the same way as in Unix (for C). For an iOS developer, the choice of languages is limited to Objective-C and Swift, because the native tools and APIs are implemented for them. C/C++ can also be used, but this is done either out of dire need (there is existing code) or out of strong curiosity, since it requires high qualifications and writing a sizable base of auxiliary code. The overall iOS architecture is shown below.
In addition, in the diagram we have marked the subsystems that matter for cross-platform frameworks:
WebKit is used in hybrid apps based on PhoneGap or similar tools to run applications, and effectively acts as the runtime environment for web apps;
JavaScript Core is used in React Native and similar frameworks for fast execution of JS code and data exchange between native code and JS;
OpenGL ES is used in games and in apps built on Qt/QML or similar tools to render the interface;
UIKit is responsible for the app's native user interface, which is relevant for React Native and Xamarin.
As we can see, out of the box iOS provides ready-made interfaces for Objective-C (Swift works as a layer on top), plus there are mechanisms for cross-platform HTML/JS applications (WebKit, JavaScriptCore). Any frameworks that support Unix calls can work with the iOS API at the system-call level, but for full interaction with the Objective-C API from other languages, special wrappers will have to be written.
IMPORTANT: Just-In-Time compilation is not available in iOS, except for JavaScript compilation with WebKit. This is because iOS blocks access to writable executable memory, which prevents executable code from being generated dynamically.
Because of iOS restrictions, all applications that require JIT (other than JavaScript) must be compiled to machine code (Ahead-Of-Time compilation, AOT), which may come as a surprise to Java and .NET developers. This restriction is dictated by heightened security and performance requirements.
Android is also a Unix system and is largely based on Linux, with all the resulting pros and cons. However, Linux does not stick out much in Android, since its own infrastructure has been built on top of the OS kernel, including the Java Virtual Machine (JVM) for running applications. The JVM acts as an intermediary between user code and the set of system APIs available to Java applications. Kotlin language support is a layer on top of the infrastructure available to Java.
As we can see, Android gives the developer two subsystems at once: the Native Development Kit (Android NDK) and the Android SDK.
With the NDK, you can access low-level Android mechanisms. Development is done in C/C++.
When using the Android SDK, the developer ends up inside the Dalvik Java machine (or Android Runtime, ART) and has only the capabilities that the Java API provides.
The link between the low-level libraries (in C/C++) and the Java infrastructure is a special JNI bridge (Java Native Interface), which allows the two worlds to interact with each other. JNI serves as a single, universal link, but like any bridge it leads to a drop in performance if it is used inefficiently.
IMPORTANT: JNI reduces application performance when a large stream of commands and data is passed across the bridge
Besides the JNI bridge, in the Android architecture it is also worth noting the subsystems WebKit (for PhoneGap), OpenGL ES (for Qt and games) and View System (roughly, the equivalent of iOS UIKit, for React Native and Xamarin), similar to the modules in iOS. However, compared with iOS there are fewer restrictions: JIT can be used not only for JavaScript but also for other languages, and there is no rigid dependence on a particular JS engine.
Until recently, Android itself used JIT for Java applications, which did not have the best effect on performance. Starting with version 5.0, Android added an AOT compilation mechanism for bytecode (as part of ART), which improved program behavior but did not remove the limitations of the JNI bridge. Looking ahead, we note that JNI will be used in Xamarin and Qt applications.
Finally, let us look at the architecture of Windows UWP, which is the most all-embracing and provides a large number of different interfaces and interaction mechanisms, including Windows Bridges (https://developer.microsoft.com/en-us/windows/bridges)
Besides the traditional APIs for C++/C#, Windows UWP also provides mechanisms for working with JavaScript based on the Chakra engine, which is used in Edge. Microsoft supports an open-source version of React Native on Windows UWP: https://github.com/Microsoft/react-native-windows
The system also has a WebView and is suitable for PhoneGap-style applications. There is no OpenGL ES implementation; only DirectX is available instead. Qt works, but with significant limitations.
As "exotic" options, Windows also offers various bridging technologies, for example for running self-hosted websites (https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps) as local applications, as well as classic desktop Win32 programs or even iOS applications (https://developer.microsoft.com/en-us/windows/bridges/ios).
What matters for us is that Windows UWP provides all the mechanisms necessary for PhoneGap, ReactNative and Qt to work. As for "Classic Xamarin", it works only on iOS/Android (on Windows, C#/.NET is already native), whereas the Xamarin.Forms library works great on top of the native Windows UWP APIs, but we will talk about it in Chapter 3.5.
So, we have examined the architectures of iOS, Android and Windows UWP. As you may have noticed, all operating systems have some technical means of running cross-platform applications. The simplest option from a technical standpoint is to use a WebView, which every OS has (relevant for PhoneGap). The second option is to use low-level mechanisms such as OpenGL ES and the C/C++ language - this allows most of the logic to be shared between projects (in games or Qt), but it will work only to a limited extent (or not at all) on Windows UWP. If you need a fully native user interface and native performance with minimal overhead, then high-level system APIs come into play - this approach is implemented only in Xamarin and ReactNative.
To better understand the capabilities and limitations of each framework, let us look at how they are architecturally designed and what capabilities and limitations follow from that.
PhoneGap-based solutions use a WebView and are fairly simple to implement - a small native application is created that essentially just displays an embedded web browser and a single-page HTML document. There are no native controls and no direct access to the API - all interface elements inside the web page are simply styled to look like native ones. To access system functionality, special plugins are attached that add JS methods inside the web browser and link them to the native implementation on each platform.
As we can see, PhoneGap allows you to share almost all code between platforms, but the native part still has to be implemented in Objective-C and Java (and C# for Windows). The whole life of the application takes place inside the WebView, so web developers will feel right at home. That is, until a need for platform-specific functionality arises - then a good understanding of iOS and Android will be required.
PhoneGap (also known as Apache Cordova) is also used in the popular Ionic framework, which provides a large number of ready-made plugins for system functionality.
IMPORTANT: The interface of WebView-based applications is not native; it is only made to look like one using HTML/CSS styles
Developing applications with PhoneGap requires experience with HTML, JavaScript, CSS, as well as Objective-C, Java and solid engineering knowledge to integrate the native and cross-platform parts. The user interface is organized on the single-page HTML principle - in real applications with a complex interface there will be jerkiness and lag (a characteristic of mobile WebViews, which can also differ between manufacturers). To pass data across the bridge, it must be serialized/deserialized to JSON. In general, the bridge is rarely used, since the whole life of the application takes place inside the WebView.
IMPORTANT: To pass complex data structures and classes between the native part and the WebView, they must be serialized/deserialized in JSON format
Finally, note that PhoneGap is already a fairly mature solution with a large number of ready-made plugins.
************
So, PhoneGap can be recommended for rapid development of simple applications (up to 15 screens) with a small user base (for example, an in-house solution) or for prototypes.
One of the interesting solutions in the field of cross-platform mobile application development is ReactNative, created at Facebook. This framework makes it possible to use JavaScript to describe the native interface and the application logic. The JS engine itself provides performance comparable to native. However, do not forget that the ReactNative architecture also contains a bridge, which reduces the speed of working with platform functionality and the UI.
As we can see, the project consists of a native part in Objective-C, Java or C#, which initializes the JS code and interacts with the operating system. The JS application then takes control and, using ReactNative, starts creating native objects and managing them from JavaScript. It should be added that the ReactNative architecture allows the JS code to be updated without restarting the application (hot reloading). This makes it possible to update the cross-platform part without having to republish applications to the App Store and Google Play. You can also use libraries from npm and a large number of third-party plugins.
Keep in mind that, because of iOS restrictions (JIT cannot be implemented), JavaScript code is interpreted on the fly rather than compiled. In general this does not significantly affect performance in real applications, but it is worth remembering.
IMPORTANT: To pass complex data structures and classes between the native part and the JS engine, they must be serialized/deserialized in JSON format
Building applications with ReactNative requires JavaScript experience as well as good knowledge of iOS and Android. Integrating the native and cross-platform parts is easy to do following the official documentation. The user interface is fully native, but has limitations and quirks when styled from JS code, which you will have to get used to. To pass data across the bridge, it must be serialized/deserialized to JSON. In addition, the bridge is used to manage native objects, which can also lead to a drop in performance if used inefficiently (for example, frequently changing the properties of native UI objects from JS code during manual animations).
You should also take into account the youth of the framework - there are bottlenecks or bugs that you only discover during development. And almost always the native part has to be implemented in Objective-C and Java.
************
So, ReactNative can be recommended for rapid development of applications of medium complexity (up to 40 screens); the team should include not only experienced JS developers but also good specialists in iOS (ObjC/Swift) and Android (Java/Kotlin).
Qt is one of the oldest cross-platform frameworks and is very widely used for developing embedded and desktop applications. The Qt architecture allows it to be ported to operating systems that have a C++ API. iOS, Android (NDK) and Windows all offer this capability, although each with its own peculiarities.
One of the main advantages of Qt is its own efficient user interface rendering system, based either on a raster engine (for example, CoreGraphics on iOS) or on OpenGL (ES). This is exactly what makes the framework portable. That is, Qt uses its own UI rendering mechanisms - the application will look native only to the extent that you style it to.
As we can see, on iOS the standard CoreGraphics and UIKit modules are used to render the user interface. On Android the situation is a bit more complicated, since Qt uses NDK mechanisms to render the UI, while the JNI bridge, already familiar to us, is used to access the Java API and manage the application. OpenGL ES can also be used on iOS and Android to render QML or for 3D work.
On Windows there is direct access to the C++ API and everything would work great, if not for the need to convert OpenGL ES calls into DirectX calls (raster rendering does not deliver sufficient performance, and OpenGL ES is not available in Windows UWP). The ANGLE library helps with this.
IMPORTANT: The interface of Qt-based applications is not native; it is only made to look like one through styling
In general, Qt could be recommended as a self-contained thing - just the framework's own ready-made modules plus platform-independent C++ libraries. But in real projects it will be very hard to use - a non-native UI, no third-party components (only the "out of the box" libraries), difficulties when building and debugging the application, and when accessing native functionality. On the plus side is the high performance of C++ code.
************
So, Qt can be recommended for developing applications for iOS, Android and Windows UWP only if you already have extensive experience with Qt and an understanding of complex system mechanisms. Keep in mind that the interface can in any case only look similar to the native one.
Xamarin is now available as open source and emerged as an evolution of the Mono project (http://www.mono-project.com), an open implementation of the .NET infrastructure for Unix systems. Originally Mono was supported by Novell and made it possible to run .NET applications on Linux and other open operating systems.
To interact with the operating systems' native (C) interfaces, Mono uses the P/Invoke mechanism (http://www.mono-project.com/docs/advanced/pinvoke/). The MonoTouch and MonoDroid frameworks were built on top of Mono, and were later renamed Xamarin.iOS and Xamarin.Android; together they are now called "Classic Xamarin".
Classic Xamarin provides full access to native APIs, meaning you can create native iOS/Android applications in C# without a single line of Objective-C or Java. Native libraries are connected through a binding mechanism (Native Library Binding). Interaction with the OS goes through a bridge and a wrapper mechanism, but there is no need to serialize data, because marshaling is automatic and references can be passed directly between the Mono managed and native environments. You can also use a large number of .NET libraries from NuGet.
The .NET/Mono infrastructure assumes the use of JIT, similar to Java, where the application is compiled into intermediate bytecode and only then interpreted at run time. But because of iOS restrictions JIT cannot be used, so the bytecode of Xamarin.iOS applications is compiled into a native binary and statically linked together with the libraries. This kind of compilation is called AOT (Ahead Of Time) and is mandatory in Xamarin.iOS. In Xamarin.Android, besides AOT, a JIT mode is also available, in which the Mono virtual environment runs in parallel with Dalvik/ART and interprets code at run time.
As we can see, the shared code base between platforms is limited to business logic and data-handling mechanisms. Unfortunately, the UI and platform functionality have to be implemented separately for each platform. As a result, no more than 30%-40% of the overall code base of a mobile application can be shared. To achieve more, you need to use Xamarin.Forms, which we will cover in Chapter 3.5.
The key advantage of Classic Xamarin is the use of the C# language for all the code and, as a consequence, developers who are already well acquainted with .NET. A good knowledge and understanding of iOS/Android mechanisms, their class models, architectures and object lifecycles, and the ability to read examples in Objective-C and Java, are also required.
IMPORTANT: The performance of C# code is comparable to that of native code on iOS/Android, but interaction with the OS goes through a bridge, which can slow the application down if used inefficiently
A Xamarin.iOS/Xamarin.Android application usually consists of a shared part, which is packaged into a .NET library, and a platform-specific part, which has full access to the APIs, including the native user interface. The platform-specific part contains the screen definitions, resources, styles and fonts - practically 100% the structure of a native Objective-C or Java project, only in C#. It is also possible to embed C# code into native projects using Embeddinator-4000 (https://mono.github.io/Embeddinator-4000).
Classic Xamarin is a mature solution and provides a development experience as close to native as possible for C# programmers, using familiar tools such as Visual Studio.
************
So, if the task is to build a fully native application and you have experienced C# developers, Xamarin can be a good choice for a wide range of tasks, both large (more than 40 screens) and small (up to 10).
If your goal is to maximize the shared code base, Classic Xamarin clearly loses to all the other frameworks (PhoneGap, ReactNative, Qt and their analogues). The Xamarin team understood this as well, so they released a solution that allows a single UI description and simple mechanisms for accessing platform features - Xamarin.Forms.
The Xamarin.Forms library works on top of the previously described Classic Xamarin and essentially provides user interface virtualization mechanisms and additional infrastructure.
Xamarin.Forms (XF) solves a kind of "last mile" problem, providing a single API for working with the user interface across different operating systems (iOS, Android, Windows UWP/WPF, Linux Gtk#, Mac OS X, Tizen). The interface itself remains fully native.
To better understand how XF works, let us look at a simple button. One of the basic mechanisms is renderers: when a Xamarin.Forms button is displayed, a native control is actually added to the screen, and the properties of the XF button are dynamically propagated to the properties of the native button on each platform. ReactNative uses similar mechanisms.
The shared part in Xamarin.Forms is usually implemented as a library (Portable/PCL or .NET Standard) and has access to the component ecosystem on NuGet. The platform-specific part is implemented on top of Xamarin Classic and has full access to the APIs, as well as the ability to attach third-party libraries. The overall share of code between platforms usually reaches 85%. Xamarin.Forms can also be used in Embedded mode to create individual screens and Views inside applications built with Classic Xamarin.iOS and Xamarin.Android.
If the components and plugins already available in Xamarin.Forms are enough for you, deep knowledge of iOS/Android/Windows will not be required. However, for more complex scenarios (custom controls, a pixel-perfect implementation of a design), good knowledge of the OS and its mechanisms is still required, plus an understanding of Xamarin.Forms.
Although Classic Xamarin is a mature and stable solution, Xamarin.Forms is still a fairly young layer that is actively evolving on top of it, so problems and bottlenecks may appear that you should watch out for.
************
So, Xamarin.Forms can be recommended for rapid prototyping in C#, but Xamarin.Forms can also be used for enterprise and business applications of any scale (100 or more screens). The look, performance and behavior of the applications will be fully native, but do not forget about efficient interaction with the operating system through the bridge.
Comments