Does everyone have iPhone App-opia?

At one time Apple wanted you to know just how good the web was on the iPhone with the early ads focused on the web browsing experience the device offered. This was before the app store. Recent ads have shifted focus, drawing attention to the diversity of applications available for the platform through the app store. These are the “There’s an app for that” ads. The mobile carriers AT&T and Verizon have been battling for months on the whole “There’s an app for that” vs. “There’s a map for that.” AT&T feels as though the device’s capabilities and wide variety of applications available on the app store are a huge selling point. Verizon feels it’s about service coverage. Float thinks that both of them are missing the point when it comes to true mobile ubiquity and utility.

As mobile enthusiasts, we are pleased that there are so many choices for application functionality at the iTunes App store. In fact, one could argue that having so many single purpose applications like tip calculators and the like is a bit of overkill. As another example of this, at last count there were nearly a dozen alternate “web browsers” in the app store that simply act as wrappers for the webkit rendering engine (which already exists on the iPhone as Mobile Safari).

As mobile developers, we are less than pleased with the overall development process and the walled garden approach taken by Apple and the cottage industry that has sprung up around everyone’s favorite mobile device. With so many single purpose apps out there, and the fact that so many of the apps that could just as easily be executed as mobile web apps, one wonders if we haven’t all gone mad. It seems as though everyone has taken a myopic view to mobile development, or “iPhone App-opia.” Blinded by success stories and dollar signs, no one is looking at the bigger picture. Access to the content in the easiest format, and the ease of development required to provide return on the investment of the development and content creation is really what is needed.

All one has to do to recognize this is to think back to the height of the browser wars. With Netscape and Internet Explorer firing salvos at each other from the respective development camps, there were two clear losers in the battle: the web designers/developers and the consumers or end users. The web design professionals were spending hours and hours on creating many separate versions of the same site for all the different end deliverable platforms. Revision cycles and redesigns were painful and expensive. I remember those days. I didn’t see a lot of weekends or nights at home. I was busy writing alternate style sheets, HTML templates and re-encoding media for the myriad players and bandwidths that the users were coming with to the sites I maintained. Ahhh…yes, the users. The poor users. Want to watch a video? Great, choose the browser you are using, now the video player, now the bandwidth. Make sure your resolution is set correctly. Install this plug-in or that one. Too many choices, none of them easy to make or really even necessary had the browser developers worked together to use web standards. These standards, and the birth of the Dreamweaver task force eventually liberated the users and developers.

Where is the task force for mobile?

Much has been said as of late about the Apple iPhone app development and deployment process. It’s too rigid. It’s too formal. It’s too much like a closed country club. All of these might be true (and maybe not depending on your vantage point, I suppose). But more so, with the recent 3.3.1 clause in the SDK, Apple has taken one step further away from allowing the users to have the best viewing experience possible due to the fact that now developers will be forced to redevelop their applications using an additional SDK/API that they may not have been budgeting for before the clause was created. With the pressure to produce the highest quality application possible, there are only a couple things that can change if the developers are going to still produce a top tier application. Schedules will slip or application pricing will change. Some projects may not get built at all. The long term sustainability of generating a new application for every mobile device and platform out there simply is not there.

What can we do?

One great first step to take would be to determine if you actually need a native application. Are you planning to monetize it via direct sales? Do you need low level device hardware access? Do you require offline functionality for limited connectivity clients? These and other questions will lead you to the answer as to whether you need to make “an app for that”, or if you were simply wearing iPhone goggles.

One needs to remember why they are creating what they are creating prior to wildly and aimlessly embarking down the road of answering the call from your colleagues “Is there an App for that?” question.