Five Things to Consider When Deciding Between Native and Hybrid Mobile Apps

Chris Newhouse
Feb 17, 2017 · 8 min read

While everyone else has passionate debates about iOS versus Android, mobile app producers are having a much different debate — how to create a slick and engaging app that can best reach both audiences. To go native or hybrid — it is an age-old question that has been debated as long as mobile apps have been around. Each school of thought has its own advantages and disadvantages, and the decision should not be taken lightly, as it will have implications for the maintenance and future of an app as technology continues to change.

Let’s go over the basics. A native app is developed specifically for mobile operating systems using either Swift/Objective-C (iOS) or Java (Android). To deploy an app to both operating systems, you’ll need to have two separate codebases that are both maintained as you make updates. Hybrid apps attempt to simplify things by allowing developers to write one codebase and deploy to multiple operating systems. Built using HTML5 and JavaScript, a hybrid app is then packaged into a native wrapper, giving it the illusion of being a native app. On a first consideration, it may seem like going hybrid will save time and effort, but the story is a lot more complex than that. In this post, we’ll discuss what you should consider before making your own decision.

1. User Experience

There is no greater factor in the success of your mobile app compared to competitors than user experience. This broad term encompasses many things, ranging from the big picture to the fine-grained nuts and bolts. How is each screen of your app laid out? How does the user flow between those screens? And how does the user interact with each individual component of those screens, whether it is reading text, tapping on buttons, or swiping items in a list?

When planning out how your mobile app will work, you’re probably focusing on the big picture stuff. As mobile app creators, we at Appstem can help you build whatever vision you have, but we’ll have to fill in a lot of those fine-grained details. And those are of paramount importance.

The average users of mobile phones spend about 90 minutes per day on their phones. [1] That’s 23 entire days per year interacting with the iOS or Android operating system. Users become intimately familiar with the carefully crafted environments that Apple and Google have designed, whether it is a left- or center-aligned title bar, the speed and acceleration of scrolling through lists, or the visual feedback cues of tapping on buttons. Even if we can’t explicitly call to mind all of these elements of user experience, they help us to feel at home when using apps on our phones and tablets.

So how is user experience affected by native and hybrid apps? Quite significantly! Most of the things we’ve described here come standard when developing a native app. Everything built using the toolkits provided by Apple and Google are already styled in a consistent manner with the rest of the platform. On the other hand, hybrid apps are forever playing catch-up. Without extra effort, many hybrid apps seem like exactly what they are — a website that happens to be sitting on your mobile phone. Users tend to be left feeling as though the app does not belong as much to the platform as the other apps on their device. They are more likely to discount the app as being somewhat unprofessional.

On the other hand, some hybrid apps do successfully emulate aspects of platform look and feel. However, this requires extra effort from the developer, and some separate code for Android and iOS, which starts to eliminate the timesaving benefits of hybrid. Usually developers will use third-party cross-platform frameworks to help with this task, but inevitably when Android or iOS releases a new OS version, developers will be left waiting for someone to release a library or an update that simulates the newest design patterns. Native apps in most cases won’t even need an update to get a new OS version’s look and feel, and otherwise only require minor changes.

2. Performance and reliability

Surveys show that mobile app users are impatient. About half of users expect apps to start up in two seconds or less. [2] Additionally, users aren’t going to give your app many chances if they encounter any problems, including crashes, freezes, and other issues. A full 80% of users won’t put up with any more than three problematic experiences. [2] It is clear that you’re going to have to impress your users from the very beginning, and that starts with a smooth and speedy experience at every turn. Unfortunately for hybrid apps, the foremost focus for Apple and Google is to improve performance for native apps. Browser performance is continually improving, but research shows that it still lags well behind native apps. [3] Users want instant gratification, and native is going to provide much more of that than hybrid.

Some users may put up with a slow app, but very few are going to tolerate bugs and crashes. Hybrid apps are once again at a disadvantage here, because they have an extra point of failure. As most hybrid apps rely on some type of cross-platform framework in order to be deployed on both iOS and Android, there is a third-party software company that is in charge of some of the code of your app. As these frameworks are constantly needing to be updated to support the latest versions of mobile operating systems on a vast array of devices, they are often shipped with bugs that developers have no choice other than to wait on for fixes.

3. Hardware and platform-specific feature access

