Do iOS users really want mobile web applications?

I recently wrote several posts on native clients for RSS reading and management following the announcement that Google would kill its aggregation service and Google Reader. A number of developers and readers pointed me to web applications, while others announced forthcoming iOS-native clients. Which approach is better?

Petr Kral, co-founder of Skimr, wrote to say that the company is also planning to release native clients. I asked him about the rationale. He said the cause isn't as much technological as demand on the customer side.

Kral said that he recalled the 2007 announcement of iPhone application solutions at the Worldwide Developers Conference (WWDC). Some developers were disappointed in the lack of an SDK for native applications, rather than the Web 2.0 approach voiced by Apple management.

I can remember Scott Forstall taking the stage and talking about apps — web apps, that is. Developers were supposed to create these for the iOS platform. They would have all the benefits that web apps inherently have (immediate updates, etc). That was before Apple allowed developers to create native apps.

It made perfect sense. I was just that the browser technology was not quite there yet at the time of the announcement. Apple was simply too early.

In March 2008, Apple rolled out its App Store and detailed the road map for its iOS SDK. At the time, John Doerr, the Silicon Valley legendary venture capitalist, said that iOS was the "creation of the third great computing platform".

Today, we're witnessing history: That's the launching of the SDK, the creation of the third great platform, the iPhone and the iPod touch. Think about it. What the iPhone is all about is in your pocket, you have something that's broadband, and connected all the time. It's persona, it knows who you are and where you are. That's a big deal, a really big deal. It's bigger than the personal computer.

However, Kral says that while customers and mobile device makers now see native apps as being faster, better, and more responsive, the web app is quickly attaining parity. He pointed to projects such as famo.us as a prime example.

When we were building Skimr, we just couldn't see a real benefit that a native app would bring. After all, Skimr is a very simple service. Turns out we were quite naive. Users demand native apps! So, we decided to give them what they request.

We have solid product plan, and some of the features that users are requesting go against it [the plan], so we reject them. But a native app is just a distribution method, really, so there is no harm in creating a few of these. It will just take some time.

Perhaps the selection of the approach depends on the application and its expectations from users? A simple content application, such as Skimr or a sports stats app, may come closer to the advantages of web apps than a complex app that wants connections with hardware-only services such as GPS, and photos or video streams from cameras. Developers also need to consider whether their app needs to take advantage of software and network services such as notification services, which can only be accessed through a native application.

All in all, my bet is that a few years from now (maybe sooner), users won't be able to tell a difference between a native app and a web-based app and it will really come down to what will be the preferred solution of a given developer (cost, time to market).

Note that I'm not going into monetization here. Now, I prefer paying for updates and not have advertisements clogging my interface. Developers have to figure that part out.