WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
By John Bristowe, Principal Developer Advocate, Progress.
Hybrid mobile apps are like any other apps on your phone; you can find them in app stores, and you can use them to play games, engage your friends through social media, take photos, track your health, and much more.
Although many similarities can be drawn, it can be very difficult to tell how a mobile application is built; trying to determine whether a mobile application is hybrid or native is like trying to differentiate rare grape varieties of wine. However, what matters is that the wine tastes good. A well-written hybrid app shouldn't look or behave any differently than its native equivalent, and users don't care which way the app is built, as long as it works just as well.
With all that said, many developers are left wondering about the benefits of going hybrid in today's app-crazed world.
How Hybrid Mobile Apps Are Built
Motivations to Go Hybrid
Hybrid mobile applications provide a way for developers to re-use their existing Web development skills. Generally, developers don't like the prospect of getting locked into proprietary platforms. This includes the programming languages and SDKs provided by platform vendors.
Although it's true that hybrid mobile application development enables developers to target more than one platform, 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 certain platforms that a developer wants to target. In those instances, a combination of plug-ins and platform-specific code must be utilized to take advantage of those capabilities. Alternatively, developers can take advantage of third-party Web runtimes such as Crosswalk that can be embedded in your hybrid app.
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. To elaborate on this, let's examine some questions worth asking yourself before embarking upon development of a mobile application:
Which Mobile Platforms Do You Want to Target?
If you want 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 also lends itself well to this approach 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, 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#.
Where Will Your App Be Distributed?
If you prefer to distribute your application via an app store, you must build a hybrid or native application. You cannot distribute Web sites 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 Web site available for your mobile application. This will be the first place your users will expect to go if/when they encounter problems.
Are You Looking to Utilize the Capabilities of the Mobile Device?
Web sites have a restricted set of abilities as opposed to hybrid and native applications. These restrictions are enforced by the 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 alternatives. 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 sluggish. For that reason, developers have long-argued against using hybrid 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. For developers building more traditional, line-of-business applications, there are frameworks such as Famo.us.
What Are the Technical Abilities of Your Development Team?
Even though there are many situations where building hybrid mobile apps is a perfect solution, it's imperative to recognize that hybrid isn't the be-all, end-all approach to mobile application development. If you find yourself developing an app that needs numerous native features, or an app where performance is critical to its success, you may find the hybrid development model limiting.
The important 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 fit for you requires evaluating the options and asking the right questions.
About the Author
|John Bristowe (@JohnBristowe) is a Principal Developer Advocate with Progress and lives in Australia. John is also an experienced speaker and frequently presents at developer conferences and events. Prior to joining Telerik, he was a Senior Developer Evangelist with Microsoft. You can find out more about John here.|