Skip to content

What is "Apollo"?

Screenshot of Apollo eBay application

A couple people, one of you in particular, asked me just what Adobe’s Apollo is, pointing out that my post from Adobe Engage last week doesn’t exactly start out with a definition thereof.

Indeed, there’s plenty of room for explanation before <a href=""my usual arm-chair product management.

This InfoWeek piece has a good starting discussion:

[One of the ancestors of Apollo,] Macromedia Central was an early [version] of Apollo,” said Pam Deziel, director of the Platform Business Unit for Adobe. Apollo will allow developers to take applications built not only in Flash, but also in HTML, AJAX, and other Web development languages and create them to run locally on a user’s desktop, she said.

According to Sean Christmann, senior developer at EffectiveUI — a Denver-based company that has had an early look at Apollo — the technology acts as a wrapper, which makes it easy to take code from an existing Web application, wrap it in Apollo, and transfer it to the desktop. The key to making this transfer is Adobe’s Flex Builder tool, which developers can use to wrap their code with the technology, Christmann said.

What you can imagine here is the ability to move a Flash/Flex application from being the browser to existing and running on the desktop. The same could apply to self-contained XHTML/CSS applications. I haven’t seen a whole lot of the second apart from just wrapping a web page in an the Apollo equivalent of web-browser, but the functionality is in the Apollo framework.

A Desktop GUI Toolkit Built from Web Technologies

Moving Flex applications to the desktop is, to me, the core of what makes Apollo. “Flex applications” including using XHTML, CSS, and JavaScript as needed and desired as well. From the technical overviews I had last week, Apollo is indeed a “wrapper” on Flex and XHTML/CSS applications along with (obviously) the glue to tie those two together. Also, Apollo provides much more access to the desktop environment and underlying operating system than a web application would. That desktop access is currently to things like the file system, local devices, raw network sockets (right?), and other things a “purely” web-based application would lack or have severely limited.

Flex is an XML and ActionScript (Adobe’s JavaScript) based UI framework based itself on and “running in” Flash. The benefit of Flex is the ubiquity of the Flash player, aside from the (tragically) usual Linux hiccups (they say they’re doing, or will do, better).

Side-note: Run Anywhere

Adobe likes to besmirch the Java claim of “write once, run anywhere” saying that Flash/Flex is the real “write once, run anywhere.” The point being that there’s a common Flash runtime for every platform. There’s truth to that, and I’ve been impressed by the numbers of how rapidly the user base upgrades Flash. The “write once, run anywhere” story has always been a nice both for Java and, now, Flash/Flex, but as the Linux users reading this show, it hasn’t panned out yet for many, if any technologies, even for HTML. It’s only now that most applications can even deal with line endings between Windows, OS X, and *nix. Good luck with everything else.

That hefty does of cynicism done with, both Java and Flash/Flex are “write once, run pretty much anywhere,” which is a massive and commendable task on it’s own. Usually, the real phrase is, “write once, and if you’ve installed the right virtual machine, run anywhere.” This is why install and upgrading is a big deal, which Adobe is certainly paying attention to.

And, hey, just because it hasn’t been the case in the past doesn’t mean it can’t be in the future.

Interestingly enough, this last point is (to me) the key-stone in Adobe’s argument against open sourcing the Flash player. (Aside from the general point of “if it ain’t broke, don’t fix it” which is always compelling) As numerous commentators have said, that’s pretty much what we heard from Sun about Java from years. The playbook is again in effect ;>

Ain’t that just a GUI?

So, pulling back to the main thread, the point of Apollo is to build “applications” with Flex and/or XHTML/CSS/[Action|Java]Script. These applications “live” on the desktop, getting (some) of desktop benefits like the afore mentioned access to the local file-system and tighter integration with the native desktop windowing environment, e.g., a launch icon on the desktop or in the dock. And yes, there is security sand-boxing. The user interaction for this sand-boxing is limited to install-time only when the user approves the application; usability says this is all the user will tolerate. These applications act like web applications in so far as they’re very aware of and interact with the web, interacting with HTTP (and other) servers and even pulling in complete web pages, like Twitter.

Now, if you’re like me, your next thought is: “so it’s a desktop GUI framework, right?”

