When developing mobile applications, one of the first choices developers face is the front-end technology that has to be used for the project implementation. Historically, there has been a distinction created in 2 classes of technology stacks: Native, to develop apps in iOS or Android; and Hybrid, to support both iOS and Android. The main factors taken into consideration when making a decision were performance in terms of speed and code reuse, how many platforms can support writing the least amount of code. Back in the day, developers had to support at least three platforms because Microsoft and BlackBerry had a role in the smartphone market with their operating systems. Since the support for both Windows Mobile and BlackBerry OS ended, it’s sufficient to release an app on iOS and Android to be able to reach the widest audience possible.
Before 2015, the term hybrid referred to mobile apps that were written in HTML, JavaScript, and CSS, then wrapped in a native shell, which in turn allowed them to be packaged for release in the App Store or Play Store. The downside of this approach was performed, as the web code was running in an embedded web view offered by the native shell. With the release of React Native in 2015 that uses JavaScript as a programming language that binds to native UI widgets, and with Microsoft acquiring and open-sourcing Xamarin in 2016, that compiles to the platform runtime, cross-platform tools have undergone a dramatic acceleration that closed the gap to native in performance aspects.
Today there are many more conceptual aspects for managers, designers, developers, and architects to take into account when making decisions on the mobile front-end technology stacks, going beyond the dimensions of code reuse and performance.
Let’s compare code in Native vs. Cross-Platform and execution in Native vs. Hybrid.
● Native (coded) applications are built with programming languages and tools rolled out by the company that develops the platform and the OS they run on. For example, native iOS apps would be written mainly in Objective-C and Swift, whereas native Android apps would be written in Java or Kotlin.
● Cross-platform (coded) applications are built-in programming languages and tools that are not included in the development tools offered by the company that develops the platform and the OS that they run on. This is a broad list, including stacks and frameworks like Flutter, React Native, Xamarin, and more.
Let’s now look at the difference between native and hybrid execution.
● Native (executed) apps are built in native or cross-platform programming languages and are then either compiled to assembly code ahead-of-time (AOT) or just-in-time (JIT), which still leverage native UI widgets. Apps that are written in React Native, and Flutter belong to this class.
● Hybrid (executed) apps are built in cross-platform web-based programming languages (HTML, CSS, and JavaScript/ECMAScript or their supersets such as SCSS and Typescript) and are executed within a native shell, usually a WebView or equivalent. Apps written in Cordova and Ionic come under this class.
Choosing a full-native technology stack is the no-compromise solution for a mobile development framework. If we are adopting a cross-platform technology stack for developing mobile apps, we may have other considerations driving the decision such as development time and code reuse that may be required to make some tradeoffs. These tradeoffs also include upgrading paths and timing of tooling and language support for mobile OS updates.
The main perceived tradeoff between native and non-native mobile apps is performed, with hybrid mobile apps performing more poorly than native mobile apps. Mobile app UI has to remain active, even during heavy data processing to provide a smooth user experience. Because mobile processors are multithreaded, it’s not needed for mobile app UI logic to run on the same thread where the data processing takes place. Native mobile development frameworks have this capability built in and offer APIs to schedule operations on different threads. Web apps and hybrid apps that are coded on web technologies should run their content on an embedded web browser and perform processing in parallel, such as the parsing of a large API response within the browser may cause the UI to be blocked. Most of the recent cross-platform mobile development frameworks address the performance limitations in numerous ways and some of them are specified as native apps when speaking in terms of runtime.
● Flutter compiles 32-bit and 64-bit ARM code for both iOS and Android.
● React Native has the JavaScriptCore engine to execute the Javascript code along with native widget for the UI, so that Javascript code does not block the UI operations.
● Xamarin compiles code using ahead-of-time to ARM assembly language for iOS and the MonoVM virtual machine for Android, which sits at the same level of the JVM on the Kernel that makes the process more efficient.
With the cross-platform mobile development framework, it will benefit from being able to develop apps for multiple platforms with the same skills. The price that you pay for staffing or resources is that you are building a team of “generalists” by means of considering the mobile development technology as a single case. Generalist designers will risk not knowing the capabilities of each target platform and will build UIs that are independent of native scale. Generalist developers may not be aware of certain target platform-specific APIs and will try to make it once fit for everywhere basis. It has to ensure that the team has strong design and architecture guidance when staffing resources for cross-platform mobile apps.
Moreover, it’s a wrong thought that cross-platform mobile development frameworks are easier to use than native ones. For a sophisticated app, it has to use certain device-native features by using plugins or bridges that can solely be written in native code by a person with a high level of expertise.
Release span is always critical in new mobile projects, and companies are always looking for ways to reduce the time to develop mobile apps as much as possible. It is possible to build apps on iOS and Android side-by-side (dual-native) and release them at the same time, But this approach might require either more development time or extra team size.
For applications that do not make extensive use of frameworks, it is probably realistic to consider 90% code reuse for the Xamarin, React Native, and Ionic frameworks. Some tools like, Ionic allow for the same code to be reused not just across mobile platforms, but also with web apps as well by building Progressive Web Apps.The possible risk of trying to maximize code reuse is that you risk losing the capabilities or strengths of each platform as you build for the average without taking advantage of platform-specific frameworks.
The mobile platform landscape is continuously evolving, and the lifetime of a mobile app should be considered in the development stage itself. The longer you want your app to remain available on the market without major rewrite or device level changes, the more you will want to choose a stack that offers clear upgrade paths. Picking a technology stack that offers a very small support community will put you at risk of having to rewrite the app in the future, which may cause additional effort. For a native mobile development stack such as Objective-C to Swift or Java to Kotlin, the vendor will provide a clear migration path, guides, and migration documents. For a major migration itself, there will be additional support for the migration tools and upgrade steps. For cross-platform mobile development technologies, it will be less coordinated. To avoid this risk, you need to select tools that are backed by wide communities or by massive corporations.
Native languages and tools will be supported from the day of release, whereas cross-platform tools will have a delay between the stable OS release and support of the same features within the cross-platform framework itself. It also needs to consider the probability that the newest OS release introduces either API changes that require code modifications for the app to run efficiently in the most recent OS update or alterations in the build toolkit that make builds fail. For example, when Xcode 10 was released, it included a new build tool that prevented Cordova-based Ionic Framework apps from being packaged properly on iOS devices. When we choose a cross-platform stack that has wide community support or frequent vendor updates,this trade-off is mitigated.
The main driver for these concerns is driven by the sort of app that you are building and its market and the devices you plan to support. If you are working in an agile manner, you should have quick release cycles for all app types and aim for the best user experience in every scenario.
First and foremost, the mobile development framework you choose depends on the type of app that you are building:
● Productivity apps that are B2C customer facing, such as a shopping app. You can expect these apps to be fairly complex, have a long lifetime on the store, and you want them to perform as best as possible since your company’s name will be next to the App Store ratings. You can assume that you will need to target both leading platforms on the market, currently iOS and Android.
● Enterprise apps that are for employee B2E, such as an audit tool or a plant maintenance application. These apps are expected to be long-lived, will likely be quite complex in terms of business logic, but you may not require immediate support of new OS features. With enterprise apps, your company might have a device strategy that dictates that all apps will only be developed on a single platform.
● Marketing apps that are B2C facing, such as an app for a campaign or a conference. These apps might be relatively simple, although they need to pack eye-catching features. With some exceptions, these apps will not need to remain in the app store for a long time and only be on sale during the campaign or event duration. Because these apps are for consumers, they need to be offered to all platforms on the market and you might even think of a web version.
● Productivity apps that are business partners B2B, such as a wholesale order tracking app or an inspection app. From a complexity and use case standpoint, it will be very similar to employee apps (fairly complex and with a long lifetime) but the main difference is that your company won’t have control over the device strategy of your business partners, so you will need to build apps for multiple platforms.
When staffing your mobile app project, you need to know what mobile development skills you have on your team. If you are working in an environment that has strong knowledge of a certain language or certain tools, some cross-platform mobile development frameworks may fit your needs. For example, Xamarin offers tools for building fully native apps (from a processor architecture point of view) for both Android and iOS. Or, a team of React web developers can feel more at home building React Native apps than switching to native development languages.
Other than the differences in the programming language, a common trait of many cross-platform mobile development frameworks is the support of a “hot reload” or “live reload” development approach. With this approach, because changes are not directly compiled to native code, when you make a change to a file in the development environment, the app is immediately refreshed on the simulator that you are using for development.
Even if you use any of the cross-platform mobile development frameworks, your team will need guidance from experts on the native platform. And, if the cross-platform stack does not offer a plugin for the features your app requires, then you might need to rely on external or third party resources for these features.
App complexity can be determined in various ways, but the number of included frameworks/SDKs and device features is always a good method for deciding between native and cross-platform mobile development stacks. The complexity estimate should be done at the time of solution design, where your Lead Developer or Mobile Architect will make technology decisions on the frameworks and capabilities of the mobile platforms to deliver the requested business features.
If your app needs to include platform-specific capabilities like Vision framework for native scan capability ARKit for Augmented Reality, CoreML for Machine Learning, or ApplePay on iOS, you’ll need to thoroughly research and validate whether it is worth it to build a cross-platform app and then adopt or develop plugins/bridges for these technologies or instead go entirely native. Depending on the backend technology that you will use in your full-stack app also, you need to add integration SDKs for databases, notifications, or API support.The presence of the corresponding SDK for the backend system you intend to use can be the factor of decision for a certain technology. All native tools have a corresponding SDK, cross platform frameworks cannot rely always upon.
All software released to end users requires a form of support, from fixing bugs to making sure that the app works on new OS releases. Also, mobile apps are really never “done,” and you will likely build your app iteratively, adding features over time.
If you are adopting agile and DevOps best practices, bugs and enhancements become part of the backlog and are addressed in a subsequent release by the same development team that built the app. A shared codebase is a factor that can contribute to reducing the time you spend on resolving defects, as your team would fix the issue in a single place. Also, should your company take the not-recommended decision to outsource support to a separate team, a shared codebase can contribute to having fewer resources assigned to the support activities.
Before starting to develop your next mobile app, you have to consider how long you expect the app to remain on the market. While it’s true that mobile apps are short-lived compared to many legacy solutions, it is realistic to expect a 3year lifetime for your mobile app in enterprise environments for employees and for Framework products it can last upto 5+ years as it involve more updations it will be less subjected to rewrite entire module.
Choosing a technology that ensures you can always upgrade to the latest support level offered by the mobile platform is the factor for apps that have a long lifetime, while it would not be a problem for short term apps that usually vanished from store after the event schedule. Although some cross-platform stacks are supported by large companies, such as the case of Facebook for React Native, support can be dropped at any time without notice.Possibly, with a large enough community, the project will live on, but it can be tough to choose if you plan an app for a long lifespan.
The “Hybrid” kind of apps has evolved in recent years into more mature cross-platform development tools. Many drawbacks of early web-based approaches are a thing of the past and more advanced ways have been developed to enhance a cross-platform development experience to deliver performant native code. Cross-Platform frameworks are sometimes more advanced in features than native tooling. Think about hot reload or live reload: although Instant Run on Android and SwiftUI in iOS allows for something similar, this is one feature that was ported hybrid back to native.
Cross-Platform development stacks are powerful. In the past a cross-platform mobile development framework, (especially a web-based one) would be used to accelerate the ramp-up of junior developers or to offer a path for Web developers to quickly gain mobile skills. Now, with the complexity of today’s mobile operating systems and the wide array of features and frameworks to build for, you need senior expertise cross-platform developers and strong native guidance to deliver solutions that take advantage of devices’ latest capabilities and efficient root map.
You can’t go wrong building native apps: you will have a clear upgrade path, supported tooling on the first day of new OS releases, and no performance trade-offs to make whatsoever. In conclusion, here are some rules of thumb for deciding whether to use a native or cross-platform mobile development framework. Nothing is black-or-white when it comes to technical decisions, and ideally, you should always document all the factors that drive your choice:
If you are building a B2C application targeting the stores with an expected long lifetime, build it using a native stack. Your team can still experiment with building partial features in cross-platform tools.
If you are building a complex mobile application, with heavy dependencies from native frameworks, or “first-of-a-kind” mobile apps with the latest technologies then build it using the native stack.
If you are confident that your solution has a reasonable level of complexity, code reuse, staffing and time to sell are the main drivers, then you can Consider cross-platform frameworks, bringing in guidance from senior native developers/architects/designers as needed.
The main driving success factor will always be The team: while the choice of the best-fitting stack will certainly play a major role, a motivated and truly agile team will be the determining factor to success.
In the dynamic realm of legal proceedings, efficiency is not just a luxury but a necessity. Software development companies stand poised to revolutionize legal support services, offering solutions that streamline operations with unparalleled precision and speed.
In the annals of Human Resources (HR), the introduction of Artificial Intelligence (AI) has marked a transformative leap that reshapes the traditional contours and opens doors to unprecedented efficiency.
Blockchain is a decentralized ledger or database that is distributed across a network of computers. Every block in this chain holds a unique cryptographic hash of its preceding block, along with a timestamp and transaction details.
