With its Cloud Apps, Google tells a nice, simple story: All you need is a browser. Life is simple, we take care of everything, no more fighting with fat, expensive desktop bloatware.
You can access your data and our apps Anywhere, Anytime…if you have an Internet connection. If you don’t, as we’ll see in a moment, things become more complicated. More like yesterday.

Let’s start with a simple Web app. How does it work?

Somewhere, a computer runs a Web server. In turn, the Web server runs an application whose job is to pull the strings of the browser marionette hiding inside my computer at the other end of a Net connection. The app tells my browser to display ‘Monday Note’ at these coordinates inside such-and-such a window, using this font, that size, and this color. Or the Web app sends a file and tells the browser where and how to play it, and so on.
But what happens if I lose the Net connection? The server no longer pulls the string, the marionette collapses, my Web application is dead.

To achieve its strategic goal of displacing Microsoft Office, Google knew it had to provide an off-line version of Google Apps. Off-line capability is implemented by dropping a replica of the Cloud—a Web server, the application code running on that server, and a local cache of my data—into my computer. My work will be uploaded to the Cloud when the Net connection is restored. With today’s software technology, with abundant storage and computing power on desktops and laptops, Google’s goal isn’t unreachable.

But…the Cloud can be replicated inside my laptop?

It’s not as fantastic as it sounds. While the Cloud evokes images of Google server farms and Big Iron, even the flimsiest of netbooks now provide ample RAM space (at least 1Gbyte, often 2), plenty of disk space (160 Gb or more), and an Intel processor running at 1 GHz or faster. Recreating the server, storage, and applications is well within their power.

Furthermore, your PC/laptop/netbook already contains a Web server. Every Mac carries a copy of the Apache Web server (“the most popular HTTP server software in use” says the Wikipedia article), as so do most Linux “distros” on netbooks and DVDs. Windows provides a Web server called IIS, Internet Information Services, the “second most popular web server in terms of overall websites…” (Wikipedia). If you want Apache on Windows, it’s free and easy, go here. The Windows Installer package (née MSI) weighs in at 6Mbytes, that’s all.

Combining on-line and off-line work modes isn’t a new idea at all. Microsoft has been providing combined modes for years with Outlook and the Exchange Server. When I’m on-line, I can edit contacts, mail, calendar appointments. If I’m sitting in an airplane composing email replies, I work on a local cache, a copy of the server data that resides on my hard disk. When I reconnect, the mail is sent, the calendar on the server is updated, the two versions update one another and consistency is restored. (Most of the time…)

Until recently, Google provided some off-line capabilities for some of its Apps, using a browser plug-in called Google Gears. The goal was to offer an ‘open source browser extension that lets developers create web applications that can run offline.’ Gears has since been “deprecated” (I’m not too fond of the word’s potential for alliteration) by which Google means they’ll rely on HTML 5 to provide…

• A Database module (powered by SQLite) that stores data locally.
• A WorkerPool module that provides parallel execution of JavaScript code.
• A LocalServer module that caches and serves application resources (HTML, JavaScript, images, etc).
•A Desktop module that lets Web applications interact more naturally with the desktop.

A Geolocation module that lets Web applications detect the geographical location of their users.

It sounds and is complicated—this is far from “just use a browser”. If Google wants the best of both worlds, if it wants on-line as well as off-line capabilities for its “Office-killer” apps, it will have to stuff a lot of local code on our machines…and update it, and deal with bugs, just like Microsoft and its desktop apps. Furthermore, for most users, the desktop versions of today’s Google Apps can’t compete with the familiar MS Office. (As discussed last week—a mere opinion—my own Google Docs user experience hasn’t been enticing.)

Summarizing: Google wants to kill the Office Golden Goose. To do this, it must go beyond on-line, browser-based Cloud apps and provide off-line, “earthbound” versions as well. Ironically, this kills the “Everything in the Cloud” argument: Google is now forced to deploy and maintain a complex set of desktop apps that emulate the Cloud originals. Microsoft seems far better equipped to continue with its familiar, robust desktop Office products while it deploys a subset of functionality in the Cloud.

And Apple?

While Apple believes in “native”, local apps, when the iPhone came out there were no tools to develop applications and no App Store. The party line was “Web 2.0 apps”. We know what happened: We have iWork apps on the iPad and on the Mac but no Web versions. In that sense, Apple doesn’t have an answer for the on-line/off-line dual modes offered—or promised—by Microsoft and Google. (There is iWork.com as a way to share documents, but editing capabilities are still only local.)

But…ask a friend to show you the iPhone manual on the iPhone itself, not from a desktop browser. Or, better, the iPad manual on the iPad. While they look and behave like local code, they’re actually Web apps. Here’s the local Settings app on my iPad:

…compare it to the iPad Manual, a Web app:

The iPad Manual Web app fooled everyone I showed it to, even more so after bookmarking the site (www.help.apple.com/ipad/mobile/interface) on the Home screen:

It looks like another app.

Let’s look at the local iPad Mail app (which, by the way, has a fluid and fast UI, very helpful when you’re dispatching a large number of messages):

Last week, we heard that Apple is going to update its MobileMe Webmail app. It’ll look like this:

Web apps that are nearly indistinguishable from the local code versions running on the iPad. This is the model Apple could use to get the best of both on-line/off-line worlds.

What’s next? Perhaps a MobileMe (or iWork.com) version of Pages, or Keynote (Apple’s own “PowerPoint”) or Numbers (their spreadsheet). The code runs on an Apple server (that’s not too hard) and the UI is served via the browser (that’s a little harder).

Going back to the on-line iPhone and iPad manuals, alert geeks have noted Apple’s use of an HTML framework nicknamed PastryKit. (An HTML framework is a collection of HTML code modules—HTML “bricks”—you can use to build an application. Google supplies iPhone HTML modules here…) ArsTechnica, the aptly named techie site, called PastryKit the “best iPhone Web app library you never heard about”. John Gruber, the always-awake blogger, provides further insights here and here.

What this all boils down to is this:

– Like its frenemies Microsoft and Google, Apple has been busy making Web apps, and crafting the tools to build them.
– Unlike Microsoft, Apple doesn’t have an Office cash cow to protect so they can build Web apps that “cannibalize” the desktop iWork suite.
– Unlike Google, Apple starts with good (YMMV) desktop apps—and they don’t have to give away their Web versions.

The almost unavoidable conclusion is that Apple could build itself a nice MobileMe 2.0. Today’s version isn’t always well-regarded, even when it provides neat features such as Find (and Lock, and Erase) my iPhone or iPad.

Tomorrow, Apple could play the freemium game. Let’s say free email or 5 Gbytes of picture storage, and paid-for iWork Web apps. Who knows, you might even be able to host your own domain name, as Microsoft Live now provides. (Although I have my doubts about that. Microsoft thinks Small Business, Apple thinks Consumer.)

This is all speculation, of course. Should Apple enter the game, the matter of execution would play its usual role in determining if Apple could yet again extract large amounts of money from a less-than-dominant share of the market.