While that’s my conclusion, Adobe is edgy about declaring that outright:

  • First off, philosophically such a statement misses the point: Adobe (and Macromedia before them) is trying to create a new way of creating GUI applications. They’ve certainly done that, taking a clean break from the Microsoft and Java/Eclipse (and, yes, Cocoa for all you OS X nuts) worlds both in that the way in which you code these GUIs is different and in that the resulting GUI can look much, much different than a native GUI. Apollo wants to bring down all the benefits of a web application to a desktop application: easy install, (more easily) connected to the rest of the world instead of stuck in a silo, simplified development and (sometimes painfully so) user workflows. Of course, the point is to mix in desktop benefits like working offline.
  • Apollo isn’t done enough to be a full fledged desktop GUI system, it’s still 1.0. I tragically don’t have a handy list of the what Apollo can’t do on the desktop, but Adobe folks were always gracious to admit that it can’t do everything. One example is high-level uses of raw sockets like connecting to databases via ODBC or JDBC. Now, I have no problem with releasing incremental products at all. In fact, it’s what I advice. The problem for Adobe is that other people are not so nice: if they came out saying it was a desktop GUI framework, everyone would start flinging poo at them. This point is more important in the sense of causing a distraction that would cause Adobe to miss the window of opportunity to launch Apollo. They call it “FUD” as well. Of course, the future is a wide open space, isn’t it? I know Adobe would be happy to become a full-fledged desktop GUI framework (who wouldn’t?), but they’ve gotta ship sometime, and hence we have what we have. (Bravo on deciding to finally ship, even after several years and at least 3 major concept-iterations.)

All of this, esp. the FUD-avoidance, is why Adobe is desperate to create a third category of applications “between” desktop and web applications. It’s also why it’s so difficult for Adobe to articulate what Apollo is.

But, if you subscribe to my notions, there is no third type of application: Apollo is a web-aware and enabled desktop GUI framework. There’s nothing wrong with this. In fact, almost every vocal developer at Engage said “man, I really hope this works” meaning that they’d really like a new way of doing GUIs.

Desktop Buses

Another interesting aspect of Apollo is that it allows your application to not only run on the desktop and act more like desktop GUIs, but access the local machine like a “service” in the web sense. Now, that’s just common desktop GUI sense, but coming at it from a web application mind-set, it’s something new. Access to those “services” is currently limited (rightly so) for security concerns, but I get the feeling that Adobe wants to widen it over time.

That service pivot is one of the things that could make Apollo much more interesting. Several of us at Adobe Engage talked about the concept of accessing applications on the desktop as a service, and it seemed to solve many annoying data-interchange problems that currently exist. For example, accessing OS X’s or Outlook is currently a problem. Fixing that problem would add a whole new bucket of features to application development, web or otherwise.

The glue (“desktop middleware” or “desktop bus”?) to access all those desktop applications as services currently exists in proprietary silos: Microsoft has their OLE/COM/whatever-it’s-called-now, OS X has their Services stuff, and Linux (hopefully) has a common desktop bus for interchange as well. But, OS vendors have an incredible interest in keeping those desktop buses locked up. Roach motels make killer revenue, bub.

A third party like Adobe with an application framework not tied directly to those roach motel revenues could build such a desktop bus though. Now, that’s the kind of thing we hope for from open source projects as well who — theoretically — have even less bias to lock things up.

What’s Left?

I’ve left a large chunk out, and that’s the notion of how servers are involved in these applications via things like Flex Data Services. The point here is that you can expect most Apollo applications to interact with some sort of server, otherwise it’d be purely a desktop applications. I believe the security model disallows peer-to-peer interactions between Apollo applications (except as mediates through a server, of course); that seems like a potential tactical problem, but I haven’t thought on it too long.

My developer head was incredibly skeptical at first. But, at least I’d look into Apollo and Flex more that I know it better. A single-source for any technology always bugs me out, rational or not (see this sailor-talk filled episode of the podcast for more on that point). But, if it worked and was quick and easy to do, I’d assume it’d help make me money, so I’d look at it.

In all truth, speaking personally, I’d need free tools, probably built from someone other than Adobe, to really get into using Apollo or Flex. The price (any price) is certainly a sticking point, but the benefit I’d more be looking for was evidence of a thriving community which would point towards a tool-set that was portable to whatever environment I wanted to or was forced to work on. That said, I work on OS X, a very locked down OS, so I can be a bit two-faced when it comes to open-theory.

Now, how to combat that? I think that (some…a lot?) developers with my mindset would start to ignore their open-think if they saw their applications used widely and saw the delight users had with their UIs. Until Ajax, there really was no “cool” in UI design, and developers had taken to getting happy over how standard and “pure” any given framework was.

