We thought that we had the answers, it was the questions we had wrong." - Bono
If the song, "I Still Haven't Found What I'm Looking For" had been written in the last 5 years, I would swear that it was born of Bono trying to write a mobile app.
U2 — Still Haven't Found What I'm Looking For from Adam Fromm on Vimeo.
Let that video play in the background while you read this article. Is it playing? Alright, here we go...
I mean honestly, how stressful have these past five years been? Build native apps! Build hybrid apps! Build web apps! Build responsive apps! The noise around the "right way" to build mobile apps has been nothing short of deafening; and after all this time, we still haven't found what we're looking for.
Is it possible that this whole time we have been asking the wrong question?
Wrong: What Should I Use To Build A Mobile App?
Most conversations about developing mobile apps usually go something like this, "I need to build an app. What should I use to build it?" The mobile disruption was so immediate and jarring that we have all been desperately searching for the answer to that question. There is no shortage of tools, platforms, hacks, strategies, tricks - but there's always a trade off. It seemed that no matter which direction you turned, there would be someone there to tell you about the downfalls of your choice.
"Native? I hope you enjoy writing Objective-C, Java and .NET. Good luck hiring developers and maintaining all that code."
"Hybrid? Hybrid apps are slow and everyone knows it"
"A Mobile Web App? Are you kidding me? What is this, 2010?"
"Responsive? It sounds great, but let me show you all these blog posts where people say it's too hard for apps of any size"
RIGHT: What Should My App Do?
Everyone was so busy with the HOW that we had completely forgotten about the WHAT. We never had to ask the how question before, and now it dominates the conversation to the point where we found ourselves paralyzed, afraid to build an app and pick the wrong technology.
We have lived in fear long enough.
We believe that it's time to start building applications again based on what they should do, and not arbitrary opinions about which technologies are superior. First you should define WHAT your app should do, then you choose an approach for HOW you will build it based on its defined functionality. You know - the way we have been building software since - well - since forever.
So Which Approach Is Right For Me?
It's actually fairly easy to determine whether or not you actually need an installed app, so let's start there.
An "app" is an application, regardless of where it's running. Just because it's on the web doesn't mean that it's not an app. There is a common misconception that if you are building an app, you can't use the web because then it's just a "site". That's a horrible injustice to the most prolific runtime of our generation.
If you don't need device access and aren't worried too much about offline capability and you don't need or want app store visibility, then the mobile web might be perfect for your next app.
You can build apps that are targeted specifically for mobile devices (e.g. m.yourcompany.com), or you can go with the Responsive Web Design approach (RWD). Done right, it will allow you to build an application that will look great on any form factor, no matter the size.
If you are looking for device access, offline capabilities and want to leverage device stack features (like push notifications and app stores), then you will want to build either a native or a hybrid application.
Native apps have scared off a lot of developers and for good reason. A new language, new awkward frameworks and goofy IDEs. It all boils down to change. Change is HARD. Anything in life that involves drastic change can be excruciating. However, sometimes that change is well worth it.
If your mobile application is the primary driving force of your business model (e.g. Instagram, Twitter), it makes sense to invest the time and energy into building a native mobile application. You get unlimited access to device features, offline abilities, app store visibility and everything that these wonderful new mobile platforms have to offer the intrepid developer.
Yes, you will need to write in a different language and for a different framework and in a different goofy IDE for every single platform. Right now that's iOS, Android and Windows Phone at the very least if you want to cover all of your bases. Yes, it will require a lot of time and investment. Yes, the days of getting rich quick in the app store are well gone and over (or ARE THEY?.) However, if your mobile application is this important to your business, it just makes sense to invest heavily in native applications.
Between the polar opposites of Native and Web, sits the wilderness we now know as Hybrid. Hybrid apps (commonly called PhoneGap apps) are written with web technologies, but run inside of an app shell. That means that they install like native apps, enjoy app store visibility, and even look very much like native apps. Done right, it can actually be very very difficult to tell the difference between the two. They also have access to many device features and can get access to even more with plugins.
The hybrid application is the elusive unicorn of mobile development. For many, the hybrid application is the sweet spot between native and web. It bridges the gap. It is, however appealing, not always the right answer.
It is quite difficult to make hybrid apps perform just like native ones. While you can get quite close, and the gap is growing smaller with every new device and every OS upgrade, you will be trading native performance for hybrid efficiency. The reality is though, that while for some types of apps, performance is critical (e.g. games, video processing), for most cases, the performance needs to be “good enough”. While developers have a keen eye, most users do not know or care whether your application is hybrid or fully native. Does your app do what it says it's going to do? That is all that matters. If however, your hybrid application displays a blank white screen indefinitely, expect several 1 star reviews.
Quite possibly the most compelling reason to choose a hybrid approach is that you get to re-use existing skills. Your company quite possibly has several web developers, but there is a much slimmer chance that they have an Objective-C developer. Adding a new platform and different language into the mix of your organization brings with it the burden of maintenance. Remember: if it gets built, it also has to be supported. You can always hire that one mobile developer or outsource the entire project, but it’s the organization who gets saddled with the technical debt.
In the end, one of the hardest decisions you will have to make is whether to go native, or to go hybrid. Either way is fine. Neither contains the "right" answer. The best way to get a good comparison of hybrid to native is to build at least a part of the same app in both technologies.
UI For Any Approach
Once you have decided WHAT your application should do, you can pick the right approach and start building. We designed the Telerik Platform to support your approach, not a specific technology. How on earth can anybody possibly tell you the right way to build your application when they aren’t the one’s who have to build it!?!
That’s why the platform is designed to support web, hybrid and native apps. Building apps on the Telerik Platform enables you to freely choose HOW to build your app based on WHAT it should do. Don’t be bullied into making a decision based on “the right way” to build a mobile application. There is no one “right way”. There is only the way that makes the most sense for you and your project.