Native, Hybrid Or Responsive – Which Is The Right Way Forward?
Touchscreen devices have revolutionized the way in which we interact with computers. Today, people spend far more time on their mobile devices than they do with their desktops or laptops. This shift in consumer behavior has led to the requirement for mobile-first development and design.
Before we explore the methods that are being explored today for mobile first solutions, let us first have a look at the history of mobile application development. Previously, companies such as IBM, Blackberry, Palm, Erickson, and Microsoft used to develop proprietary operating systems such as Simon, Windows, Palm OS etc. These applications were inbuilt into the phone’s operating system.
Others delivered content with the help of built-in mobile browsers. The content was customised for consumption on small screens which would often be of inferior quality.
Later on, Java applications, especially games, became very prominent. Any devices that supported Java runtime could run these apps. This was the birth of independent app stores.
Unfortunately, these early applications had a lot of compatibility problems and issues. One of the biggest question plaguing web developers at the time was – how can we display the existing web pages across multiple devices whose screens come in all kinds of shapes or sizes? It would take years for responsive web design to be born.
Apple released its first iPhone in 2007. A year after that, it began to offer tools to write native applications for its smartphones. These tools also began to become available for sale at online marketplaces such as the Apple’s App Store or Google’s Play Store.
Today, there are 3 major ways of developing mobile applications –
- Responsive web design
- Native development
- Hybrid development
Each of the aforementioned technologies meets specific requirements for any solution and have both advantages as well as disadvantages.
We will discuss the same in details below.
Responsive web design
Screen sizes of smartphones are now big enough to fit in a lot of content. This means that most websites will open and be accessible on these phones. Whenever users access a site, they like to rotate, zoom in and out or navigate and scroll in other ways. Any developer who depends upon the device to deliver these functions smoothly to the user is giving a bad UX to the visitor and it is unlikely that there will be a return visit to the site, especially on the smartphone.
Fortunately, the solution to these challenges in most cases is to apply styles to the web pages. They can also be corrected by adjusting the layouts and views for mobile devices. This is done by front-end engineers who are proficient at getting any site to display smoothly. Furthermore, existing websites can also be made over so that they become responsive on mobile devices as well.
The disadvantage of using responsive web design is that the website will be running on a mobile web browser. As such, no native mobile functionality such as location detection, cameras, sensors etc. will be available.
When should we choose responsive web design?
- When we need our website to be properly displayed on a mobile device.
- When we are not in need of any native functionality such as using sensors, taking pictures etc.
- When we need to display content fast on mobile platforms such as iOS, Windows, Android etc.
When should we not choose responsive web design?
When we are in need of native mobile functionality
Native mobile application development (NMAD)
Mobile devices have a tremendous potential for revenue generation. In order to access a phone’s fingerprint scanner, camera, GPS or any other features, we need a native application.
Does this affect development costs? Today, there are mainly 3 ecosystems – Android (Google), Apple and Microsoft. These 3 make up about 99 percent of the total market share. In order to reach out to each ecosystem, we need developers with separate skill sets. For Apple, developers must be proficient in Objective-C or Swift. If we are trying to target Android, developers have to be good with Java. For Microsoft, developers have to be proficient with C# or other Microsoft technologies. It is difficult to find developers who possess knowledge across all these categories.
The first hurdle to pass, therefore, is to find developers with skill sets that match each of these ecosystems. After that, different code for each platform will have to be written since the Application Programming Interfaces (APIs) and the Software Development Kits (SDKs) are different from each other. After the submission of the mobile apps in each ecosystem, the latter will come up with different guidelines for UX. Almost all the devices’ features may be accessed in return for an increased development cost.
If we choose to target anyone ecosystem, it presents its own set of challenges such as fragmentation. With various OS devices and versions, this results in many possibilities on how an application will behave or stop working. Fragmentation stops us from using all the new features of the device.
When should we use NMAD?
- When we are targeting only android, Apple and Microsoft users.
- When we have no plans to reuse resources for other ecosystems.
- When we need to have access to device functionality that is not on offer by other development methods.
- When we want the best possible UX for any specific ecosystem such as performance, compatibility, and view etc.
When should we not use NMAD?
- When we do not require native functionality.
- When performance is not an issue.
- When we do not possess either the time or the budget to develop each ecosystem separately.
Hybrid Mobile Application Development (HMAD)
All hybrid frameworks work the same way. Native functionality and native runtime are abstracted away. Then, they are exposed to the upper layer where the application is written. Sometimes, the platform abstracts the top layer even more. This is done so that the frameworks that are being used for desktops can be used. The upper layer can be tackled in several ways.
Alternatively, we can develop the application through a framework. Then, the application can be compiled to platform-specific elements and implement platform specific parts. The performance is as good as a native application. This is used by Xamarin and React Native.
In both the cases, the applications are installed, distributed and packed up as native applications.
With the help of HMAD, we can use the same code base to cater to multiple device ecosystems. Furthermore, any developer who has knowledge of web technologies will be able to work on this. Due to the aforementioned reasons, compared to NMAD, the speed to market and the development costs are reduced significantly.
However, every phone functionality cannot be mapped into a framework.
All frameworks allow plugins. Development has to be performed in the native language of the platform. This adds to the expertise and the development effort substantially. Sometimes, this makes the development of a native app more practical. On this occasion, the app would look exactly the same both on iOS as well as Android. This may create problems since the UX guidelines are different for each ecosystem.
When should we choose HMAD?
- When we are targeting multiple platforms.
- When the frameworks cover phone-specific functionality.
- When the developer has a limited skill set.
When should we not choose HMAD?
- When the framework does not possess certain native functionality.
- The best experience across every platform is desired
When choosing between hybrid, native and responsive mobile app development, we have to consider the following –
- Consider the advantages and disadvantages of each platform.
- Assess which one is the priority – the right tool or speed to market.
- Perhaps most importantly, we have to understand the market we are trying to cater to. Otherwise, we will be wasting our resources on functionality that we do not need and thus fall behind our customers.
For example, HMAD offers a lot of features but is not necessarily the right approach especially if we do not need the features. If we are in need of basic interaction with the application, responsive design is the right choice. Since we can build a mobile support without the need for a separate app, this leads to cost savings.
If we are trying to cover only one ecosystem and want top performance, NMAD is the way to go.
It is always best to observe the market that we are trying to penetrate before we can freeze upon the right platform to use.