The pros and cons of
Two competing approaches
Native versus Web
by Tim Aaron
Aurnhammer Philosopher and Social Media Strategist
In the throws of the 21st century, we are moving towards a multi-screen, touch-interface world where biological beings are spending more time interacting with digital gadgets and their complementing softwares than ever before. With new devices and high-density pixel displays sprouting up at rates that rival the proliferation of “trendy” grandma-sweater shops in San Francisco and Williamsburg, brands are increasingly able to broaden their reach, engaging with a greater number of consumers across a wider variety of platforms. Operating on these platforms, sites, apps, and hybrids stand as the faces of empires, postured to withstand the unforgiving sands of time as well as the even less merciful consumer reviews. And with each digital face that is developed, the same question always emerges: Is it more advantageous to launch a web app initiative (one whose point of access is through the internet) or to go with a native app initiative (one whose point of access is through a particular platform device itself)? Taking an investigative dive, let’s look at the pros and cons of each approach with regard to aspects of development and end performance.
Compatibility Across Devices
Native App
As you may know, native applications are single compatibility applications (they function on only one type of device ie. iPhone or Android etc.). Much like being a French speaker in a room full of Germans and one native Frenchman, they are suave, single language programs that can only interact with the particular entity that understands their native dialect and they fail when trying to communicate with foreign dialects. As such, they need to be run on devices that interpret specific programming languages that apps are coded in such as Objective C and Java for iPhone and Android, respectively (not that these two are the only devices on the market). Trying to run an iPhone app on an Android device would obviously not work. However, while native apps can only speak to a single platform device, when they do articulate themselves, they do so elegantly.
Web App
In contrast to native applications, web apps have the luxury of being able to run on any device that has Internet access. This capability effectively makes them cross compatible across the sundry devices that are available on the market. Coded using a mix of HTML and Java, web apps are searchable in all modern browsers (ie. Chrome, Safari, Firefox etc.), making their points of access available to a large audience.
Ability to Leverage Hardware Capabilities
Native App
The ability to access a range of features through a native Application Programming Interface ([API] the protocol through which software components interact with one another) is an exceptional faculty that makes native apps tremendously dynamic and powerful in users’ eyes (an example of an API is Apple’s object-oriented API, Cocoa Touch, which handles gesture recognition, animation, and houses a tailored user interface “UI” library). Through API’s, native apps can leverage hardware features that are unique to the devices they are on, resulting in fluidity of use and the ability to integrate with the device’s camera, address book, geo-locator, and other native features. They are what make compound UI gestures, such as double taps, pinch, and spread, so seamless as well as animations and graphics transitions so fluid. Communicating with device hardware through its native language, native apps are fast, polished, and smooth for that “like-butter” feel.
Web App
While there is a misconception that web apps are not able to access device-specific capabilities, they are certainly not able to leverage the full range of methods presented by a device’s operating system. Limited API’s impede access to native features such as multi-touch, fluid animation, fast graphics and built-in components. And although an increasing number of APIs have been introduced to web browsers, such as geo-location, further advancements into the ability to leverage unique device hardware features will have to wait until technology permits.
Speed
Native App
The primary reason that native applications run so fast is due to the fact that they run offline with most, if not all, of the necessary resources already stored on the device that the app is running on. All of the app’s text, images, and videos are downloaded before it is put to use, rejecting the need to process any information that is running on an outside server. And even with native apps that fetch content from a web URL (such as Facebook, which contains information that users need to access each time they employ the app, such as new wall posts and updated news feeds), most of the material is already downloaded and the app simply feeds the new content into a pre-existing structure. Running on device hardware rather than through a server, native apps streamline the computating process for a faster, more organic user experience.
Web App
Unlike native applications, web apps generally need to access the Internet in order to function. With little to no content that is pre-downloaded onto the device that the app is running on, web apps require the execution of a greater number of computational tasks. Needing to constantly connect with an outside server in order to process software each time the app is run, app speed is slowed down and performance is compromised. Additionally, the same lack that generates computing-speed problems also puts a cost on the consumer; since web apps need to be accessed through an Internet connection, consumers are forced to use data if a Wi-Fi connection is not readily available.
Cost
Native App
Initial development costs and the costs of app maintenance are relatively high for native applications. The reason for this stems from the fact that native app development requires programmers with an advanced skill set who are drawn from a small pool of expertise. When asked about the average price of native Android apps, Michael Burton, Android developer for Groupon and Digg, wrote, “Depends quite a bit on a variety of things, especially on the complexity of the app, but one quote for an app that takes about six weeks (low to average complexity) would be about $35,000. This is probably on the low to mid end in the range of quotes.”[1] Because native device platforms are still in their inception, exploration into the new platform technologies has only recently begun and the number of expert pioneers is still few and far between. As more developers acclimate to the new technologies, it is likely that app development costs will lessen but, for now, the cost is in direct correlation to the supply and demand of the scarce, device-specific experts.
Web App
Due to the widespread availability of developers who know HTML and Java, web apps are relatively cheap to develop. With costs between $2,500 and $30,000, depending on complexity, such apps can be developed more quickly and with fewer resources than native apps. Moreover, since web apps are run through web browsers, required maintenance is less frequent and app updates are compatible across device platforms.
Conclusion
As it stands now, the advantages of web applications are primarily more on the app developer’s side whereas the advantages of native applications are more on the app user’s side (which makes them advantageous for the company that is acquiring and retaining consumers through a mobile initiative). The principal reason to go with a web app initiative is often if budget restricts but if cost is not an issue, a native app initiative will deliver a user experience that is far superior at this point in time, especially if the amount of app content is high. As technological advancements are made in HTML, the divide between web app and native app performance will diminish but for now, native delivers a better user experience overall. Going forward with your app initiative you should make sure that you have developers who understand and can program for a range of technologies within a context of you’re company’s mission and budget so that they can fully assist you in your decision of which approach to take.
Now that you have some food for thought, weigh in and join the discussion about two approaches that are competing to deliver the best app performance. Only through collaborative discussion will we advance knowledge and achieve enlightenment.