The challenge for client OS providers is far greater than simply delivering a fast, fully featured web browser on a phone. The classic web browser navigation model works poorly on a phone (in fact, some would argue that it’s poor even on a desktop computer).

Mobile users are, well, mobile. They are usually in motion, walking, driving, or occupied with something other than their phones. Launching a browser each time you want something on the Web—wading through multiple pages to get to the right spot—is tedious, distracting, and slow.

Web pages have their own UI models, with navigation and controls separate from and frequently inferior to those of the device they are displayed on. Often, the only option is to walk links. Menus, selectors, text editors, and other UI tools that enable rapid user interaction in native applications on the same device can’t be used within the web browser. Launching web pages from bookmarks or moving between web pages usually involves a completely separate UI model from that used to launch native applications and generally requires invoking the browser before anything else, adding at least one extra step to most actions.

In addition, web users are forced to initiate all interactions. They must make a request and wait for it to be fulfilled. It is clearly more effective for applications to monitor external events and prompt the user only when something of interest occurs. Ajax and web applications have made a big improvement by handling user input on the client and providing some level of dynamic user interface, but even these applications can’t employ commonly used techniques such as background execution, user alerts, and notifications.

The truth is that despite the hype, a phone with just a fast web browser is still not a truly smart phone.

To fully realize the mobile Web, a new application model is needed, one that retains the strengths of web development, but with the type of access and power that has been available to native, mobile applications for years.