Either Hybrid or Native. Is that the question?

In the very beginning of every mobile app project, we can have to face a tough decision: should I go for a native approach to make the most of the device capabilities and optimize the user experience, or should I prefer a hybrid development to make progress faster even though the result may be not as good. And you have to choose either one or the other.
A few years ago the answer was quite easy: the hybrid technology was not ready yet (actually, ten years ago it didn’t exist).
 
Nowadays, the hybrid approach is mature enough to be considered an actual alternative, specially for enterprise apps. Besides hybrid, we also have a slightly different approach, called cross-platform, which consist of using third-party tools and languages that produce native code.
 
If you need a deeper understanding about native, 
hybrid and cross-platform approaches, you can check 
this webinar where we talk about it.
 
So in these days, the decision “native vs hybrid” is a difficult one: each company, project and team have different needs. You need to know the company, the market, the project goals, the team… the context, after all, to make the best decision.
And when you know your context, you have to consider several factors. I found companies considering the following factors:
  • Know-how: Is my team able to do a native development both for Android and iOS? or maybe I only have access to web developers. In my opinion this is a critical factor.
  • Technical reasons: Is it possible to do the app without native code? Some apps require a tight integration with the device, and they make the most of sensors and device capabilities (camera, GPS, RFID) Others want a perfect UI with super-fluid and advanced animations and transitions.
  • Political/subjective/trend reasons: my competitors are using native, I read Facebook gave up on hybrid, my colleagues/developers say hybrid sucks... you know. 
Also, this decision has three important characteristics that makes it even more dreaded:
  • It’s a binary decision (almost): your app will be native or hybrid, but it can't be both at the same time. If you go for the hybrid path, it’s difficult to add advanced features that use native (Cordova plugins are an alternative, but not perfect). On the other hand, if you go for the native path, it’s tricky to add hybrid (HTML) content: you need to tweek a lot with embedded WebViews.
  • It’s a final decision, you can’t go back: maybe you want to start fast and small, with a simple hybrid development, and that works great. But a few months later, you need to starting implementing new features in native. You’re done because you need to start from scratch. Most of the hybrid projects regret because at some point, the app is technically limited. Also native projects regret because adding simple features can be difficult and slow.
  • It's a initial decision: you need to make the decision up-front. And that's probably the worst moment to decide (you know nothing, John Snow). It's so risky that the manager responsible for that usually asks for advice more than twice (and that's probably the reason why the Internet is full of articles about "hybrid vs native")
In the last year, we’ve been thinking deeply in this problem, and we believe we found a flexible way to approach mobile development without being constrained by that initial & final & binary decision. 
  • What if you don't need to decide once, at the very begining (decision per-app) and you can decide several times during the life of the app (decision per-feature)?
  • What if you can change your decision without starting from scratch if you think you chose wrong?
  • What if you can combine both approaches instead of choosing one or the other?
If you like this new approach, stay tuned. We really believe we found the sweet spot in the “native vs hybrid” dilemma!