The promise of one codebase for multiple platforms can be slightly misleading. It may be true that you can construct user interfaces and interact with web services using only HTML5 and JavaScript, but many mobile apps do a lot more. Smartphones have a lot of built-in capabilities, such as GPS, cameras, address books, and much more, not to mention opportunities to work collaboratively with other apps on the same device. These features are not utilized or accessed the same way on Android and iOS, and that is where cross-platform frameworks attempt to bridge the gap. In some cases, cross-platform frameworks handle this well, but it is not always simple to create a unified way to do something for Android and iOS, as the platforms were designed differently.

Where it is possible, cross-platform frameworks do attempt to provide unified solutions for these specialized features, sometimes through user-generated plugins. As mentioned before, the more external software used, to greater the potential for outside source of bugs. In other cases, developers have to create two branches of code that are conditionally used depending on whether the app is built for Android or iOS. This is starting to sound a lot more like native development rather than a single codebase. In fact, with separate native code for each platform, along with code to integrate the feature into the hybrid codebase, this can end up requiring more effort than simply building two separate native apps!

4. Maintainability

As technology and products are continually evolving, building a mobile app certainly doesn’t end once you’ve released it to the market. You’re going to continue to have to refine and build new features to keep your users engaged, and update your app to conform to the latest technology and design standards.

While we at Appstem would love to continue to work with you to maintain your apps, we understand that some companies would like to take things in house after an initial release. For this reason, it is important to understand the implications of maintaining native and hybrid apps. For native, the story is pretty simple. You’ll need an Android expert to perform updates for your Android app, and an iOS expert to do the same for your iOS app. But because even mildly complex hybrid apps tend to have native modules for specific features, to maintain a hybrid app you’ll need to have expertise on your team not only in cross-platform development, but in Android and iOS as well.

We also mentioned when discussing user experience how cross-platform frameworks tend to be playing catch-up with the native operating systems. In a world where it is critical to be on the technological forefront, it is important to keep in lockstep with Apple and Google as they make changes to iOS and Android. Some of this comes with no extra effort for native apps, and any new design patterns or features are easy to implement quickly, as developer tools for new operating system versions are usually released to the development community well before the updates are made public. On the other hand, updates to cross-platform frameworks that attempt to replicate new platform-specific UX and features can often lag well behind public releases.

5. Time and cost

You might think that one clear upper hand that hybrid development has is in the business portion. Time to market is key and budget concerns tend to rule over all others. And for simple, straightforward apps, that is a valid point. However, as we’ve learned in the prior sections, most hybrid apps are going to involve a lot more than simply half the work of two native apps. Additionally, as an iOS team and Android team can work entirely independently, they can easily keep pace with a hybrid development team, and sometimes work even faster in cases where the hybrid app would require a lot of conditional code.

If cost constraints limit you from starting out with two native apps, you might consider the necessity of entering the market simultaneously in both the App Store and Google Play. Each individual store has a massive audience, and if you can capture the world’s attention in just one, you’ll have no problem building the case to invest in other, drumming up a lot anticipation by users in the process.

Summing it all up: compromises, trade-offs, and shortcuts

Most people look to hybrid apps because they see it as a shortcut to reaching the two major mobile audiences. But just like most aspects of life, this shortcut involves many compromises and trade-offs. The primary benefits of going hybrid are reduced time and cost (although less than one might expect), but this is a shortsighted way of looking at things. In the long run, a hybrid app is going to require more time and investment making updates to improve performance issues, add OS-specific features, and maintain modern platform look and feel.

For these reasons, many developers and development firms, including Appstem, recommend building native applications. They are a long-term investment that will pay dividends throughout the lifecycle of your application. Hybrid applications have their place, but in most cases, going native will keep your customers more satisfied and engaged, while allowing you to spend more time innovating.

[1] http://www.mobilestatistics.com/mobile-news/23-days-a-year-spent-on-your-phone.aspx

[2] https://techbeacon.com/resources/survey-mobile-app-users-report-failing-meet-user-expectations

[3] http://www.infoworld.com/article/2610329/mobile-development/forrester--html5-apps-still-not-as-good-as-native-apps.html

Appstem

A product design and digital agency with a passion for…

Appstem

A product design and digital agency with a passion for informed, human-centered innovation, Appstem transforms complex business problems into elegant digital solutions.

Chris Newhouse

Written by

Appstem

A product design and digital agency with a passion for informed, human-centered innovation, Appstem transforms complex business problems into elegant digital solutions.