It was a wintry night and I was attending a weekend party hosted by my dear friend, who happens to be an entrepreneur. While we were enjoying a gourmet dinner, laughing and making new friends, my friend & host introduced me to a gentleman, who it seems, was contemplating building an app-based business. He was an appreneur in the making.
As I was about to leave, he came to me and asked casually –
“I see you are an app developer with lots of rich experience, would you be willing to become a part of this project?”
As an app developer, I am always looking forward to expand my horizons and work on interesting projects. I was a bit ambiguous, nevertheless, I decided to pay a visit to his office to learn more about his venture.
Long story short –
He had an idea for a travel app, which, according to him would disrupt the industry, change the way we travel & blah blah. There was investor funding to the tune of $200 million and everything you would associate with a well-funded startup. To be honest, I was blown away the moment I stepped in his office. However,
I turned down the project for many reasons, the fundamental being –
I didn’t see a reason for them to invest so heavily in building native apps. Not that I am against native apps. These are still the best way to go for building mobile apps.
But, you see ………
You may ask what’s so wrong with building native apps? We have almost decided to go with it, hired native mobile app developers etc. You can’t just do this?And, that is why my friend this letter is for you, it will help you become more open-minded to the approach of building your next mobile app.
I love you all…basically because you give me the opportunity to know about all the awesome thoughts…ideas…plans that you have. You help me discover technology and myself, both in their better manifestations.
But at the same time, I feel worried. All those great ideas, those great thoughts, have complete probability to run into gutter, if you are not careful enough.
There is a lot of shiny information about app building protocol on the internet. There are a lot of shiny people who would possibly bedazzle your vision to believe that something that comes out good, must bleed you out of your money.
Don’t you believe them!
Sit with me on a journey to simple truth.
By now, you must have scoured across the web and found tons of posts on whether to go for HTML5 or Native for building your next app. There are experts who believe, no matter what, you should go for Native. (They even give examples of biggies like Facebook and Gmail who eschewed HTML5 in favour of Native).
Then there are people who advocate for HTML5 stating that its cost-effective, helps you build apps for multiple platforms by writing a single code base for all.
This should all make it damn easy-peasy for you to decide. Right?
While I was hunting out for some meat, I found an interesting discussion on Y Combinator which said — why native development sucks and HTML5 rocks.
Chirag Mehta, a participant, posted this and it’s bang on —
I’ve done non-trivial projects in both HTML5 (with/without PhoneGap, with/without jQuery Mobile), Native (ObjC, WinMobile), and hybrid mix of HTML5/Native (views in HTML, model/controller in Native). I’ve heard all the pros and cons of both sides but most of them are either non-issues or wrong.
ARGUMENT: Native is ALWAYS faster than HTML5
MY EXPERIENCE: So what? Speed depends on what you’re trying to do and how. Animating a loading icon for UITableView will not spin any faster than a loading.gif in HTML5 view. Similarly, being able to slide an entire UIView to the side at 120fps doesn’t mean using CSS webkit-transform: translate3d(x,y,z) at 60fps looks any worse to the user. Speed matters when you’re (a) crunching data and (b) updating graphics. If you’re building HTML5 apps that need some serious data crunching, you can do that part in C and call from your code via a plugin. And unless you’re making 2.5D-3D games, you don’t HAVE to go native. And then you’re most likely coding in C/Lua anyway. For most of the apps out there, raw processor speed isn’t a necessity — responsive UI is.
ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native
MY EXPERIENCE: Sometimes yes, sometimes no. It depends on your experience with all the available technologies. I can code views in HTML5 using CoffeeScript/Less/Bootstrap/Backbone relatively fast. I can code models/controllers in ObjC relatively fast. Views in ObjC get complicated and models/controllers in CoffeeScript/JS get complicated. If you have a UI-heavy app and you can code UI fast, go with HTML5. If you feel comfortable validating user data input in ObjC and have tons of forms, go with ObjC. There is no silver bullet.
ARGUMENT: HTML5 apps ALWAYS look bad/uncanny vs. Native ALWAYS looks boring
MY EXPERIENCE: Poorly designed apps look bad/uncanny/boring. I have to admit that using jQuery Mobile and similar libraries without doing any customization/tweaking pushes your HTML5 app into the uncanny valley. And unless you skin the Native UI, your app will look no different than the phone’s native contacts list. My preference is to (a) Not use libraries that make fake native-looking-UI when doing HTML5 (b) Adding graphics/skin to native UI to make it standout from boring address-book UITableView lists. Ugly/boring apps are a graphic design problem, not a side-effect of platform choice.
ARGUMENT: HTML5 is ALWAYS easy to port, Native is not
MY EXPERIENCE: Far from the truth. When porting, you’re not just porting to a different software subsystem but also different hardware parameters. Even the best designed HTML5 apps can’t suddenly go from Android phones to iPad or iPhones to Nexus 7. Moreover, if you code the core functionality of your Native apps in C, it makes it quite portable. If you make your HTML5 views fluid/responsive, it makes it quite portable. If you’re relying on special hardware functionality (camera, GPS etc.), it’s a case-by-case issue of what’s portable and what’s not. If you have a data logging CRUD app that accepts user input on HTML5 views, posts to a remote server, and displays results, you might get away with 1-hour port like the author of this article. But more often than not, you have more issues to consider. In-App purchase? Yeah, can’t port that easily. Facebook-integration? Can’t port that easily unless you’re using portable libraries.
Software development is just as complex on mobile devices as it is on servers. Your choice of platform (HTML5 vs Native) really depends on your specific app’s requirements. There is no way you can make Word Lens in HTML5 (today) and there is nothing wrong with going HTML5 if it saves you time and resources in the short and long-term. People need to realize that there are no absolute GOODs or BADs in software development. Pick the best option after you weigh in the cost of design & architecture, development, legacy support, resources, training, deployment, and maintenance.
Disclaimer: I am not against building native apps. The point I am trying to make is blindly following some random advice on the internet can get your app killed. There are situations in which HTML5 is the best way to go, there are circumstances when nothing beats Native and finally there are scenarios when Hybrid can be your best choice.
Let’s say you are an early age startup with no significant funding, you will burn yourself out if you go for native unless one of your co-founders knows how to build a native app.
Or in case you have millions of dollars of funding and resources, please don’t bother wasting your VC’s money on going native when you can actually go for HTML5. This is especially true when you are about to build an MVP, outsource your stuff etc. It can be very enticing to follow that path but resist the temptation, my friend.
If you are building a game, have found a product/market fit and have resources at your disposal, Native App Development is the way to go in your situation. Also, when you are building apps that want a Facebook-like experience, HTML5 might not work for you.
Platforms like Ludei are powering thousands of apps. From indie developers to Fortune 500 companies that are using HTML5, Cocoon is emerging as an option deploy native-like apps and games. Biggies like Nickelodeon and Disney are building games with HTML5.
Josh Morony ( a renowned mobile developer from Australia) aptly very well puts it — The pareto principle or the “80/20” rule, applies to HTML5 app development. He states that with HTML5 you can create an app that feels and performs about 80% as well as a well designed native app. If you want, or the clients wants, that last 20% — the beautifully smooth and magical experience — it’s probably going to cost 80% more.
What if you want to monetize your app, you would ask me?
From the development point of view, if you don’t have much time and cost to invest, HTML5 is your best bet. However, I would vouch for Native here, because you can’t put the User Experience at stake because your focus is monetization. To go a bit further, I would only release an iOS app because of the audience it has. Android users are like — I want everything for free. So, only iOS native app here.
What if you need to build an enterprise level app?
HTML5 is the obvious choice when you are building an app for an enterprise, mainly, because of the following two reasons:
- Your developers can update an app more easily than native apps and it can work seamlessly across iOS, Android and other mobile operating systems.
- It will reduce your time and cost.
- When you replace an old legacy windows app with HTML5, you can build apps using responsive techniques that work across desktop and mobile.
- HTML5 is now loaded with new capabilities like allowing an app to run in the offline mode when there’s no internet connection. Faster speeds, improved user interfaces, features that allow you to build sophisticated applications etc. also work in favour of HTML5.
However, this does not mean enterprises are not using Native. There are situations in which Native apps are the best choice. Consider this.
HTML5 does have its disadvantages
Having worked on HTML5 applications, I would stress on the fact that user experience does take a back seat when compared to native apps. Though native apps take time to build and are bit expensive, you have a lot of freedom with them (For instance, from native, it’s relatively easier to build up HTML5 stuffs on top of it. So you can still utilize HTML5 stuff if a need arises. The reverse is almost impossible.)
and when it comes to solving bugs, native apps win the game hands down. If not built properly, HTML5 apps can have sluggish performance and load slowly, ultimately impacting UX.
When you need a flexible solution, cross platform app with little budget in place, HTML5 is the best option out there for you. But, for other things, Native gets my vote.
For instance, using HTML5 to access camera on iOS is very much possiblebut not without some bugs. And, that is why you have to spend an insane amount of time fixing bugs for HTML5 apps.
But..you must take your steps carefully with Native too…
Besides being time-consuming and expensive, Native apps are turning out to be a gamble for many of us. Because, the cost of acquiring a user on both iOS and Android are moving northwards. And, if you don’t quickly acquire users and start breaking even, your app is doomed for sure. Understand that in these situations, there is no fault with a mobile app.
Consider the Circa news app. It shut down last year shocking the media industry and journalists because it was a damn good app.
So, what was the problem? Being a native app, UX was phenomenal? Then, what caused its death?
Looking at history, it seems we have an answer. Native News Apps are up for failure. There’s a similar trend across iOS and Android. People don’t like them. And, hence it might make sense for you have an HTML5 app here without investing much in native. For instance, Guardian news has a HTML5 app that almost behaves like Native.
The bottom line is as an appreneur, you must and should invest time in scouring the history and see what type of approach works best for certain genre of apps.
When it comes to native apps, you find 1 in 20 native app developers who truly understands how to architect an app for success. The problem is there are way to many native developers who presume they know their stuff — which — causes failure. And, this applies to HTML5 as well. Because the costs of a bad investment can run high. You got to proceed with caution, dear friend.
Then, are native apps on the verge on extinction?
Certainly not. Like I said previously, you got to be cautious and make calculate moves. Native apps are the best options if you understand your market, have resources to pump in the money & time. Nothing beats native. Period.
For instance, I routinely get asked, I don’t want to compromise on UX but I don’t have big budget and resources.
What should I do?
I say, you could explore the Hybrid option.
These are HTML5 apps wrapped inside of a native container and provide access to native platform features. Cordova and PhoneGap are prime examples. But, I did stay away from PhoneGap. You could explore Titanium and Xamarin.
When does Hybrid become a good option? When you are building a MVP or prototype, this makes sense because you can save money and mitigate risk while not entirely but to some extent.
Then, what’s the future you did ask?
For those who don’t wish to go into untested waters, PWA are the best option. Learn more about PWA here –
While, those who still want to do Native, the latter are good options. Airbnb has around 10%-20% of their app is based on ReactNative.
You also have the option to use the Ionic framework . If there’s a side project you are considering kick-starting, it might be an option worth exploring. Pure HTML5 AngularJS apps compiled with Cordova into native android and iOS applications.
And, so my friend the next time when you have an app idea, you don’t need to blindly follow what everybody else is doing. Take a step back and see what’s appropriate for the long run.
“Is this the right approach? Are we missing out on something here? Can we do something different?”
It’s easy to do what others are doing but it takes courage and wisdom to differ because your app idea is great and it should see the light of the day.
Love & Wisdom,