FIghting the 'native vs html5' mobile app battle
I am an iOS (native) developer and have been since the App Store came out. Since then, I’ve learned a bit of Windows-Phone and Android as well. I have been noticing the inevitable trend towards the building of HTML5 web-apps over native, and it seems to be growing faster than I expected. This frustrates me as a native developer, since there are so many arguments for going native most of the time, and only a few for going HTML5 (i.e. it’s cross-platform!), but those few latter arguments seem to be trumping the former more and more these days, for sometimes reasons that are not valid.
I am not buying the idea that the “future” of mobile apps is in HTML5 and with tools like PhoneGap, which enable mass distribution across the platforms. The experience with web-apps will always be sub-par compared with a native app, and on top of that, a lot of myths tend to be floating around about it. For instance, “Clients won’t pay for native development on multiple platforms; it’s too expensive!” That’s a myth, if many clients truly know the difference in quality of apps they are getting, they WILL pay for it. This is proven time and time again by the industry leaders, who for the most part, are not building web-apps for clients. I even know of a near lawsuit that took place when a CEO got ahold of an app they had outsourced, and it was a PhoneGap/HTML5 application. He was (rightfully) infuriated at the company that promised “an app” and wanted to know why it didn’t feel or respond like his other apps, thereby resulting in a mess.
My biggest frustration is that now it seems some development shops are sometimes even recommending the PhoneGap/HTML5 approach to clients with the allure about it being cross-platform, etc, without even really explaining to the client (who can sometimes be clueless) about what it actually entails with regards to a difference in performance and look/feel.
I definitely want to keep up with the times and prepare for the worst, which is why I’m branching out to learn these tools, but I am just curious as to how you guys (fellow native developers) are handling this kind of thing? Am I alone in my thinking on this? Any advice for how to explain to people in a rational way how to make this decision process?
Before I get replies about this, please note that I completely understand there are times in which the web-app route is the right way to go, and I fully understand there are some clients who simply won’t pay for native, so that is fine. I also understand that predictions indicate the percentage of HTML5 apps will continue to rise as the years progress.. However, I just simply don’t agree with the growing mentality that “all apps should be HTML5, and we just use the native pieces when the need arises (i.e. camera, etc).” My personal opinion is that it should be the other way around: “All apps should be native, unless particular pieces of UI and functionality are easier/quicker to do in HTML5”. Companies can find native developers who code quickly and have access to libraries of code to make native development just as fast, if not much faster than doing it via a web-app.
Thoughts? I apologize in advance if this is the wrong forum for this kind of thing, but I’m eager to get opinions and advice. Thanks!
4 Solutions collect form web for “FIghting the 'native vs html5' mobile app battle”
Here is the simple case for going with Native vs. HTML5. Technically speaking there is nothing preventing a browser based solution from becoming just as powerful as a native based solution, but its NEVER going to happen and here’s why: The venders invovled: Apple, Google, and Microsoft have no incentive to make this happen. Think about it. If they completely standardized it there would be little or no advantage to their platforms. Lets take messaging as an example. Could you have the best Apple or Android messaging services delivered via HTML5? of course you could, but why would a platform vender take this route? Why would they devalue iOS SDK or Android SDK? So this is really the like the browser wars only played out in the mobile space. When the browser wars began everyone thought the uber-browser would emerge, but it never emerged, and it won’t this time either for the same reason. So really its not just a technical issue as its described, open vs. closed. Its the fact that venders will not provide their latest and greatest in an open way. This is one of the reasons that most cross platforms solutions are a step behind the vendor releases.
Another example of this would be support for WebGL. Support for WebGL has taken far longer than it should. Once there is something better than WebGl, it will be offered in native first and then WebGL will finally be fully supported in all the browsers, on every majore device. But the support will always lag behind the native. The point is browser based will always be one step behind because thats the way the venders like it.
Security is another important issue to consider, how many secure apps are using HTML5? I bet most apps that do secure transactions are native, and for good reason.
It would be useful if people could provide examples of features that are recently released in Android or iOS and the level of support for those features provided by PhoneGap and what is the roadmap of PhoneGAP in supporting these sdk features. In other words when a new version of the SDK’s come out, PhoneGAP is not in lock step, and neither is Titanium. However PhoneGap is in my opinion the main competition to the native solution, and therefore its comparison to native will be the most meaningful. I think comparing native to a proprietary SDK that is cross-platform is a waste of time. This is never going to be attractive enough to give either PhoneGAP or Native a run for the money.
A word of caution for those thrilled with PhoneGap however. The built in plugins might exist on all the platforms you need, but what if you need to write your own plugin for PhoneGap? (You are about to learn the real story behind the GAP in PhoneGAP) Either because you want to do something entirely different than an existing plugin or because you want to customize an existing plugin. This is not a write once deploy everywhere scenario. You need to write a custom plugin for each and every platform you want that feature on. In other words you are back to native again. So you better take the time to evaluate the plugins carefully (on all the platforms you are going to run the HTML5 app on), and make sure that they are now and in the future what you are going to need. On the other hand HTML5 without PhoneGAP is quite precarious, and limited and you will find your self rewriting PhoneGAP before long.
Another point is that an app can really interacts in several ways, only one of which is with HTTP. It also often needs to interact in optimal ways with the operating system and resources on the device. Not too mention the user who really does not care about what underlying technology is used but has high expectations based on interacting with a lot of native apps.
When you run an HTML5 application you are essentially running your app within another application, namely the browser. The browser app is only as powerful as the platform vender allows it to be. And if history is any guide, it will evolve, and more features will be added, but never optimally,never in sync with all the other venders, and never at the same pace as the underlying OS and SDK for both technical and business reasons.
Users want the best experience, and it should be noted that while you have many people who own Androids, and many who own iPhones and iPads there are relatively few who own both at the same time. In other words an Android user could care less the iOS version of your app, and an iOS user could care less about your Android app. But the user really cares about how the app runs on their platform of choice. They don’t want something that runs half as well on both platforms because they never see it on both platforms. The user almost always experiences the app on a single platform at a time.
As far as positioning the native solution vs. HTML5 I think its about making the decision makers recognize that its not just native developers that like native, its also the platform vendors that like native solutions, and that means better, higher quality apps made in sync with OS improvements.
In turn this means happy app users with a better mobile experience.
I think I can understand you in some way. I developed native Android Applications for some time and we had a lot of discussion about cross platform development in our company.
In my experience many mobile cross-platform solutions like Phonegap, Appcelerator or Adobe Air fail if you want to build some serious applications. Maybe these solutions will get better in the future.
At the moment I recommend the following for developing mobile applications:
- Very simple Apps (just a few views), nothing special: Go for Phonegap. Simple Apps work fine with phonegap and you have a “cross-platform” solution.
- Everything that is a bit more complex (a lot of server communication, synchronization, etc.): Go for Native. In this case the APIs/performance/debugging tools of native applications often are a bigger benefit than then “cross-platform argument”.
Mobile Websites are a bit different. In many cases there is already a “normal” website that just needs to be cleaned up and optimized for mobile devices. In this case you can use existing code/interfaces which can save a lot of time.
This is analogous to the question of “which one programming language will be victorious in the future?”, or (sotto voce) vi vs emacs. There’s more than one way to make an app. Native has its advantages, and so does HTML5, depending on the problem and the developer’s skill set. I recommend you familiarize yourself with both workflows, which will better qualify you to make a recommendation in the future, as well as accept someone else’s opinion as feasible.
A couple of important other issues. Will there ever be a great metaprogramming way? Like Titanium or the initial idea behind Java. Also, there are things that are better implemented natively such as maps. Also, the increase in cpu, memory makes some of the arguments in favor of native less relevant.