Hybrid mobile apps are like any other apps you’ll find on your phone. They install on your device. You can find them in app stores. With them, you can play games, engage your friends through social media, take photos, track your health, and much more.
It can be very difficult to tell how a mobile application is built. Hybrid mobile applications are no different. A well-written hybrid app shouldn’t look or behave any differently than its native equivalent. More importantly, users don’t care either way. They simply want an application that works well. Trying to figure out if a mobile application is hybrid or native is like trying to differentiate rare grape varieties of wine. Unless you’re a sommelier or someone who really cares about it, it’s not terribly important. What matters is that the wine tastes good. The same can be said for hybrid mobile applications; so long as the application does what it’s supposed to do, who really cares how it was built? This point is underscored through an experiment we conducted where we wanted to see if people could tell the difference between a native application and a hybrid application:
These plug-ins include APIs for accessing the device’s accelerometer, contacts, camera, and more. There is also a number of plug-ins that are built and maintained by the developer community at-large. These can be found in the Apache Cordova Plugins Registry. A curated subset of these plug-ins that have been throughly tested, documented, and extended can also be found at the Telerik Verified Plugins Marketplace.
Hybrid mobile applications provide a way for developers to re-use their existing skills in web development. Developers don’t like the prospect of getting locked into proprietary platforms. This includes the programming languages and SDKs provided by platform vendors (more on this later).
Yes, it’s true that hybrid mobile application development enables developers to target more than one platform. However, each platform comes with a set of caveats when it comes to its web runtime or WebView. This is especially true with Android, which is inconsistent between OS versions.
Moreover, there might be unique capabilities of platforms to which a developer may wish to target. In those instances, a combination of plugins and platform-specific code must be utilized in order to take advantages of those capabilities. Alternatively, developers can take advantage of 3rd party web runtimes like Crosswalk that can be embedded in your hybrid app.
It should be noted that Android 5.0 introduced updatable WebViews via the Android System WebView. Check out What Android 5.0’s Auto-Updating WebView Means for Mobile Apps for more information about this recent change and the impact it will have for hybrid mobile development.
Before committing to a platform strategy, it’s important to evaluate the technical and non-technical merits of hybrid versus alternatives like web and native – especially as it relates to your mobile application’s requirements. For example:
These and other questions are worth asking before embarking upon development of a mobile application. To elaborate on this, let’s examine a few of these questions in more detail.
If you wish to target more than one platform, you have a number of choices. Clearly, the web offers a highly attractive solution for this requirement. Your target is the mobile browser. Hybrid lends itself well to this approach as well because of its reliance upon the WebView.
Native – on the other hand – finds itself in a unique space. If you are reliant upon the vendor SDKs and platform-specific programming languages then you are essentially coupled to the platform. In the case of iOS, it’s Objective-C or Swift; for Android, it’s Java; and for Windows Phone, it’s C#. It should be noted that native deliverables can built using cross-platform technologies like Xamarin, React Native, and NativeScript.
If you want to distribute your application via an app store, you must build a hybrid or native application. You cannot distribute websites through app stores; that’s what your browser’s address bar is for! Despite this restriction, whether you build a hybrid or native application, it’s highly recommended that you have a website available for your mobile application. This will be the first place your users will expect to go if/when they encounter problems.
Websites have a restricted set of abilities as opposed to hybrid and native applications. These restrictions are enforced by browser, effectively sandboxing it away from the mobile operating system. Recent developments with mobile browsers have exposed more device capabilities through HTML5 such as the camera, geolocation, and others.
Despite these advancements, support for advanced functionality is quite limited. For example, media capture and streaming remains unsupported in various mobile browsers. Because limitations like this remain in mobile browsers, many developers are compelled to evaluate hybrid and native as alteratives. Both offer the ability for developers to access device APIs – in the case of hybrid, this ability is supported through plug-ins.
It’s often asserted that native is best suited for applications where graphics performance is paramount. Mobile games are a class of mobile application almost entirely reliant upon complex visual interactions on the screen. Even if a game operates flawlessly from a functional perspective, you should expect it to have a very low app store rating if it feels slugglish. For that reason, developers have long-argued against using hybrid as an approach to build games.
That stated, a number of solutions for hybrid mobile applications exist. These include HTML5 Canvas and WebGL, both of which are well-suited for building applications like games. Furthermore, technologies like these are more approachable for developers through libraries like Paper.js, EaselJS, and others. And it’s not just for game development. For developers building more traditional, line-of-business applications, there are frameworks like Famo.us and Kendo UI.
Finally, it’s important to recognize that hybrid isn’t the be-all and end-all approach for mobile application development. Earlier in this article, I cited the challenge of overcoming the inconsistencies between WebViews. Other challenges remain. In fact, with hybrid, you can find yourself targeting the features of a mobile platform only to discover that they’re inaccessible because the plug-ins for them are out-of-date, unreliable, or (even worse) missing altogether. In this scenario, you are faced with the dilemma of either removing an application feature or writing the plug-in yourself.
This scenario is more pronounced when new versions of a mobile platform are introduced. If you wish to leverage these new capabilities, you either have to wait for someone in the community to write the plug-in or develop the plug-in yourself. My advice is to know what plug-ins are available and reliable before proceeding with development.
There are a number of well-known hybrid mobile applications available in app stores. Some of my favorites include Basecamp, Instagram, Yelp, Untappd, and SydJS. If you’re looking for more examples, you can check out the showcases for PhoneGap, Ionic, Telerik Platform, and AppGyver. They list applications that cover a wide range of categories, including line-of-business applications, games, and more.
If you’re curious to learn more about hybrid application development, I would encourage you to check out Apache Cordova, build a prototype, and evaluate the results for yourself. I would also recommend checking out Telerik AppBuilder. It offers solutions to many challenges that crop up in the world of mobile application development. It’s an environment that can integrate with many popular IDEs like Visual Studio and Sublime Text, and it has a number of project templates to get you up & running quickly.
The thing to remember about hybrid mobile application development is that it’s not a single approach; rather, it’s a spectrum of options ranging between web and native. Determining if it’s the right choice for you requires evaluating the options presented in this article.
Header image courtesy of Luke Wroblewski