Go TRUE Native for Mobile App Development

Update: Drew Crawford did a great analysis of why Javascript can NEVER be as good as native code.

The Promise of HTML5

HTML5 promises to reduce time to market by allowing web developers to quickly build a mobile application using the tools they already know while leveraging existing code (usually a mobile-web app already in existence). It also allows developers to build an application once, and deploy it on tens of platforms: iOS, Android, Blackberry, you name it.

By being able to build applications once and run them everywhere, companies expect to reduce cost and iterate at a faster pace to save time. Since there are so many more HTML5 and javascript developers out there, it’s easier to quickly build or hire a stellar development team.

With native development on the other hand, there is little shared code between platforms such as iOS and Android, and one often needs to shun smaller platforms such as Blackberry or Windows 7 because of high costs associated with per-platform development. Since the applications are developed independently, their development and release timelines will never line-up properly, and one never wants to release features solely to a single platform.

It would seem like HTML5 would be the way to go for easy, cheap, and fast app development.

The reality

While great in theory, just like any web development, with HTML5 apps, things never go as planned. When building HTML5 mobile apps, the application is rendered using the device’s web browser. The application is therefore subject to all the weird quirks associated with the web browsers of the various devices it’s deployed on.

All web developers can tell you how many hours they spend while building a website implementing various frameworks and Javascript libraries in order to achieve the desired functionality and effects. For HTML5 mobile applications, these same problems come in to play.

There are many mobile development platforms that offer HTML5 mobile application platforms. Some such as Appcelerator and PhoneGap even claim that they create “Native” apps. All these platforms tout their strengths in allowing the quick development and deployment of mobile applications. Yes they allow you to quickly build and deploy a mobile application, but boy will you be disappointed with your final app.

Remember back in the 90s when people were building websites with Yahoo! GeoCities and Dreamweaver (when it was still a Macromedia product)? These websites websites could get pretty advanced, but they could never breakout of the template format used for development. This exact problems plagues all HTML5 based mobile application platforms – there’s only so much you can customize.

To build a proper application that doesn’t fall into a small pre-defined category, you need to do it yourself. You’ll need stellar HTML5 and CSS developers with experience building mobile applications. Don’t forget those expert Javascript developers you’ll need. Javascript in mobile applications is a different beast to tame than in traditional websites.

Getting the experience right using HTML5 on a mobile device takes hundreds of iterations, most are wasted getting functionality and speed to match truly native. After all this hard work and energy, you’re finally deep in the development of an HTML5 mobile app. When you begin hard testing the app, you’ll notice you’re always finding small glitches and weirdness at times, and the slow performance is instantly noticed by users. You don’t get the WOW you were hoping for from your users – they’re never fully satisfied.

The hybrid approach

During the development process (maybe even after one or two release), you realize that some of the functionality you need isn’t possible using HTML5/Javascript. When this hit most developers, they created the Hybrid App approach: combine HTML5 with Native wrappers when needed for some functionality. To continue developing your app, you hire iOS and Java developers to build the native functionality for your mobile app.

Lets take a quick headcount. You’re now using the following resources for your application: HTML/CSS developer, Javascript developer, iOS developer, and Android developer. You’re no longer supporting every device/platform such as Windows 7 or Blackberry because it’s too expensive to add two more developers to your team (for simplicity lets assume you’re only using one developer per platform which is rarely the case). You quickly find that there’s hundreds of small bugs and glitches pissing off your users. They don’t know or care about the differences in development between your app and Apple’s native applications… all they care about is that your app isn’t as good. Meanwhile, your HTML/CSS and Javascript developers are about to pull their hair out trying to these issues throughout the app. Every time they finally think it’s perfect, something new pops up on another platform.

Remember Appcelerator and PhoneGap we mentioned above? Well they’re application platform builds apps that fall into this hybrid category. They leverage some native code for things like cool effects/transitions, hardware access (camera, compass, etc.), and push notifications. They’re part of the problem. By claiming they build native applications when in fact they don’t, they confuse people into believing their apps will run as smoothly as native apps such as Path or Tweetbot.

Lets not forget the devices your users will be running these apps on… You may be testing your hybrid or HTML5 app on the brand new top-of-the-line phones and be satisfied by how slick your app works. But many of your users bought free or cheap Android phones with sub-par processors and you would be horrified with how your apps run on these phones. See for yourself: go to your local wireless carrier and buy their cheapest subsidized phone. Install your app and see how it runs. My bet – it’ll crash within minutes…

If you’re already investing in native iOS and Java developers, why not go the distance and develop true native applications?

True native

At raw engineering, we believe true native is the best way to approach mobile development. As Tedd Fox of Salesforce says, HTML5 is a great way to “get your product in the mobile door [but] [i]t is not and should never be your real product strategy!” By developing natively in Objective C and Java, you can achieve all the cool UI functionality without spending weeks optimizing your code. You can develop the functionality yourself or use a bunch of awesome open source components (we’ve open sourced Twitter’s StackScrollView and Scroller on GitHub).

The development process is simplified significantly when you’re working in a native only environment. If you’re developing for iOS, you only have one developer tool to use and support. There are also automate unit testing abilities for iOS and Android to ensure that your apps are working flawlessly.

The Facebook Fiasco

Facebook had a fantastic native application. Unfortunately, they got sold on the promise of HTML to quickly develop and iterate hybrid applications with significant cross-platform code sharing. When Facebook switched to building hybrid applications, the biggest issue was speed. You remember that first time you launched Facebook on your iPhone or Android and suddenly, you had to wait… even when you were on WiFi.

This was the day I stopped liking the Facebook application. Waiting for my content is one thing, but waiting for my content to render is a completely different story. By making this change, Facebook pissed off millions of its users off. Since then, Facebook spend a billion dollars on Instagram to get mobile users and has returned to its native roots.

Conclusion

The promise of low cost and available resources for HTML5 is forcing people to make the wrong decision in the short term that would impact their long term success. Today, HTML5 is not the right solution, but maybe in a couple years HTML5 and mobile devices will catch up to native performance and usability. Go native and you will achieve the functionality you are looking for with lot less iterations and headaches and most importantly, a satisfied user base.

At raw engineering, we’ve built several apps using all the approaches above and we strongly recommend going pure native. I just don’t see any cost savings for the HTML5 approach. Even if someone argues that you get 10% – 20% saving, is it really worth it for an inferior application?

Check out this awesome infographic to help put things in perspective:

Image Source

3 thoughts on “Go TRUE Native for Mobile App Development

  1. medical school statement of purpose consulting on said:

    I’m truly enjoying the design and layout of your blog. It’s a very easy on the eyes which makes it much more pleasant for me to come
    here and visit more often. Did you hire out a developer to create your theme?

    Superb work!

Leave a Reply

*

*