There are more and more platforms between the PC, the web, smartphones, and various connected objects within the application ecosystem. Offering a seamless, unified, and interconnected flow between all these devices is fast becoming the norm. Complexity, team size, and maintenance costs tend to rise when developing apps for multiple platforms. There is also an increased risk of too many variations between them.
To overcome these challenges and reach as many consumers as possible, hybridization technologies that enable the development of all these apps in a single and unified manner are gaining popularity. This is what we’ll be discussing in this latest installment of our series on hybridization.
Various Application Types
The purpose of hybrid applications is to unify the entire application ecosystem. To get a clearer understanding, I think it is vital to take a step back and look at the big picture. What are the various application types? What do they provide and how do they help? How do hybrid and native applications differ?
Native apps are built to leverage the target platform’s tools (language, framework, software development kit (SDK)) and are often designed for a specific platform: Android, iOS, Windows, and Mac mainly. This means that each platform has its own dedicated language and development team. These applications often have to be installed via the respective app stores (Play Store, App Store, Microsoft Store, etc.).
However, there are some huge advantages to native apps:
- Performance: native apps are designed for a single platform, meaning their development is as faithful as possible to that platform. This improves performance in rendering time, processing time, and system error handling.
- Fully exploited potential: they can use the target platform’s potential to its fullest because they have access to all of its features, which is not always the case with other application types. Think phone sensors and push notifications.
- A fully implemented design: each manufacturer and platform has its own design and experience recommendations that can easily be honored if the application only targets one platform and does not need to unify its designs.
As the name suggests, these are applications developed using web technologies to reach other platforms, such as desktop computers or smartphones.
Web applications also have some positives:
- They attract a wider range of developers due to the popularity of their technologies and do not require any installation on users’ devices since they can be run directly from a browser.
- Their goal is to achieve a design that is as close as possible to that of native mobile apps. This will give users the best experience possible while minimizing the cost and hassle of installing native apps.
- Being browser-based, they do not target one single platform and can be deployed anywhere.
However, they are not without drawbacks: unlike native apps, they make it harder to use all the platform’s built-in features. Not all of them are available, they look the same on different platforms, and their performance is not always as good as it could be.
Now, back to hybrid apps. As its name suggests, this type of app takes features from both native and web applications. They are also called “multiplatform applications” because, unlike native applications and like web applications, they can target multiple platforms (mainly Android, iOS, Mac, and Windows) using the same source code. In the early days of hybrid apps, this source code only used web-based technologies. However, as we’ll see later in this post, this is starting to change. But hybrid apps must be installed on each platform, just like native apps.
Hybrid apps can be used as “WebView” containers for websites to deliver them across all platforms where the chosen technology can run. This is not recommended for performance and rendering, though.
Using the same logic, containers like “Electron” can also make web versions compatible with desktop computers. Popular apps like Slack and Figma use this.
Hybrid applications are highly appealing because they appear to combine the benefits of both web apps and native apps. Web apps have lower costs and faster development times because they use a single code and can target multiple platforms simultaneously. Native apps have the advantage of being installed on the device and having access to more advanced features.
So, let’s weigh up the pros and cons, starting with the pros of hybrid apps:
- Reduced development costs: a single codebase can be used for the entire application logic and some of the interfaces. This means that less code needs to be written to deliver the application on multiple platforms than with native apps. Since the technology is also the same, the teams are smaller, and less training is needed.
- Developer pool: following on from the previous point, using a single technology rather than being limited to manufacturers’ technologies allows for a wider pool of developers.
- Reduced maintenance costs: once again, the relatively standard code makes it easier to maintain.
- Scalability: Because the development logic is centralized, if new platforms need to be supported, it should be enough to write the platform-specific code to be integrated rather than a whole application.
- Exploited potential: Since hybrid applications are installed and built as applications for target platforms, it is easier to use platform-specific features, like the camera or GPS sensor, than with web applications. This is still not as efficient as using native applications, though.
There are still some drawbacks:
- The number of platforms to be fully integrated: when we talk about hybrid applications, we usually think of “unified code.” This is partially true and is one of the best things about application hybridization. But it is possible to make full use of the features of each target platform and, depending on the target, get optimum performance from your application. This, however, often requires specific development for each platform. The greater the degree of customization, the more numerous and specific the developments, negating the previously mentioned pros in terms of code maintenance and development cost. Many points unique to each platform also require knowledge of the target platform, which can sometimes turn advantages into disadvantages. Customization by platform is an important thing to think about when deciding to use a hybrid application technology. If you don’t, you could end up with an even more complex application than if you had to manage two.
- Design: Hybrid applications allow for a unified design, so it is the same across all platforms, speeding up deployment. On the other hand, this can make development more complex for the reasons mentioned above. Knowing this is a problem, let’s look at what different technologies can do to fix it.
- The wait compared to manufacturer releases: when Android, iOS, or any other platform releases a new version of its OS/framework/tool, the new features are available immediately for native development because the SDKs come with these updates. In hybrid development, you must wait for the hybrid technologies to catch up with these new features.
- Performance: From a technical point of view, we have seen that a hybrid technology lets you target multiple platforms with the same source code. Performance-wise, the quality depends on whether or not the chosen technology can compile apps in a way that is strictly tailored to native or not. Most hybrid technologies do not support this, and the few exceptions require additional content embedding. As a result, it is extremely difficult to match the performance of the native applications on each platform, in terms of speed and size.
Fresh Ideas for Greater Hybridization
Acutely aware of the problems that come with hybridization and its appeal, the associated technologies and frameworks are full of ideas to lessen the impact of any weaknesses while catering to as many platforms as possible and trying to speed up and facilitate development. Let’s take a closer look at two intriguing technologies.
.NET MAUI Blazor Hybrid
Microsoft has extensive experience developing hybrid applications with its “Xamarin” and “Xamarin Forms” frameworks. .NET MAUI (multi-platform App UI) is the evolution of this integrated within the .NET 6 framework to take full advantage of its performance.
.NET MAUI supports:
- Development across all platforms: iOS, Android, macOS, and Windows
- Development of interfaces for all the platforms with a single descriptive language: XAML
- Component-by-component customization, which is much more effective than Xamarin, to minimize the costs of developing specific interfaces for each OS while maintaining a great deal of flexibility
- Access to an “Essentials” library that integrates most of the access to platform-specific features in a unified way, making overspecialization of the app much less of a problem (Xamarin already has this);
- Getting an app that has been compiled in native bytecode for excellent performance.
Blazor, on the other hand, is a Microsoft open source framework for C# website development using the.NET platform. It is executed either directly on the server or via WebAssembly (WASM) with an interpreted .NET Runtime.
A Blazor WASM website can already be turned into a hybrid desktop application using solutions like “Electron” that support WebAssembly but only for the desktop and with limited performance.
This is changing because .NET MAUI has a “BlazorWebView” component that lets you add Blazor pages to your MAUI applications. This means you can deploy your pages on browser and desktop, and on Android and iOS mobile devices!
In addition, this allows the linked Blazor pages to be executed directly in the MAUI .NET runtime, resulting in a significant performance boost. These pages can interact freely with all common code.
With .NET 7, Microsoft plans to make the connections between these two frameworks even stronger.
So, we have a solution that lets you either build hybrid apps from scratch that work on Android, iOS, MAC, and Windows or have your website turned into a hybrid app without sacrificing performance.
Kotlin and Kotlin Mobile Multiplatform (KMM)
Kotlin is a language developed by Jetbrains. It is intended to replace Java in many scenarios. It is also Google’s preferred language for building native Android apps. Our “Is Kotlin the New Java?” post is an excellent place to start for further information about the language.
Kotlin Mobile Multiplatform (KMM) is a toolkit for developing hybrid applications in Kotlin.
The approach differs from that described above, as the interface development remains native. As shown in this diagram, it has a common core and a set of tools for developing hybrid applications.
By using this collection of tools, developers can work on their chosen platform in a unified way while still fully exploiting the language’s potential.
This approach can also work in both directions. So, you can add Kotlin modules to existing applications on the target platform or add existing applications to Kotlin KMM projects.
This means you can start with a native Android Kotlin project and turn it into a hybrid app for iOS and the Web, for example.
The Pros and Cons of Hybrid Applications
The number of options is growing, there are different ways to do things, and the technologies that allow for hybridization are getting better and can be used on more and more platforms. Despite the growing attractiveness and strength of the offerings, however, hybridization is not yet an automatic choice for application development. As is often the case, weighing the pros and cons before deciding on a particular technology is essential!
For example, whether or not it’s a new project, what technology the organization has in-house, and budget are just some of the factors that come into play. But Cellenza is on hand to help: don’t hesitate to contact our experts!
Interested in learning more about hybridization? Read the other posts in this series now: