Enrique Ortiz (CEO) has been picking up the threads of the local versus browser debate, especially in response to a suggestion that ‘mobile apps are dead.’ CEO has been around and knows his mobile apps, so his thoughts on the topic are worth reading.

This debate comes around and around and is almost always argued as if it were a philosophical debate, which it ain’t.

Browser and installed (embedded) apps came from different places and have served completely different purposes. The reason that an embedded app environment exists on a phone, be it J2ME or native, is to expose the functionality of the underlying phone and make it available to software applications. The reason a web browser exists on a phone is to access web pages (i.e. mark-up files) on remote servers.

Today, a web app can’t do lots of the things that installed apps can do, whilst this is generally not true of an installed app. Indeed, an installed app can behave exactly like a browser, because - wait for it - it can actually be a browser! Sometimes, like Opera Mini, it can be a better one than ships with the phone in the first place!

The programming model, as such, of a web page in a browser, is all document-centric, totally unlike the general purpose programming model of an embedded app. They have very different UI capabilities and so on. Installed apps are persistent whereas (at least currently) most web apps aren’t.

However, none of this is what really brings about the fragmentation problem that is being blamed for the so-called death of mobile apps. Lest we forget, most mobile phones are not upgradeable in the field, or ‘after market’ as the analysts like to say. Hence, we have a very real legacy problem that leads straight away to a fragmented sea of devices out there. This accounts for lots of the fragmentation across the potential user base. All mobile service providers know this and hate it.

The next problem is the shear number of types of phone out there and the fact that they are still, for the most part, being shipped to fulfil a primary purpose as a telephone and texting device, not a computing device. This accounts for two problems. Firstly, the number of device platform variations - even within a single device family, which can have multiple software builds in its lifetime - inevitably leads to many subtle (and sometimes not so subtle) performance variations, especially in the handling of increasingly complex J2ME API implementations and browser implementations. Secondly, the testing resource and motivation in mobile manufacturing is highly biased towards telephony interoperability and compliance, not to software API compliance and mark-up rendering compliance, especially as these don’t really affect handset sales and profitability.

In the desktop world, the underlying hardware and OS variation is a walk in the park compared to mobile. Problems do happen, but we don’t notice (or perhaps we do) that the never-ending stream of software updates (OS and browser) is always moving in the direction of ironing these variations out. Also, greater abundance of resources on the desktop compared to scarcity of resources on a phone allows for a more forgiving environment in which to deliver a more consistent software ecosystem.

In a nutshell, the whole industry has spent billions on solving a very real and significant problem, which is voice connectivity. This business has been incredibly successful. The problem of mobile computing has not been solved and we might wrongly be blaming it on a mobile telephony business that doesn’t yet see how it can make money from solving the problem.

The reason that the browser can offer wider penetration than installed apps is that all phones come with a browser whereas any after-market installable app would have to be downloaded and installed. However, browsing on mobile phones is still very fragmented. When implementing very rich mobile sites, they have to be tested on each target device. It is normal for there to be rendering problems from one handset to the next. The only solution, apart from extensive testing (and often in each country to take into account the most popular handsets regionally) is minimal features, or lowest common denominator design, which ends up not appealing to users.

What’s interesting of late is how many sites out there (e.g. Facebook, LinkedIn etc.) are offering designed-for-iPhone versions, some almost exclusively as their only mobile offering. And, let’s not forget that this is what Apple does too with YouTube and Google Maps, before we get too carried away with ‘normal web works on my mobile’ enthusiasm.

I am left wondering if this device has finally tipped the balance towards at least the notion that if we really want a usable and great mobile web experience, then we have to settle on only one or two platforms (i.e. devices) and that’s it. Is there enough momentum behind the iPhone in this direction?

Whilst there are lots of us who want to innovate in all kinds of directions around the mobility theme, what does the consumer really want? Will they be content with vanilla mobile phone/texting plus an awesome web experience, or will they want all this other mashed-up stuff promised to us by a world of ‘mobile computing’ and ‘next generation networks’?

Why not contribute to the wireless innovation discussion at the forthcoming Ecomm 08 conference, where some of these issues will be hotly debated. I will be there and look forward to meeting some of you.

Technorati Tags: Browser, embedded, Opera Mini, mobile apps, J2ME, iPhone

[This blog has moved to here]