There has been a lot of excitement, interest and discussion around Apollo, especially since we released the public alpha on labs last week. One thing that has come up a couple of times, is confusion over what Apollo is as well as what value it provides. A lot of the discussion has focused on uncertainty about why would you want to move web applications outside of the browser.

A lot of times when this question gets answered, the answer focuses on specific Apollo features (file I/O API, working offline). While these are things that Apollo can do today, that are difficult if not impossible to do consistently in the browser, a feature based discussion doesn’t address the fundamental question of why would you want to move applications out of the browser.

I had been planning to write up my thoughts on this, and realized that I already had as part of the Apollo Pocket Guide for Flex Developers. Below is chapter one from that book, which explains what Apollo is, and what problems it is trying to solve. (You can download the entire book from here).

Note that the excerpt does contain a discussion of features, but one of the primary advantages of Apollo, which isn’t a specific feature, is that it allows applications to run outside of the browser. This is not a ding on browsers, or web technologies, and as I point out, the browser has some strong advantages that often outweigh its disadvantages.

Ultimately though, because browser based and Apollo based applications are built using the same technologies, it is possible to deploy to both platforms, taking advantages of the strengths of each. Because of this, Apollo applications compliment web applications. They do not replace them.

Online applications that are pin point targeted to provide a specific service generate intensely loyal fans. Apollo will give us the ability to extend these applications deeper into the user’s lives by making them part of their operating environment.

I have put together a very simple example of how to download and cache items to the files system. This can be useful if your application needs to work offline, or if you want to optimize performance and don’t want to have to keep downloading the same assets over and over.

This example uses some of the caching classes from my Ascension mp3 player, and required the corelib library.

In order for client browsers to recognize an Apollo application when being downloded, the Web Server hosting the Apollo applications needs to map the following mimetype“application/vnd.adobe.apollo-application-installer-package+zip” to the Apollo extension “.air”. For example, for an Apache Web Server you will add to the AddType section:AddType application/vnd.adobe.apollo-application-installer-package+zip .air

Note, you can do this in the web server config, or if using Apache, in the .htaccess file.

The Apollo team is heads down working on finishing up the first public alpha release build for labs. I wanted to give a quick update on where we are, as well as provide some information about the labs release.

The first release on labs will be an alpha release. This means that the build will not be feature complete, and those features implemented may not be completely implemented (such as the windowing API). It also means that there will be bugs (make sure to check out the release notes before you play around with it).

Secondly, the first labs release will be targeted at Flex developers. HTML developers will be able to start building applications, but we won’t have HTML focused docs, and some of the HTML specific features are not as far along as some of the other features. The second labs release in the summer will be targeted at HTML developers.

We are really excited to see what developers do with Apollo, and can’t wait to finally get it into everyone’s hands.