Web Developers, Don’t Be Lazy And Learn A Native Mobile Language

There's an old Chinese proverb: "A man who says it cannot be done should not interrupt the man who is doing it."<p>That's the feeling I get from opinion pieces like this. I've developed web-based user interfaces for several projects in recent years, some of them with a strong mobile focus. I'm still waiting for all these demons to come and bite us, where our paying customers don't find the experience satisfactory and run away to the competitors who are going to beat us by having a highly polished native app instead.<p>Sure, there are occasional irritations with mobile browsers. Many of them, perhaps even the majority I've come across, are actually by design because Apple actively chose not to make their browser work like everyone else's... again. But do we spend as much effort getting our web apps to run effectively across all the major platforms (including Windows) as we'd have to spend writing a native UI on every platform we want to support? Not even close.<p>And native apps still have the same horrible downsides as ever: the app store approval lottery, Apple wanting a huge cut of any money you make, yada yada.<p>If I were running Facebook, where for practical purposes the budget and developer time required to develop a mobile app on every platform were negligible, sure, maybe it's worth it for a more polished experience. (Maybe.) But for more modest projects, where resources are finite and we don't magically have developers on tap who speak a different "native" language for each platform, I can spend the time and money once to build the web app and then the same again refining it or I can spend the time and money twice just to get the basics done without any polish. I don't understand how anyone who has actually done this can be in any doubt about which gets better results.

It's not laziness, it's an economic decision. Learning a development environment like iOS or Android takes quite a bit of time and effort (especially if it's not your day job). If you believe that by the time you become proficient, HTML-5 will have improved enough to significantly decrease the demand for native apps, then you should spend your time learning something more valuable.<p>Also, lots of people have already learned native app development, and it's increasingly becoming a commodity skill that, at least for simple apps, can be outsourced to the lowest bidder. Developers might believe that learning skills that are not as easily outsourced, such as data analysis, might be a better investment.<p>Finally, learning a fast-changing environment like mobile apps is a much bigger investment than just learning a mobile language. It's a large, ongoing effort to stay current with the new features in every new release of the platform. So please let's not call people lazy just because they're not jumping on our favorite bandwagon.

Not doing native development isn't about laziness. It's about freedom and flexibility. As much as is possible, you should strive to minimize your dependence on any single company (at least until you have some clout), and having a code base that is locked to a closed platform breaks that principle.<p>And look, what I'm saying here isn't ideologically motivated. It comes from hard experience. If I had a dollar for every time I sat on a blanket with two corners held by a single company, and then got that blanket yanked out from under me, well... I'd have three dollars.

"Native technology allows for excellent apps, whereas HTML5 apps will be at best just OK"<p>Sometimes "just OK" is what people want, and what meets the needs of the business.<p>The truth is -- building a mobile web app can be fast and can fill an iPhone/Android/Blackberry/Windows phone with the content and interactivity the business and users need and want. It can also be much cheaper. Different businesses have different values, and whatever works best to achieve those values is best.<p>Calling devs lazy for not learning native mobile languages seems like a cheap way to get clicks. New Year's Resolution: Stop clicking on them.

It's lazy to give up and devote all your energies on yet another company's proprietary platform. Instead of constantly writing articles like this, how about we focus on the obstacles web apps face, and fix them.<p>Sure, if both a web app and native app are programmed optimally, the native app will run slightly faster. But a program written in machine code will always be faster still. There will come a point when the speed disadvantage is outweighed by all the benefits of web apps - and that time is near.<p>The biggest issues with web apps are:<p>- <i>Development.</i> Creating web apps requires writing code in at least 3 different languages, including server code, client code, and markup code. Try making an iOS paint app that saves your drawing to the cloud. Then try doing it as a web app. If you think this is easy, believe me, Objective C is a <i>drrreeeam.</i><p>- <i>Discovery.</i> The App Store/Google Play are the best ways to discover new apps. There exists no such popular and lively platform for web app discovery, review, and sales.<p>- <i>Browser and OS Dependency.</i> Mobile browsers don't all allow access to the camera, easy installation to the home screen, and all the access to APIs a full-featured app should have.<p>So let us be constructive from now on, and focus on fixing these issues, instead of giving up and locking ourselves into reliance on yet another company (Flash, iOS, Android, etc).

Some of the impetus towards cross platform HTML5 development was probably because the state of Android app design in the 2.x era was so bad. You could basically get away with using an iOS-look-alike web toolkit on Android in a WebView, and it was "good enough".<p>With Ice Cream Sandwich, the new Holo look and feel actually has a real design language that is markedly different from an iOS app.<p>As to Windows Phone - there is such a strong design for Windows Phone apps that those jQuery Mobile apps in their app store look really out of place. Microsoft's working on some CSS that will make jQuery Mobile apps look more native, but it's still missing some of the key Windows Phone UI like panorama.<p>From developing HTML5 and native mobile apps for iOS and Android, and from follow ups on some mobile application strategy consults, HTML5 mobile apps just don't deliver a good user experience, especially if the app does anything other than content consumption.

Mobile OS developers, don't be lazy and give me a way of embedding HTML5 into an app that doesn't completely ruin the whole experience.<p>Seriously, a web app will be running beautifully in Mobile Safari, but when I put the same code into a WebView, it all goes to shit.

Is there a good reason not to believe that mobile will eventually swing to HTML, for the same reasons that desktop apps yielded to web apps?

One of the obvious reasons some teams may not go for native is that they don't have the resources to commit to maintaining two applications.<p>Having 2 teams, contracting an external agency or finding a developer versed in both platforms are all pricey options. If your product is not the mobile apps themselves (obviously), HTML5 or Titanium can get you there without stretching your resources.

I tend to agree. Even a properly optimized, Simonized and Vulcanized app needs to be run through a browser layer, which inherently slows things down. Javascript bridges to native functionality are messy and can fail. And for what? Writing one code base? How much client-side logic are you really doing that you don't want to replicate?<p>Any mobile app I write that requires server logic is basically just a view, so it needs to accept and manipulate JSON. Interface Builder gets you an interface in minutes (of course, you can spend time tweaking it), and there are dozens of networking libraries that consume a service and spit out native objects (if that's your thing). At the risk of speaking in absolutes, you will never get a better experience than a native, first-class one. Ask Facebook - it didn't work out so well for them.

