How To Choose Between Native and Hybrid to Build Mobile Apps

As most of us in the developer community already know, there is a major ongoing debate over what technology to build mobile apps with: native, hybrid, or mobile web/responsive design. For most developers, this is a zero sum game: Some advocate always using native, others advocate always using hybrid, etc. My argument is that you should use all three. It just depends on the stage your project is in.

When you are at the proof of concept (POC) phase—a brand-new startup idea or a new greenfield enterprise application, for example—your needs are very different from when you are further along. For example, at this early stage you only need to do things quick and dirty in order to get something out there and get user or market feedback. You may need to connect to a Back-end data service but maybe you don’t need quick refresh rates or checking for an error condition. During the POC stage, you are best served by building a browser-based mobile web app using HTML5 and JavaScript.

The reasons for this are twofold. First, building a mobile web app is fast and easy and your staff probably already has the necessary skillset (HTML5, CSS and JavaScript) to build the POC very rapidly. Second, at this stage you most likely will have to rapidly iterate your POC while doing customer discovery and getting user feedback. When you ask potential users to test your app, you don’t have to worry about having them go into the AppStore and download something; you just give them a short URL or QR code to your mobile web app.

Deployment is exactly the same as a web page because it is a web page—just one optimized for mobile. After you get feedback from your first few users, you can just make changes to the mobile web app, then the next person you interview will automatically have the new version (as well as anyone who still has it from a previous interview). This leads to much faster iterations of your design.

After you move past the POC stage and into full-fledged development, most of the time it is appropriate to build a hybrid mobile app. Again, there are two reasons for this. First, you will automatically target iOS and Android (and other operations systems if you use Cordova or other hybrid technologies) with only one code base. The true value of the hybrid approach is that you write your application in with HTML5, JavaScript, and CSS and compile into a native Container, giving you one code base, but deployment to both the Apple AppStore and Google’s Play Store. If you go native here, you will have a code base in both Objective-C for iOS and Java for Android.

The second reason is skill set—especially if you are a startup. Skill set is also important if you are in the enterprise because you may not have developers who know Objective-C or Java on your team, but almost all developers know HTML5 and JavaScript.  If you are a startup or an enterprise struggling with budget constraints, this is essential, because you need fewer developers.  In an early phase of a project there are always a ton of changes. Having only one codebase is quite useful in this environment because it lowers your development costs. By going hybrid early on you will not have to overinvest in more developers, more training or multiple code bases.

After your app has more traction and is more mature, potentially the time to go native has come. After you have fleshed out what the app is all about and you have a stable user base, you can dive deeper and take advantage of the local native Platform and User Experience such as direct access to the hardware or some UI components not exposed via the hybrid approach. Hopefully your app has generated profits or enough use to warrant the extra cost of a rewrite with multiple code bases.

If you read this and think I am crazy, let’s take a look at some of the most-used apps on a mobile device today. By far, the most-used app has to be Facebook. Facebook started out in the early days of mobile as a mobile web app. You would go visit (it still exists and is still quite good) to have an early Facebook experience on mobile. This was a way for Facebook to get on devices super-fast, avoiding the app store and platform fragmentation. They also learned how their users interacted in mobile, which is different from how they interacted with the web site. Since Facebook was a popular web site before a mobile app, Facebook developers built the mobile web app as a stopgap while they built their mobile app. This got Facebook a great mobile presence very quickly, blocking a new social media platform from end-running Facebook on mobile.

Facebook then built a hybrid mobile app, put it in the AppStore/Google Play, and made it the company’s flagship mobile presence for more than four years. This let Facebook ride the Android wave and allowed the company to save development resources with only one code base. Lastly, once Facebook became the dominant player, it moved to a native app. At this point Facebook was profitable and had close to a billion users. (One could argue that Facebook waited a little too long to go native, but the overall strategy of mobile web app to hybrid to native was correct.) If you think Facebook is an outlier, LinkedIn did the exact same thing.

While this advice won’t fit every situation, it is definitely applies to most situations. Good luck with your mobile development!

Be sure to read the next Application Development article: Developers Take on the Fire Phone Dynamic Perspective Functionality