With the rise of OS X and Ajax, developers have “remembered” how rewarding it can be to have users who titter with joy over their user-interaction. Tightening up that feedback loop, and even making it possible, would be helpful for wining over non-Flex/Flash developers to Apollo. The question might be “remember when your users loved the UI’s you made?”

We’ll sacrifice a lot to be cool, which is good and/or bad depending on your motivations and desires.


Finally, I don’t have that many screenshots or screencast links. Once the Adobe Engage videos are up, there should be demos aplenty. But here are some in the meantime:

Disclaimer: Adobe, Eclipse, and parts of Microsoft are clients.

Technorati Tags: , , , , , , , ,

Categories: Community, Development Tools, Java, Marketing, Programming.

Comment Feed

10 Responses

  1. Great article.

    FWIW, though, I'm not sure that calling Apollo a GUI framework is appropriate. Seems to me like Flex is more of a GUI framework than Apollo is – to me, Apollo is more of a uniter of existing desktop/web frameworks. You could even say it has a function kind of like X-Windows – it is the frameworks layered on top of it that provide the APIs that most developers interact with most of the time.

    I'd like to hear more about the issues with the current Flash Player on Linux. Is this a reference to the "yea, but it doesn't run on 64bit/powerpc/etc." complaints, or are there a lot of people with actual compatibility problems on the Linux platform we do support? The feedback from people actually using FP9 on Linux has been almost uniformly positive from what I've seen.

    I also want to point out a few possible typos:

    * "web-based application would lack or have severally limited" – should be 'severely limited'
    * "but as the Linux users reading this show" – is that supposed to be "reading this know"

  2. Thanks for taking the time to write up a reply. I'm glad you liked it and I appreciate the feedback.

    Yes, you're right on about the GUI framework thing. My angle on explaining this was to someone who didn't already know Flex. From that angle, Flex is a sub-set of Apollo and, thus, Apollo has the characteristics of Flex. While they're not technically "the same," in explaining to someone who's just looking at the full package of Apollo, I wanted to keep it as simple as possible: hence saying Apollo is a GUI framework, rather than saying that Apollo wraps Flex, and that Flex is a GUI framework. Hopefully that simplification doesn't cheat the description too much.

    I don't use Linux as my desktop PC, so I can't speak directly to those concerns. But, people I know who do use Linux complain about it whenever the topic comes up. Steve has done a better job covering this than I.

    Now, I know that this has been "fixed" with F9 (right?), but I think the Linux world is still feeling burned by compatibility and is rightly still suspicious.

    The point in mentioning "write once, run anywhere" was to draw attention to the fact (perhaps strong diction) that there's still trust to be demonstrated here to (at least?) the Linux community despite the welcomed, recent fixes.

    I'm all for it, I'm just jaundiced: kind of like representative democracy 😉

    Thanks for the type corrections. I appreciate it 😉

  3. Thanks for clarifying. I'm glad there isn't some huge bucket of FP9 issues out there I hadn't heard about. I completely agree that, at a minimum, Adobe will have to consistently execute on its Flash Player Linux commitments for a while before trust is (re)gained.

  4. Hi Cote, sorry I missed meeting you last week, thanks for the write-up this week.

    Historical trivia:

    The phrase "author once, play anywhere" was popularized by Macromedia before in-browser Java arrived:

    Adobe Apollo was predated by Macromedia Central, which in turn was predated by the early Macromedia Shockwave project:


Continuing the Discussion

  1. […] ce moment, même si pour l’instant peu de personnes ont pu le tester. Vous trouverez ici une définition trés complète d’Apollo. La technologie permettra de prendre un code Flash, Flex, ou même […]

  2. […] Where do the topics for posts come from? Events I’m at, announcements and news, briefings I’ve had, ideas and suggestions, overviews of new “trends” and ideas, and increasingly (which I love) people asking me to look into or (further) explain something. […]

  3. […] I wrote last month on Adobe “Apollo,” my feel is more that Adobe is targeting the desktop GUI world rather than the web. Indeed, I can […]

  4. […] and back-end, respectively for an RIA approach to web-aware application development. Adobe has Flex/“Apollo” and LiveCycle Data Services (currently Flex Data Services, or FDS). Indeed, the LDS page is […]

  5. […] of softened my freak out when it comes to RIAs. First, my assumption is that most of these RIAs are a run at establishing new and better GUI frameworks rather than “taking over” the web. While web applications will do in most instances, […]

  6. […] on Flex ….. I wrote last month on Adobe ???Apollo,??? my feel is more that Adobe is … son of Zeus and Leto, and the twin brother of Artemis. apollo was the god of music […]