Before we incorporated mobile application development into our fortes, we had been focusing solely on web development and with the emergence of powerful mobile devices, on the adaptive and responsive web. However, this state of things did not last too long. Mobility captured the world introducing native development and the whole new approach to production with it.
Dawn Of Native
The initial path to take was in seemingly versatile existing and firmly established tools. In late 1990’s, Java’s AWT (Abstract Window Toolkit) was replaced with Swing – a GUI toolkit providing a sophisticated set of graphical user interface components. It was the first attempt to emulate the some of the proprietary platforms look and feel, or take shape of outside platform UI regardless of the underlying platform. Sort of…
Swing never really became mainstream. Generally because of the amount of maintenance to be done across platforms in terms of JRE, CSS rendering to Swing, things like multithreading support, etc. Many attribute Swing’s imperfections to the reasons why Java didn’t become a success among consumer desktop users.
Swing wasn’t designed for touch-based UIs so a decade later Java’s potential was reinvented in Android – the designated digital camera operating system that in a good way, spun out out control. Although using the same language as Swing, Android was designed in .xml files and specifically for mobile. However, the early start of Android was shaped by its closest rival’s birth.
A year before, Apple released the first iOS that was not yet native. Although applications for the first ever iPhone had native look and feel, they were mostly developed using the Safari web browser, compatible with iPhone OS. The truly native iOS journey began with the launch of iPhone SDK.
The strong sides of native development discovered along the way are:
- Running speed. Native apps code is written using platform-specific IDEs which is resource-efficient and optimal in terms of the speed of production.
- Integration. No web app can integrate the device services and features as seamlessly as a platform’s true born native app.
- Relevance. Native app developers have the ability to implement the newest and hottest features of mobile operating systems as well as the hardware growing capabilities, and mobile-first technologies, like touch-based, geo, and gyro-services.
- UI/UX standards. Each mobile platform maintains its unique look and feel through multiple guidelines and design principles. Quality standards and reference to the best practices raise the bar for native application developers and stimulate the industry progress.
While native mobile app development pros are undisputable, the main issues stopping businesses from fully embracing it are:
All of these are significantly higher in demand due to the variety of platforms native apps are built for, which triplicates the product in case you are only counting the major platforms.
Resilience Of Cross-Platform
No doubt, the pivotal introduction of high-performance mobile devices has changed the way we approach computing. Native applications fluently and organically entered our lives and initialized a whole new culture of design and development. However, native development not only didn’t kill cross-platform web applications but in a way became the Kryptonite for them.
For a brief moment, some attempted using two URLs for two different versions – desktop and mobile. This obviously didn’t stick. In 2001, developed mainly to beat browser discrepancy, audi.com launched the first ever responsive website.
The idea of a web application having design presets that automatically adapt to every major delivery media started another branch of web development, crossbreeding with the mobile experience.
Since then, cross-platform development is nowhere to go due to some strong statements it makes:
- Speed. With sufficient knowledge of all major platforms and adaptive/responsive principles, design and development become fast and patterned.
- Cost. If time is money, then saving time saves money. ¯\_(ツ)_/¯
- Maintenance. Much like in subversion, in cross-platform development, you don’t need to make changes to every single entity. Changes affect all platforms and updates are applied equally.
- Consistency. Different platforms showcase different features affecting presentation. Maintaining a consistent thread of your app throughout all the platforms is a classy move.
Having said that, there are significant drawbacks that explain why native tends to beat cross-platform so far:
- Off performance. Even though things might look good on the inside and on a larger scale, it’s the subtle flaws that might kill the vibe. In terms of UX, web application and its mobile version are miles apart. The mobile platform web apps have to inherit native UX in order to be appealing.
- Limited integration. A native app can leverage the full potential of the device’s native APIs, while cross-platform apps are only capable of accessing some.
- UX Discrepancy. Sort of a disservice that native apps do to cross-platform, is create an addictive experience and patterns that users start expecting from web apps as well. Failing to fulfill those alienates the web app.
In fact, I think there has to be no antithesis in the native and cross-platform application relation. Instead, the UI/UX design has to be a unifying force between the two.
The real challenge is to cover the needs of all the users instead of patting on the back those whose choice you like and criticize those you don’t agree with.
This concept has been already proven by the who’s who of the industry. The Facebook native app is faster and a bit more handy in terms of navigation, however, there is no frustration when accessing facebook on a mobile browser. Same with Medium, where the content-heavy UIs are barely distinguishable and equally good.
We’ve come to the conclusion that responsive web apps and native mobile apps have to be evenly prioritized. Most clients concentrating on their web apps prefer not to dissipate their focus from the flagship products. In this case, our goal is to deliver a high-performance and impeccably designed web app with responsiveness. At the same time, whenever there is a mobile app development project, we make sure to leverage the best options available for the native mobile platforms.
Wild Card Of Hybrid Development
Just like a normal app, you download those apps on App Store or Google Play, they require installation, but are also accessible from a browser, and have a separate icon.
The key difference is that hybrid apps are hosted inside a native application that utilizes a mobile OS’s webview.
The idea that general capabilities of any mobile OS include similar browser behavior, there has to be no problem converting hybrid apps for any OS by means of customizable wrappers.
One of the most popular technologies in hybrid cross-platform development is Apache Cordova. The webview of a mobile application runs the mobile version of a web app. The device’s native capabilities like camera, sensors, buttons, etc. are triggered by the Cordova API. Check out LinkedIn’s article about their attempts to build a viable mobile experience using HTML5. Something they call The Native/Web Messaging Bridge and WebSockets.
Why Go Hybrid
The obvious pros of native speak for themselves, but there is a chance to blur the edges and make use of developers’ existing skills in web development. Developers generally don’t like to be constrained by the limitations of proprietary platforms. Instead, they want to leverage the best of their ability to compile and invent. In that sense, hybrid is an attractive business approach.
At the same time, Android’s version inconsistency and Apple’s innovations from version to version impose a lot of responsibility on hybrid app developers in terms of staying relevant and being able to take into account all the variables.
Perspectives Of Hybrid
The alternative approach is nowadays being extensively studied with a view to discover whether there are ways to reach the all-round potential of hybrid development and develop heavy-duty native apps without learning the intricacies of native dev tools, but using some sort of flexible, versatile, and conventional technologies. For example, the NativeScript framework is capable of building iOS and Android apps that utilize the iOS/Android APIs and webview to leverage performance. With NativeScript you can also ditch the plugins that might cripple the potential of a hybrid application. At the end of the day, it doesn’t matter to the end user which type of app they are using as long as it does what it’s supposed to.
To illustrate this thought, here are the examples of some of the super successful hybrid apps:
The Wrap Up
In hindsight, it’s about whether the cake is worth the candle. Are you ready to place a bet on performance within the range of the available native development features, or utilize the budget-efficient and unconventional approach of using multiple web technologies and create a unique experience?