During my recent visit to the US, I popped into the Adobe office in San Francisco to find out more about Apollo – the company’s new RIA (Rich Internet Application) runtime and development platform. I sat down with Mike Chambers – Apollo Senior Product Manager, developer relations – to figure out what Apollo is all about and where it’s headed in the future. Christian Cantrell, another Product Manager on the Apollo team, joined us midway through to show me some of the newest Apollo apps.
In this post, I summarize that meeting – but also I aim to give a kind of ‘Apollo for Dummies’ overview (because until that meeting I was one of those dummies!). Much of the media and blog coverage of Apollo so far has been focused on what it means for developers, but I have yet to see a cogent explanation of Apollo for end users. So this post is an attempt at that.
Mike started off by explaining to me that Apollo aims to bring web apps to the desktop, in contrast to Microsoft’s WPF which comes from the desktop to the Web (it’s worth noting though that Mike doesn’t believe Apollo competes with WPF). He also told me that an oft-quoted benefit of Apollo, offline access for web apps, is not the main reason Adobe created Apollo. He said the main reason is to break out of the restrictions of the browser, with a richer UI. Essentially Adobe is aiming to create a new type of runtime, one that allows end users to run web apps on the desktop – as an alternative or complement to the browser.
Apollo is still in the alpha phase – and indeed Apollo won’t be the final brand name for the product (the new name hasn’t yet been decided, or at least is being kept under wraps for now). The public beta will be early summer US, with the official 1.0 release slated for late fall / early winter 2007.
Apollo in layman’s terms
Let’s back up for a minute and pin down exactly what Apollo is, because if you’re not a developer then the official definition can be difficult to grok. Here is that definition:
“Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy rich Internet applications (RIAs) to the desktop.”
Firstly, the word “rich” simply means web apps that are interactive and graphically sophisticated. The word “runtime” is probably the biggest sticking point for non-developers in understanding Apollo, but essentially a runtime is a platform where software applications can be deployed. The Web browser (e.g. Firefox, IE) is probably the best example of a runtime – certainly it is the most widely used runtime on the Web. It doesn’t just run web apps of course, but more commonly it is used to host HTML web pages.
So why create a new runtime, if the browser is ‘good enough’ for most web apps – including RIAs (most rich Ajax apps run very well in the browser)? Well the reason for Apollo’s existence is essentially to create a richer, more interactive environment for web apps. To achieve this, Adobe has created a platform for web apps that in some cases is an alternative to the browser, in other cases complements it. This is because Apollo web apps run on the desktop, using the Apollo runtime. Note that developers can also deploy Ajax applications to the desktop via Apollo.
Adobe Media Player
From a developer perspective, the benefit is that developers can use their web app building skills to develop web-based apps that run on the desktop – e.g. they might build an Ajax app that runs on the desktop, to complement an existing app that is browser-based. Indeed that is the main ‘design pattern’ emerging in the first lot of Apollo apps to emerge – see examples below.
What’s more, Adobe is aiming for a much lighter ‘footprint’ on the desktop than previous runtimes – e.g. Sun’s Java runtime (popular on the Web in the 90’s) and Microsoft’s DotNet. A footprint is essentially how many megabytes you need to download to install a runtime on your desktop. It’s important to remember that, as with any software running on your desktop, you need to install it onto your computer. With Java you need to download 12-13 MB, and with DotNet it requires a 50+ MB download. Mike Chambers told me that Adobe is aiming for a footprint of around 6 MB, significantly lower than its two competitors. He also said that Apollo won’t have problems with conflicting versions of the runtime, which has been an issue for Java in the past.
Examples of early Apollo apps
Mike Chambers and Christian Cantrell showed me several examples of Apollo apps and many of them were designed as desktop complements to existing browser-based apps. Bear in mind that Apollo is still in the alpha phase, so there aren’t many example apps yet. Two of the more impressive Apollo apps so far are Finetune (a desktop music player similar to last.fm or Pandora) and eBay’s Apollo app (code-named Project San Dimas).
Finetune is a personalized radio – mostly HTML-based, but the player itself is Flash. Originally Finetune was browser-based, but using Apollo the developers created a desktop version. While it complements the browser version, the desktop Finetune has some added functionality that is especially attractive to power users. For example it can integrate with iTunes, something that the browser can’t do. Essentially this is done by the two desktop apps (iTunes and Finetune) sharing XML files. Adobe sees Finetune as a classic use case for Apollo – where developers can build a cross-platform desktop presence using web technologies.
Also aimed at power users is eBay desktop. Ryan Stewart has an excellent overview of this, but essentially eBay desktop allows eBay users to operate their auctions using an Apollo-based desktop app – which offers improved caching, real-time product availability notifications, and auction updates.
Another example Mike and Christian showed me was Adobe Media Player (nicknamed Philo, after one of the inventors of TV). It is a web TV app, and a competitor of sorts to Microsoft’s Windows Media Player, but Mike said that it is essentially a video aggregator (using RSS) and player at heart. Via Apollo, content providers can brand the Adobe Media Player using special RSS code. Compare this to iTunes, which is strictly an Apple branded experience. Adobe Media Player also allows content providers to deliver ads in the RSS feed, including overlays (where ads are inserted into the video itself).
Conclusion
End users probably won’t see the full potential of Apollo until it goes into public beta in US summer, which should prompt more developers to build on it.
It’s clear that Adobe sees a bright future for web apps outside the browser, although with around a 95% penetration rate for Flash on worldwide computers, the browser is still going to play a key part in its plans. Adobe is also careful to emphasize that Apollo can complement the browser, as well as act as an alternative to it. Meanwhile Microsoft is also creating an extensive platform for desktop apps, but it too is still betting on the browser to be a key part of its ecosystem. In Microsoft’s case, it has the dominant browser on the market (IE has 80+% market share) and Silverlight is a browser plug-in (similar to Flash). Both Adobe and Microsoft seem to want to break free of the browser, but on the other hand both have dominant browser-based technologies to leverage (Adobe with Flash, Microsoft with IE). It’s worth noting also that Adobe sees itself as much more committed to web technologies and cross-platform support than Microsoft, which for obvious reasons wants to leverage its Windows dominance.
What do you think of Apollo and its chances in the near future? It is a fiercely competitive market, with Adobe, Microsoft, Sun, Google and others all active – and each has a differing vision for web app deployment. Google is still very much focused inside the browser, whereas Adobe and Microsoft have made divergent moves to go outside the browser (but both with one foot still planted firmly in the browser). Let’s not forget that Mozilla and the other browsers are enhancing their products at a furious rate. It’s a key point in the evolution of web apps – so who do you think has the inside running at this stage?
Thanks to Mike Chambers and Ryan Stewart for their feedback on this article, prior to publishing.
UPDATE:This week’s poll follows on from the conclusion in this post.
