Choosing a Mobile App Platform, Native or Hybrid?

It’s the mobile development debate that has raged since JavaScript wrappers evolved to support hybrid, multi-platform development. As the underlying technology of each option has matured, it’s worth taking another look at which option is right for your application. As always, the unhelpful, short answer is still, “It depends.”

Going Native

The development tools for both Android and iOS have advanced significantly in the last couple years. Android released Android Studio, an official IDE for native Android development which replaced Eclipse as the go to environment. iOS released the SWIFT programming language, largely ousting the cumbersome Objective-C language from the development process.

The maturation of these tools means development time should be less than a few years ago and documentation is much better to help resolve any issues that the developer encounters. It’s also likely that finding qualified developer talent is easier than in the past too, now that the platforms are more accessible.

There is also a user experience benefit to taking the native route if you use the built-in navigation and control elements. Users of both platforms are conditioned to understand native defaults and you have to go out of your way to significantly change or avoid using them. Keeping UX in mind is always valuable, but you get the value of a huge team of experts working for Android or iOS backing up your decisions by choosing the default elements.

The major downside to native development, as it has always been, is if you need to release for multiple platforms, you really have to develop your application twice. This is the major factor that really enables hybrid JavaScript applications to continue to compete in the mobile space.

Take the Hybrid Road

The number of options for creating a hybrid application has multiplied in recent years. With the rise of JavaScript frameworks and the maturation of mobile wrappers, like Cordova, you can make a sleek, native-like application that works on several different platform using one code base…at least hypothetically.

Slogging through the dozens of platform choices to figure out which you should use for your application is a serious chore. The variety of choices is great because you’ll have so much flexibility, but it’s a lot of work to figure out which platform will do what you need without bogging down your app with unnecessary bloat.

The complicating factor is that you have to make several different technology decisions. You need a native wrapper, such as Cordova. You likely need a JavaScript framework, such as Angular or Ember. And you likely want a mobile UI framework, such as Ionic, Sencha Touch, or Trigger.IO.

Each mobile UI framework has different underlying requirements, so you probably want to start there with your research. Some incorporate their own native wrapper or have hard dependencies on Angular and Cordova. Each platform takes a slightly different approach and there is probably more than one right choice.

The competition between the platforms has really driven innovation and developer-friendly tools. However, with the constantly changing “best choice” development stack, finding an expert in developing one particular platform can be difficult.

What’s the Answer?

I hate to hit you with the same unhelpful answer, but it depends.

If you have in-house developers, the cost effective solution is to choose the technology that they’re able to develop or at least support following primary development. If you’re building for just one platform, I think the current answer is to go native. If your application needs a web browser presence, then you should go with a hybrid app. If your situation is more complex than these simple cases, you really have to research each platform and see if it is the right fit for your scope, budget, maintenance, and stability needs.

If you are unsure, let us know.  Our teams of developers can assess your situation, provide best practices and make recommendations for the best solution to meet your needs.