Skip to main content Skip to footer

Mobile App Development: How to Decide on Hybrid vs. Native

Mobile app development is an important topic that comes up often in many companies' current and future roadmaps. For those who haven't already begun to develop mobile apps, getting started can be daunting since there are many different approaches to mobile development. In the past we've compared Xamarin.Forms to PhoneGap, and tried to break down the various Xamarin and native platforms. In this article, we'll examine the hybrid web approaches (like Cordova and Ionic) and compare them more directly to native development. In the past, mobile development was focused on one of two options: either creating a mobile website that nicely adapted to differing mobile devices, or creating a truly native application using the tools available on iOS, Android, or the various other mobile options. Mobile websites were still developed using JavaScript, HTML, and CSS while native apps used Objective C, Java, or C# primarily (for iOS, Android, and Windows Phone respectively). Over time, other solutions that blend these two approaches together, creating a hybrid approach, have become available.

Hybrid App Development

Hybrid Apps allow you to execute your mobile website within a native wrapper. The wrappers provides some access to device API's, and it blends your mobile site code with a native app-like experience. These solutions package your web code into a native project (XCode, for example) where your webpage is displayed in a full screen webview within the native project. This project can then be deployed directly to a device or uploaded to the AppStore. It allows you to largely keep one code base between your desktop site, mobile site, and mobile app. We've covered some of these hybrid solutions in the past when we compared Xamarin.Forms to PhoneGap, and Ionic was covered in the Intro to Ionic Framework webcast (and now we also have an Ionic set up guide). A framework such as Ionic brings a further degree of refinement to what hybrid apps can offer in terms of look and feel. For the purpose of this article, we'll generalize our comparison of hybrid and native development, though we'll mention a few distinctions between platforms. Hybrid App Development

Hybrid App Advantages

There are many appealing advantages to hybrid app development. You can target a huge number of potential users with one code base that is shared between your website and your app. This also means most of the code can be written by web developers rather than dedicated mobile developers—which means this is often one of your cheapest options for developing an app. Most of the tools necessary for hybrid development are also open source and free. Also, one shared code base means that your code is easier to maintain, and you can quickly prototype for many platforms at once.

Screen Shot 2015-12-04 at 2.13.22 PM

Hybrid App Shortcomings

There are some very significant shortfalls to the hybrid approach as well. The look and feel of these apps will be different than pure native apps, and hybrid apps will look and behave consistently across platforms. This means the apps might deviate somewhat from the behavior of other pure native apps available for the platform, and thus might not look exactly like an iOS or Android app. In addition, hybrid apps will not perform as well as native apps. Native development also often has very good documentation available which is something that these hybrid open source solutions really can't match.Native App DevelopmentNative apps are what developers typically think of when talking about mobile development. These apps specifically target one platform that is either iOS, Android, or Windows Phone and require that you have know Objective C / Swift, Java, or C#. App design is usually based around single screens that are connected together with navigation between them. The UI can be built in a visual designer, expressed in markup language (storyboards/xibs, xml, xaml), or generated in code behind. Each platform has its own codebase, and require that you develop in different IDE's for each platform.

Native

Native App Advantages

Once again, native app development has some significant advantages that we'll broadly lump into three categories. First, the performance of native apps is the best of all options. Apps will be fast and naturally have the correct look and feel. Second, native apps have better access to device features. Most hardware features and services are directly accessible via well-documented API's. This makes it easy to collect data from internal hardware as well as provide differing features based on what hardware and services are available. Finally, native apps give you great tools for development and debugging. The native IDE's (whether XCode, Android Studio, Eclipse, or Visual Studio) offer powerful tools for debugging, profiling, and quick access to documentation directly inside the IDE. Native code is also compiled, which forces a developer to write terser, generally better code than what might be acceptable in an interpreted language like JavaScript. Many of the IDE's also come with some form of source control built in (generally Git), and are easy enough to up to GitHub or TFS.

xcode

Native App Shortcomings

The biggest shortcoming of native development is the cost. Your app will look great and be very fast, but it also requires the most specific developer skills to write. Objective C / Swift, Java, and C# and all of the accompanying knowledge of both IDE's and API's makes developing these types of applications nontrivial for those who don't have much past experience with them. This likely means that a company will either need to hire someone with these skills, or allow someone to learn these skills over a period of time. These skills will not overlap between platforms, as an iOS Developer, Android Developer, and Windows Phone developer have three different skill sets and work with three different codebases. Native platform development thus requires that you focus on one platform at a time or have many programmers available to develop each app in parallel.

Conclusion

The answer to "Which is better?" is fairly nuanced. Native apps offer the best end user experience, but require the most specific skills and are the most expensive to develop. Hybrid apps have a lower barrier to entry, are the cheapest to develop, and target the biggest market, but don't necessarily capture the correct look and feel of what end users might be expecting and generally won't perform as well or be as feature-rich. If cost is not an issue, native apps offer the best product, but in more cost-sensitive scenarios, hybrid apps still offer a compelling (if not quite as good) experience. Ultimately, the answer will come to the company, developer, and the end users as to which solution is most appropriate.

HYBRID WEB APPS

NATIVE APPS

Shortfalls

  • Need to hire JS, HTML5, AngularJS developers
  • Look and Feel is Static
  • Performance will never be as good as native
  • Device specific configurations might require freelance or consulting work
  • Documentation can be lacking

  • High development cost

  • Requires knowledge of each language you target
  • Separate codebases for each platform
  • Different IDE's and tools available on each platform
  • Requires additional knowledge, skills, and work for each additional platform

Advantages

  • Least expensive to develop
  • Biggest target market
  • Low Barrier to Entry
  • Targets the largest amount of devices with the smallest codebase
  • Creates an App that you can publish in the App Stores
  • Easier to maintain
  • Prototype very quickly
  • Utilize all of the many JavaScript libraries already available

  • Best end user experience

  • Highest ceiling for performance
  • Natural look and feel
  • Directly access device features and services via API
  • Easily provide appropriate interfaces depending on device
  • Utilize Native IDE, Documentation and Development tools
  • Easier to debug and profile code
  • Most accurate product for a single market

Recording of our Hybrid vs. Native Webcast

MESCIUS inc.

comments powered by Disqus