Touchscreen devices have changed how we interact with computers. People are already spending more time on their smartphones than their desktop machines.
This shift in behavior has prompted the need for mobile-first design and development. A mobile-first approach is important, but where do you start? In this post, I’ll detail three methods being used today and what approach will work best for you.
A mobile history lesson
First, let’s look at mobile application development’s humble beginnings. In the early days, companies like IBM, Palm, Microsoft, Erickson, and Blackberry developed proprietary operating systems—Simon, Palm OS, Windows, among others. Applications by these companies were built into the phone’s operating system.
Others had to rely on delivering content through a built-in mobile browser. Content had to be specifically designed for small screens (at the risk of ending up on the user’s hate list).
Later, Java applications—particularly games—became prominent. These “apps” could be used on devices that supported Java run-time. The first independent app stores had been born.
These early apps were replete with compatibility issues and problems. For web developers, that question was, “How do you display existing web pages in different mobile devices with different screen sizes?” It took years before responsive web design was born.
In 2007, Apple released its first-generation iPhone. A year later, Apple began offering tools to write native applications for smartphones. They also offered markets to sell these tools, such as Apple’s App store or Google’s Play Store.
Other companies, mostly limited by their operating system’s capabilities, enabled developers to create applications using a browser technology (HTML, CSS and JavaScript). Some considered this a workaround. Others, an opportunity. Either way, it was the beginning of hybrid mobile development.
Mobile application development today
Three major development routes exist today:
Responsive web design
Native mobile application development
Hybrid mobile application development
Each of these techniques fit specific needs and have their own pros and cons. In the sections below, I’ll elaborate more on each of the approaches.
Responsive web design
Phone screen sizes are now large enough to fit substantial content. The odds that your website opened and is usable on any of these devices is high. However, the user might need to rotate the device, zoom in and out, or scroll to the side when navigating your site.
You might think, “That’s okay. Every smartphone has these functions, so every user must know how to use them, right?” In reality, this is a poor UX (user experience) and your user is less likely to return to your website, especially on a mobile device.
An example of a website without responsive design. In order to view the content on the middle screen, the user has to scroll to the right. And scrolling down (right) shows blank space.
The good news is that in most cases, this can be solved by correctly applying styles to your web pages and adjusting views and layouts for mobile devices. This is typically done by front-end engineers, as they know all the quirks and tricks to get your site to display smoothly. The makeover of an existing website would result in responsive web design that displays well, not just in a desktop web browser but also on a mobile device browser.
The drawback here is that your website will be running in a mobile web browser. You won’t have the ability to use any native mobile functionality (e.g., location detection, sensors, cameras, etc.).
When to choose responsive web design
You need your desktop website to display properly on a mobile device
You don’t need any extra mobile native functionality (taking pictures, using sensors, etc.)
You need to quickly display content on mobile platforms (iOS, Android, Windows, etc.)
When not to choose responsive web design
You need any native mobile functionality
Native mobile application development (NMAD)
Ignoring the possibilities that mobile devices offer is a mistake, especially if you see their potential for revenue generation. To access a phone’s camera, GPS, fingerprint scanner or any number of features, you need a native application.
But how does it affect development costs? First, consider that today there are three main ecosystems: Apple, Android (Google) and Microsoft. Others are out there, but these three make up 99 percent of market share. To target each ecosystem, you need a developer with a different skill set: For Apple, developers must be well-versed with Objective-C or Swift; for Android, Java; for Microsoft, C# or other Microsoft technologies. Finding someone with all of these skill sets is like finding a driver with all categories in their driver’s license, plus a pilot license.
Even if you succeed in finding a developer with each skill set, the software development kits (SDKs) and application programming interfaces (APIs) are so different that one would end up writing different code for each of these platforms. Once you submit your mobile app, each ecosystem also has different guidelines for UX. For an increased development cost, you can access almost all of the device’s features.
An example of how widely used controls can vary on different platforms (iPhone on the left, Android on the right).
Even if you choose to target just one ecosystem, there’s another trouble-making phenomenon called fragmentation. With various OS versions and devices, the result is an endless amount of possibilities in how your application will behave (or stop working). Fragmentation limits your ability to use the device’s newest features or the population of the market your application will be accessible to.
When to choose NMAD
When you target only iPhone, Android or Windows users and don’t plan to reuse resources for other ecosystems
When you need to access device functionality that other development methods can’t offer
When you want the best experience for a specific ecosystem (performance, view, compatibility)
When not to choose NMAD:
You don’t need specific native functionality and performance isn’t an issue
Budget or time does not allow you to develop for each ecosystem separately
Hybrid mobile application development (HMAD)
All hybrid frameworks work on the same concept: Native run time and native functionality is abstracted away and exposed in a uniform way to the upper layer (in which your application is written). Some of the platform abstracts the top layer even more so frameworks that are used for desktop could be used. There are several approaches how to tackle that upper layer.
One of the most compelling methods is to use web technologies like HTML, JavaScript, and CSS. Typically these kinds of hybrid applications have a single-page application (SPA) running locally, which is enriched with JavaScript functionality to access mobile native features. This approach is used by Cordova, PhoneGap, and Ionic. One drawback here is that your application runs as a local web page, so performance is impacted.
Another approach is to provide a framework, which is used to develop the application and then later compile for different platforms by mapping to platform-specific elements and substituting native specific parts with platform specific implementations. In this case, the performance is on par with native application. This approach is used by React Native and Xamarin.
In both cases, applications are packed up, distributed, and installed as normal native applications.
What makes the HMAD so appealing is the option to target multiple device ecosystems with the same code base. Also, your developer doesn’t need to have a very advanced skill set—only web technologies. These two reasons reduce the development costs and increase speed to market significantly, compared to NMAD. However, there is a limitation on the device capabilities that can be used—not every phone functionality is mapped into frameworks.
All frameworks allow extension of native features via plugins. Development must be performed in the platform’s native language, which adds to development effort and expertise substantially. In some cases, this makes native development more practical. In this approach, your app would end up looking the same for Android and iPhone, (unless you specially code for otherwise), which may not be the desired outcome, considering the different UX acceptance guidelines for each ecosystem.
iPhone (left) and Android (right) applications can end up looking very similar developed using HMAD.
When to choose HMAD:
When targeting multiple platforms (typically more than two)
When phone-specific functionality is covered by frameworks
Limited developer skill set
When not to choose HMAD:
Framework is missing specific native functionality
You want the best experience for each mobile platform
Testing mobile applications
Regardless of the approach you choose in building your application, it must first be tested before being presented to users. Application functionality and user interface (UI) can be tested on emulators or browsers, but features that involve phone functions, such as gestures and sensors must be tested on real devices, and on as many different devices as possible.
Which approach should you choose?
Before choosing between responsive web design, native, or hybrid mobile app development, consider the following:
Weight the advantages and limitations each approach delivers.
Ask yourself, what’s more important, speed to market or using the right tool?
Understand your market. Not knowing your market can result in wasting money on functionality you don’t need or in staying behind the competitors.
HMAD is the hottest trend and offers the most features, but that doesn’t necessarily mean it’s the best approach if you don’t need those features. Responsive design may be enough if you require only basic interaction with the application. This route offers development cost savings, as mobile support can be built without requiring a separate app. NMAD is also good if you need to cover only one ecosystem (Android or iOS), need top performance but use hardware on a low level.
Observe your market and choose the method that works best for your needs.
References:
“Beginning Hybrid Mobile Application Development”, Mahesh Panhale, Apress, 2016
“Mobile Design and Development”, Brian Fling, O'Reilly Media, Inc., 2009