Apps vs Web Apps

Apps or Web Apps…now that is the question!

Without a doubt, mobile apps are a hot area in today’s delivery of computer programs.  The top three mobile platforms combined offer more than half-a-million downloadable applications.  It seems as if overnight what used to marketed as “visit us on the web at” has morphed into “visit us on Facebook”, “follow us on Twitter”, and now “download our iPhone App.”

This trend is growing as more and more individuals are switching from basic mobile phones to web enabled smartphones running fully functional Internet browsers.  These devices are as much mobile computer as they are mobile communicator.

When entering the mobile application arena, often there is a development decision fork that must be chosen.  Unless you have unlimited resources to fund both web applications as well as native os apps (on multiple platforms), you must decide:  Do we write the application specific to a platform or do we write the application web-based?

This is a no-brainer solution – HTML5 and web-based applications.  You get:

  • Write once, run anywhere
  • Leverage your existing skill set in web development languages and tools
  • Freedom to choose the platform, os, and carrier of your choice
  • Ability to distribute your application anytime without any constraints

Not so fast, however.  There is a lot more to the implied surface question of “Do I want anyone to run my application or just Android (or iPhone, or Blackberry, etc.) users?”  Let’s examine for a moment the ‘no-brainer’ arguments above.

Write Once, Run Anywhere – Name a successful, totally pervasive platform where this actually happens?  Wasn’t this the panacea solved by the Java language in the mid-90’s.  Yet with Java, there are always minor nuances in the UI and implementation that are keeping this from becoming a reality.  Need proof?  Connect up Cisco’s ASDM Java interface for managing their ASA series firewalls.  Nearly unusable on the Mac platform, this program performs just fine on Windows.

A valid argument could be made that Adobe Flash has executed a near-perfect job of perfecting the WORA world.  Flash programs run (even with all the processor intensive, battery draining performance) exactly the same on any platform.  It’s just that they are not allowed, and arguably for valid reasons, on iOS devices.  Unless you want to ignore a market of over 120 million potential users, Flash is not a viable option.

Leverage Your Existing Web Development Skill Set – What exactly is an ‘Existing Web Development Skill Set?’  Presumably, it would include (x)HTML, CSS and JavaScript, but what else?  What about HTML5?  AJAX frameworks?  Do we include jQuery, MooTools, Dojo, Prototype, EXT?  Rails?  What about the back-end (more on that to come) but does existing skill set include PHP, .NET, JSP, Coldfusion or any of the other brands of server-side technologies?  My point is yes, you can leverage your existing skill set, but don’t be fooled.  It’s not the same as learning one good language and perfecting your skills against that language.

Freedom to Choose the Platform, Carrier and OS of your Choice – As we intelligently say where I live, Hogwash!  All carrier and platforms have their proprietary preferences.  Need proof?  Look at Internet Explorer.  Look as close as to the different way the open source WebKit is implemented across mobile platforms.  What about Windows Phone 7 which has the browser equivalent of IE 7?  I shudder to think about the mobile hurtles to jump through like we have for ages with IE, Firefox and WebKit.

Think about API’s that access the low-level device functions such as the accelerometer, gyroscope, and gps.  In order to access, you must use browser specific API’s or learn and be tied to yet another language and third party interface to access.  What is happening is a retro-trip back to the days of browser detection and programming for “if less than or equal to IE 6” do this, and “if IE 7 or greater” do this, and “if Mozilla” do this.

The Ability to Distribute Your Application Anytime Without Constraints – That is a valid argument…almost.  There are some hurdles and some rules that must be met if you want to use one of the many vendor app store distribution methods.  All of which is easily avoided by a simple web address and browser detection.  However, all of the vendor app store platforms do allow for the distribution of private applications.

What I am attempting to argue is that the benefits to Web Apps doesn’t always out-weigh the benefits to Native Apps.  Answer the following three questions (you may substitue ‘I’ with ‘My Development Team’):

  • I have significant experience in HTML5, CSS, and Javascript
  • I have a product that needs to get market and all mobile platforms quickly
  • I have no control over the platform that the application runs on

If you can answer ‘Yes’ to these three questions, then Web Apps are definitely the way to go.  But if you cannot answer yes to all three questions, I would recommend native apps.  There are many advantages that outweigh the multi-platform complexities of trying to be the same thing for all people:

Native Apps Run Faster – No doubt native apps take advantage of the operating system framework and just flat out perform web apps.  No need to connect to a web server to get started, no need to wait on network connections, you are up and running.  One area I could not find any statistic about – HTML5 Canvas elements.  I would be interested to know if using HTML5, SVG, and Canvas for fancy, rich interactive elements is faster or more efficient that using the OpenGL ES API’s?

Native Apps Have More Access to the Device Functionality – This is native app advantage that is losing strength quickly over time.  With the new Mobile Safari API’s, developers can accesses the accelerometer, gps and other low-level functions of the device.  However, many of these access methods are browser specific and incomplete.  What if you need access to the gyroscope or some other lower-level device not included in the API’s?  There are also application frameworks that attempt to bridge the gap across mobile browsers, but be wary of tying your production to another third party tool, another application interface and language to learn, and another vendor to worry about their survival for your survival.  Wouldn’t it be easier to learn one API standard and program against that standard for all your low-level device needs?

Web Apps Consume More Bandwidth – Consider the progression of iPhone Data Plans through the years:  When released in 2007, at&t allowed unlimited data access and 200 text messages for $20 a month (United States).  Then, with the release of the 3GS, at&t removed the 200 text messages and increased the price to $30 a month.  Next, with the release of the iPhone 4, at&t once agained changed their plans, with the unlimited plan costing subscribers a whopping $40 a month.  A doubling of the cost in three short years!

I argue the carriers don’t have the air channel bandwith to accomidate streaming movies and other large content with the growing wave of smartphone users.  In order to subsidize this increased pressure on their netoworks, they are going to continue to charge more for bandwidth.  Or at least as the cost per megabyte may be going down, our consumption (and total cost) is rising steadily.

Web Apps can circumvent this by running locally, and only sharing data across the network as needed through web services.  This is the perfect balance of connectivity and bandwitth savings.  Yes, yes, I know, HTML5 does offer localStorage API’s, but these are still not fully documented and subject to browser cache-resets and limited storage (normally 5MB on a mobile device).

Skill Set – Many the middle school geek has the necessary experience to program web sites and even fully-functional web-apps.  But as our discussion earlier, what skill set is that?  With a native apps, you’re perform almost any task you need with the mastry of one language (Objective-C, Java, C#, ActionScript) and the development API standard from the platform.

I may be the lone hold out and my arguments my not hold for many of you, but for today my recommendation would be to pick a platform and develop native applications on for it.  Especially if you can control the platform and are in an enterprise setting.  Becoming an expert will allow you to make great applications and not require you to compromise in functionality and speed for the sake of pervasiveness.

It was 1994 when Netscape Navigator first released it’s HTML web browser, and its just been the past few years that we have seen the bandwidth and browser functionality to allow web applications come close to rivaling those of native os programs.  This is why to this day, we still don’t see the most beautiful and functional applications (Adobe Suite Apps, Final Cut, AutoCad, etc.) running in a browser.  I believe we are still years away from the browser offering the best experience possible.  Until that day arrives, I want to err on the side of great applications and Native Apps are the way to accomplish that.

,

Comments are closed.