Smartphones are more powerful, networks are faster and people are more willing to perform complex and sensitive tasks from the road. An important link in the chain of increased mobile productivity that doesn’t get too much attention, however, is the way in which the applications used by these devices are put together.

Apple’s iPhone – with its revolutionary user interface and blizzard of applications – has stimulated the market. “The iPhone was like a stake in the ground,” says Jose Colucci, a mobile strategy and application analyst. “It was the marker that changed the way people look at mobility and mobile devices and the ability to turn the experience into something that is not negative.”

The sense is that a great deal of app development evolution is happening in a short timeframe in an effort to keep users satisfied with their expensive gadgets. “The debate is pretty simple: What do we do? Do we go with a cloud-based solution or a solution targeted to a specific platform?” says Philippe Winthrop, an analyst with Strategy Analytics. “The second issue that comes up is what [each development approach] means in terms of what we can do with the devices.”

Developers have a number of options. Experts say that two established ways to write applications are vying with two newer approaches aimed at alleviating the older methods’ shortcomings.

One established approach is to write “native” applications for the individual operating systems, which include Symbian, Research in Motion’s BlackBerry, Palm’s WebOS, Microsoft’s Windows Mobile, and Android, in addition to the iPhone. The other is to use Web-based applications that run on devices’ browsers. Experts say that each has its positive and negative qualities.

The two new methods – widgets and application development frameworks – are in essence clever workarounds that proponents say avoid the downsides and seize the advantages of each of the established approaches.

Going Native? Ahead in the Clouds?

The tasks to be performed and the corporate context have a big impact on which approach is best. A simple calendar app may elegantly be served over the Web, while a deep dive into customer relationship management, enterprise resource planning or other complex applications may best be served by an OS-specific approach. The decisions also will be influenced by the organization’s mobile profile: A company that limits employees to one or two smartphone brands is a better candidate for native applications than a company that is all over the device map.

Colucci prefers smartphones that use applications built within the native operating systems. He said that many applications work best when they can burrow into other areas of the device, such as the address book or the camera. Writing applications for the individual operating system simply allows the application to more easily perform complex tasks than Web-delivered applications that are foreign to the device, Colucci says.

Derek Kerton, the Principal Analyst and Managing Director of The Kerton Group, adds that applications custom-built for the specific operating system on which they are used run faster than one-size-fits-all Web-based applications. A third advantage is that they remain functional even if the device loses connectivity.

The common wisdom is that native, operating system-specific applications work better. That sounds like it should be game, set and match. After all, if seems to be a no brainer: If it works better, it should be used. It isn’t quite that simple, however. Observers say that use of native apps come with a big drawback.

The big disadvantages of OS-specific applications are most keenly felt when considered within the larger context of the organization. Few organizations only support one type of device. Thus, rewriting is necessary for each operating system that a specific application will be used on. That’s a big and growing challenge as devices proliferate. “If you want to take advantage of the iPhone and move to Symbian, it is a big deal,” Kerton says.

In many ways, the advantages and disadvantages of Web-based applications are the mirror image of OS-specific approaches.

The biggest advantage, without a doubt, is that the application and the device’s operating system are distinct entities. Thus, organizations have the ability to write once for use across the entire spectrum of devices. “The ‘pro’ is huge,” Kerton says. “Number one with a bullet is universal deployment.”

The downsides are significant, however. Generic Web applications can’t easily customize themselves to specific elements of the device, such as screen size. Kerton said that “a lowest common denominator” thinking has to suffice.

They also can get lost. Web apps are accessed by calling out over the device’s browser. This means that their presence on the smartphone is rather marginal. Having an icon on the device – as native apps do – creates a higher profile than a spot on the user’s favorites list. The third downside is that Web-based applications depend on connectivity. Unlike on-board applications, they generally are disabled when the device is offline.

Two Routes to the Best of Both Worlds

Kerton says that an ancient concept – ancient, at least in terms of the world of mobility – is reasserting itself. Palm Query Apps (PQA) date all the way back to the 2000 timeframe. The idea is simple: Developers deploy enough application code on the device to begin the operation. While this code is occupying the user – like a cartoon before a movie – the application is calling out to the Web or a backend database for the bulk of the code.

Kerton said that this concept is being dusted off. He offered an example focusing on voice-enabled search. In such a scenario, code on the smartphone captures the search term in a data file. While this is going on, a link is established to the backend database. The requested search term is sent, the search carried out and the results returned. The clearest distinction between this approach and Web apps, Kerton says, is that widgets don’t require users to connect to the Web. The browser can access the necessary code from anywhere reachable through an IP network.

Bifurcating the workload in this manner gives the app access to the camera, keypad and other elements of the device. A secondary advantage is that the presence of code on the device enables the application to look like a native. It may, for instance, get an icon on the user interface or in some other way maintain a high profile. Being seen more easily, of course, is considered a good thing by developers.

The second clever workaround is application development frameworks. These use elements of the browser without actually hopping onto the Internet. “The emerging way is what you could call ‘the browser in an application,’ ” says Senthil Krishnapillai, director of Product Management for Sybase iAnywhere. “Traditionally, it used to be an application inside a browser. That is morphing into a browser inside an application.”

The idea is that developers write the application using the standard HTML tools. The applications can use the capabilities in the onboard browser to enable the application to work with the device’s native operating system, just as it would with an application grabbed off the Web.

Adam Blum, the CEO of mobile application framework provider Rhomobile, said that the browser never actually accesses the Internet. Rather, the parts of the browser that customize Web apps’ HTML code (once it is downloaded) for the particular operating system are leveraged. “What this does is opportunistically use the browser component on the device and lets it do the rendering and [customization for] the UI,” he says.

The world of mobile application development is evolving, by necessity, at a breakneck pace. The sense clearly is that the great creativity of developers and their organizations will enable applications to avoid being the weak link in the burgeoning world of mobility.