Tara Calihman - December 03, 2014
“Please deliver a plain vanilla hybrid app to me so you can save company resources” said no customer, ever.
Another advantage of hybrid apps is that a company with limited resources, say a bevy of web developers but no mobile developers, can (in theory) bring a mobile app to market more quickly. Rather than get up to speed on iOS and Android native development tools, you can jump right in without knowing too much about each platform.
The lure of “write once, run anywhere” is a strong message that resonates with managers and bean counters everywhere!
(Did you notice customers were excluded from that group of fans?)
The disadvantage of a hybrid app is that you are restricted to a “least common denominator” approach. Features that only exist on one platform are either left out entirely from the cross-platform framework, or require a fair amount of native “glue code” to implement. At best, the latest bells and whistles offered by Apple and Google won’t find their way into the hybrid framework for several months. Thus, when resources are limited, the latest platform features usually fall by the wayside. The result is a generic app that doesn’t look or feel quite right on any mobile platform, and certainly doesn’t offer advanced platform-specific features.
The choice between developing a native mobile app and a hybrid app comes down to whether you want to be customer-focused, or company-focused. It’s that simple. Sure, resources may be limited and you have to do what you have to do, but in the long run, there is no better customer experience than a fully native mobile app with all the latest features available for your platform of choice.
What did VictorOps do? When the company was founded, we knew that mobile apps would be key to our success so we chose native app development, of course. We looked for a sharp iPhone developer and a sharp Android developer, and set out to create the very best app we could for each platform. We like to think that each one looks and feels like a native app, without any compromises. This strategy allows us to bring new features to market right away when Apple and Google release new features for the platform.
As an example, iOS 8 was a major new operating system release with over 4000 new developer API calls to sink our teeth into. As soon as iOS 8 was released to the public, our iPhone app sported two features that were not possible before: the ability to Ack and Resolve an incident directly from the push notification (without launching the app or even unlocking the Lock Screen), and a Today Screen widget so you can see, at a glance, when you are on-call next. These types of features may take months to find their way into various cross-platform frameworks, and if they do, will require platform-specific coding which reduces the cross-platform time-saving, code-sharing advantages.
Note: just a couple months since the release of iOS 8, over 90% of our active customers are using iOS 8. Do you think they want to wait for iOS 8 features to be released?!?
Companies that choose the hybrid approach often find that the expected time savings is not as great as hoped for. You still have to get up to speed on the cross-platform framework and the required glue code for each platform, and you almost always end up with significant amounts of custom code to deal with the “quirks” on each platform or to attempt to extend the capability of the framework. If a bug is discovered in the framework, well now you have to wait for it to be fixed by the third party developer or open source community – once you spend the time to figure out it’s not “your” bug. And what if that third party tool is discontinued?!? Don’t even think about that!
With fully native apps, you have no restrictions except the brilliance of your engineers and the mobile device platform itself. You can take advantage of new APIs and features immediately. The bugs you find are your own, and the schedule to fix bugs and add features is in your control.
Let’s face it: customers don’t care if your app shares code with a platform they don’t even use. Customers don’t care if you saved many man-hours in developing your app. Customers don’t care if you saved development dollars. Customers care about quality and performance. Customers want the latest and greatest platform features that will increase their productivity. Customers want fully native apps!