Vishal Gurbuxani gave us the marketing perspective on this last month in Napa: <a href="http://www.slideshare.net/vgurbuxani/app-retreat-2012" rel="nofollow">http://www.slideshare.net/vgurbuxani/app-retreat-2012</a><p>One major problem: HTML5 is fragmented across platforms and is missing important ingredients needed by app businesses. In the end, it's just another platform, and not a very good one if a good user experience is something that you hope to deliver.<p>Read Vishal's slides for more, or come ask him about them at his session at Renaissance: <a href="http://renaissance.io/speakers/vishal_gurbuxani" rel="nofollow">http://renaissance.io/speakers/vishal_gurbuxani</a>

What about Ruby Motion for iOS? Its commercial ($200 a license) but offers native objective-c compiled from ruby and is based on the open source mac ruby project.<p>This seems smart as you only have to learn the cocoa framework and you learn a little bit of objective-c. Whats nice if you want to go native and or optimize by writing straight objective-c you are halfway there.<p>Everything else I have looked at is basically a web browser attempting to be a full app.<p>I would love to hear if anyone has written an iOS app that is on the app store with it and what there experience has been.

This reminds me when (Adobe) Flash evangelists were requesting us to join their "better experience" ecosystem... (10 years ago?)

Mobile OS developers, don’t be lazy, give me a half decent language that doesn't make my eyes bleed.

I think this argument, ad hominem aside, loses a bit of validity with every subsequent smartphone/tablet generation. Every advance in CPUs and JavaScript interpreters blurs the line more if we're looking at a hybrid app developed by a competent team.<p>As to where I'm coming from in this argument, yes, I currently develop mobile apps using web technologies. [1]<p>And yes, I completely agree that the majority of web view/hybrid apps I've encountered have had poor user experiences. But the field of hybrid apps is new and everyone can recall the poor user experiences of desktop web apps in their nascent era.<p>As with the age of MapQuest, the sample size of hybrid apps is still small and thus well-designed and well-coded apps are scarce. Aesthetics give probably the biggest impression of mobile software quality, and you can either choose to stick to stock SDK UI, or implement your own visual language. The former is safe and is the default for native development. Hybrid apps almost always fail when trying to mimic it completely and users are (at least subconsciously) repelled by the uncanny valley these apps may land in. The latter option of introducing a unique UI is exceedingly difficult to pull off, hybrid or native, but is a route of convenience for hybrid developers, but again, they usually fail to create something a user can feel comfortable with.<p>In short, if you're serious about your app's reception, it is more difficult to pull off the user experience using web technologies, contrary to the article's assertion. Hybrid app developers cannot rely on native UI elements and this is why they tend to be received so poorly.<p>So why have I chosen the hybrid approach? Mainly because I'm a futurist and I see the immense value in having an open lingua franca for app development over fractured proprietary environments. The cross platform benefits appeal to me less, and at the time of this writing, I consider iOS to be ahead of the other platforms in fidelity of rendering web content (Android 4 is catching up). I fully admit this benefit is half-baked at the moment, but I don't need any pundit predictions to know it will improve by bounds in the next few years.<p>JS isn't a silver bullet, but it's undeniably exploding at the moment, especially in terms of flexibility (browser, server, mobile). You could invest your time in mastering a proprietary platform's SDK, but besides only focusing on non-portable knowledge, you could also find yourself with a dying marketshare for your chosen platform. I definitely don't mean to discredit native languages by any means, I just want to convey how I came to conclude that hybrid is a safe investment in mastering. Many apps, whether simple CRUD apps, or thin front ends for REST APIs, have no specific need for native code. Even Microsoft --seen among the symbols of proprietary control -- are embracing the HTML5 stack for apps. The benefit of being able to reuse the libraries and APIs [2] when bringing an app to another platform shouldn't be underestimated, nor the potential growth of mobile-oriented common knowledge in a common language.<p>Is it really difficult to believe that in a few years phones will be running WebGL-powered 3D games with advanced shader effects, on par with native games? Not really, considering how rapidly we're approaching that point on the desktop. It's even easier when you consider the hybrid app bottleneck is usually DOM painting, not JS execution, and WebGL would potentially use the mobile device's GPU. This problem is almost solved already with intelligent DOM manipulation and CSS3 transforms, (or potentially other approaches [3]).<p>Writing a quality hybrid app at the moment is very hard. Web views have less memory available, execution is slower, and simple DOM rendering is expensive and slow unless all optimized properly. Furthermore, aesthetics are harder to pull off when working outside SDK UI sets. But hybrid apps are a relatively new field and have enormous potential. I don't it's very mature yet, but neither was the web itself for a very long time. I think having a common, open set of tools is worth defending from accusations like this one or the red herrings thrown around regarding HTML5's role in the Facebook app. This is definitely the more forward-thinking bet.<p>[1] - <a href="http://chaincalapp.com" rel="nofollow">http://chaincalapp.com</a><p>[2] - specifically HTML5 device APIs as well as <a href="http://phonegap.com" rel="nofollow">http://phonegap.com</a><p>[3] - <a href="http://famo.us" rel="nofollow">http://famo.us</a>