When Should You Use Hybrid Apps?
Hybrid apps are a favorite among enterprise clients. You write one codebase and deploy it to two different mobile platforms. That’s a 50% savings on development time. Isn’t that genius? Not exactly.
You have to think through your requirements when choosing your tech stack, and Native vs Hybrid is one of those choices. My short answer is “Anything that’s not a To-Do list should be native.” What I mean by that is anything that has a large amount of memory usage, computation, or user interaction should not be strangled by a proprietary framework before you even click New Project. The usual response I get is “Well Facebook uses React.” In this instance, Facebook is a fancy To-Do list: a table repeating a couple hundred cells, 2 buttons, and a textfield inside. That user experience makes a great deal of sense to write in a hybrid framework. Twitter, Airbnb, most of the biggest name apps fit this description, and it gives product owners comfort in deciding to follow suit.
When you introduce more complicated UI however, it’s a different story. Geolocation technology, where SewnR agreeably calls home, should always be done natively. The SewnR app pinpoints a user’s location and many other characteristics, indexes and plots hundreds of events, then returns back information on what you want to see and learns from it. I couldn’t imagine trying to do that in Cordova. It’s just not possible. Waze, Dark Sky, and Apple Music are all apps that do a great deal of computation and have robust interactions. These are shining examples of what native development is about. Red flags that you can’t cut corners in development are: saving data to a local database, mapping, drawing, and strict security concerns. These immediately indicate native is the correct choice.
Other factors play into your decision as well. Your team’s expertise, for one. A company of C# experts is prudent to look at Xamarin, and web developers would prefer Ionic to Objective-C. These frameworks have become sturdy enough over the years to frame an industry strength app. When companies begin dipping a toe into mobile they stress about which one would be best for them. Once you’ve decided to go hybrid I usually say that you should follow the language that you’re most comfortable with. It’s basically that simple.
Last, you need to be honest about your pipeline and the level of support you’re going to give to your app. If your only goal is not to manage two codebases you probably haven’t thought this project. Xamarin actually requires two projects to deploy to both iOS and Android; and in my experience most Javascript based platforms update more often and need more frequent support than native APIs. “Write it once” is a dangerous phrase that sets the wrong expectation. All apps need updates to stay relevant and functional. If you plan to update your content or user experience often, that also can be difficult and restrictive without native code. No one ever wants to hear “It doesn’t work that way” after requirements go through planning, design, and part of a development cycle.
The biggest mistakes you can make are to follow examples that don’t apply to you, or follow the newest buzzword technology because it’s new. Plain old Java has been around for years but there’s nothing better for controlling cutting edge material design. Step back and envision the entire year of this newborn app’s life before you seal its fate.
* * *
Originally posted at Just Start Up — Sewnr
