The Five Most Common Arguments for Native iPhone Development

There are five common arguments for why iPhone applications need to be built using native code instead of web technology. Three of the arguments either don’t apply in all cases or are simply wrong.

The five most common arguments for native app development are:

1. Offline Mode — The ability to continue to use an application when you are not connected to the Internet.
2. Findability — If you’re not in the App Store, people won’t be able to find your application.
3. Performance — Javascript on mobile is too slow to use for application development.
4. Device Attributes — The need to access things like the camera, gps and the accelerometer.
5. Monetization — The ease with which people can and will buy your application.

These five reasons are also provided to argue for native app development on other platforms like Android and Blackberry as well.

Let’s take a look at each argument in more detail and evaluate their accuracy.

Five photo courtesy Flickr user boklm published under Creative Commons.

The Offline Mode argument is that when you build an application using web technology that you must be connected to the Internet in order to use the application.

This makes native applications more useful in a mobile context where people may lose connectivity periodically as they move from place to place.

However, this argument is simply false as far as the iPhone is concerned.

On July 11, 2008, the iPhone OS 2.0 was released. With the 2.0 release, we saw not only the creation of the App Store and the first native applications, but also a new version of Mobile Safari that supported the HTML5 Web Storage and Offline Application Cache.

To summarize, there has never been a point in time when you could build native iPhone applications when you couldn’t build web applications that supported offline usage..

The basic premise of the findability argument is that if you aren’t in the iPhone App Store, that no one will find you.

In the early days of the App Store, this was true. Simply having an decent application in the App Store often enough to move units.

However, the App Store now contains 65,000 applications. Developers find it difficult to stand out in the App Store, and consumers find it difficult to find applications that match their needs.

When it comes down to it, Apple isn’t a search engine company. It is facing challenges that Google solved years ago, but without the tools and data that Google and Amazon have at their disposal. For example:

• Google’s Page Rank innovation made it possible for network effects to be used to determine what web pages have the most value based on the number and quality of inbound links. Because the App Store is sequestered in iTunes and not on the web, inbound links cannot be used to determine value.
• Without Page Rank or similar mechanisms, Apple has been using keyword tools to provide search results. This has led to a revival of black hat search engine spamming techniques in the App Store. Apple’s attempts to address this spamming have been hamfisted and resulted in the good being punished with the bad.
• If you compare the App Store to other store fronts like Amazon, the App Store lacks the ability to narrow your search results by other metadata associated with a product.

The App Store market has many parallels to the early days of the web. We used to browse the web looking for cool things, but at some point the number of options became overwhelming and search became the dominant paradigm. We’ve moved into the search phase for the App Store, but the tools aren’t sufficient to the task.

The reality is that findability alone is not enough reason to build a native application. No matter what technology you use, you need a marketing plan.

No one can argue that web technology is as fast as native application. What we can argue is that for certain types of applications, web performance is more than sufficient.

Here are some things to keep in mind when it comes to performance:

• Javascript performance keeps getting faster — Browser manufacturers have been competing to see who can make the fastest browser. Browsers have seen significant improvements in the last two years. This emphasis on speed has made it into the iPhone. The most recent version of the iPhone OS processes javascript 3 times faster than the previous version.
• Web developers can build faster applications — Most web developers are still not aware of the research done by Yahoo and Google on what makes web pages load more quickly. Web developers need to test their mobile code using tools like Yahoo’s YSlow and Google’s Page Speed plugins for Firefox. If developers can’t optimize for desktop browsers, they won’t succeed on mobile.
• Use hardware accelerated css — The iPhone also offers hardware accelerated css transformations, animation and 3D. Using these css tools, you can build smooth flowing effects that rival native applications as shown by the cover flow example built in Safari shown in the video below.

The final thing thing to keep in mind is that web technology isn’t perfect for all applications. Most immersive games should be built using native code.

However for numerous applications, web technology performance is more than sufficient.

GPS access was provided in the latest iPhone OS release, but the other device attributes like camera, accelerometer and compass are still not accessible in the browser.

The good news is that mobile phone manufacturers seem to be taking seriously the need to provide access to these attributes. The Palm Web OS is great example of exposing all of these attributes in javascript.

In July, the W3C chartered the new Device APIs and Policy Working Group to work on defining standard ways to access these device attributes.

In the meantime, usage of hybrid applications (which I will talk about later) provide a workaround for web access to device attributes.

The ability for people to play for your web application on their mobile device easily is the biggest problem facing the mobile web.

The App Store solves the payment problem elegantly. Consumers can quickly buy applications and have the purchase put on their credit card stored by iTunes. Developers know that they will get paid, how frequently, and what percentage of the transaction that Apple will take.

Solutions like Bango have tried to solve this problem for the mobile web by brokering deals with all of the various carriers. Unfortunately, the end result is a inconsistent transaction fees per carrier and country and major gaps in service (e.g., no Verizon support).

Given the alternative, solutions like Bango are a tremendous step forward, but it still isn’t simple enough for developers and consumers.

Finding a good solution for mobile payments is the number one thing holding up the mobile web right now.

That said, there is cause for hope. Nokia recently launched Nokia Money. Apple is rumored to be “considering creating a service that would allow iTunes Store account holders to use those accounts to make purchases on participating third-party sites.”

And nearly every carrier seems to be looking for ways to allow people to pay for their groceries using their mobile phone.

If we reach the point where we can buy a bottle of water using our mobile phone, I’m certain we’ll be able to pay for products and services on the Internet.

Out of the five original arguments for native applications, the two that pose the biggest challenge for web technology are Device Attributes and Monetization. Both of these shortcomings are addressed by hybrid applications.

Hybrid applications take a web rendering engine and wrap it in a native code framework. This allows developers to access device attributes via javascript in their web applications.

And because the application is wrapped in native code, the application can be sold and distributed via the iPhone App Store.

In fact, the same core code can be reused on multiple smart phone platforms like iPhone, Android, Blackberry, Windows Mobile, and Nokia.

Some of the hybrid application frameworks are:

• PhoneGap
• RhoMobile
• Titanium Mobile
• Big5
• QuickConnect

People are doing amazing things with these frameworks and are currently selling their applications in the various app stores. The following video shows a game built using Phone Gap that is currently available for purchase in the iPhone App Store:

Over the last year I’ve heard a lot of people argue that building anything using web technology, particularly for the iPhone, isn’t a viable option. These five reasons are the main arguments I hear over and over again.

However, three of these arguments don’t apply in all situations and the other two can be addressed with a hybrid application strategy.

There are tremendous benefits to building an application using web technology from a platform portability perspective. Not to mention that you can draw on a larger talent pool using web technology than you can if you build using Objective C.

So in the short term if you want to use web technology to build applications, hybrid frameworks will allow you to do so. In the long run, I hope the mobile web advances to the point that they are no longer needed.

The key is to evaluate each product that you want to develop, the markets you want to serve, and determining which combination of technology will accomplish your goals.

There is no “right answer” between native and mobile web applications other than the right answer for a particular application based on its design, functionality and business plan.