Adobe Apollo Blasts Off

Until today, Adobe Apollo was kind of like (the American TV series) Lost: an intriguing thing that many people watched, yet no solid conclusions could be drawn about what the heck was going on. But that's all changed now. Not only has a public developer Alpha of the Apollo Framework been freshly posted, but Adobe is also spilling the beans on just about everything Apollo has in store. Mike Downey, Adobe's Product Manager for Apollo, was kind enough to join me for a wide-ranging chat on what Apollo is and why you should care.

Kevin Schmitt: The first question I have, Mike, is a personal one: can you give me a brief introduction to you and your background, and how did you make the move from Flash to Apollo?

Mike Downey: Sure. I've been at [Adobe] via Macromedia for the last seven years working on Flash, and we've been working on Apollo for about a year, year-and-a-half now. While working on Flash, I kept talking about Apollo with customers all the time and feeling the excitement about it, and of course Flash is always exciting, but I kept feeling more and more excitement about Apollo and I just had to get involved in it. So I decided to see if I could go work on the Apollo project, and luckily that worked out, so in mid-December I jumped over to the Apollo Team, doing the same basic responsibilities—I'm product manager for [Apollo], and it's incredibly exciting. I've never worked on a product with as much anticipation and buzz, especially considering we haven't even released anything to the public yet, so that's pretty exciting. I've been meeting with customers for seven years, talking about what Macromedia/Adobe does, and I've never had a scenario where I could go in to a customer with a new idea or a new product, and in about fifteen seconds they're asking me how soon they can get their hands on it. And that's what Apollo is doing, so I knew I had to be involved with it.

Adobe's Mike Downey

KS: Well, that segues into my next question. You touched on it a little bit; there's been no release and not a whole lot of information yet on it, so give me the quick, 30-second "elevator pitch" for what Apollo is.

MD: There you go! So, that's actually why we're [talking] with you today, because the big announcement is that we're going to do our very first public release. It'll be what we're calling an Alpha release, as a public Alpha, and that will be released on our Labs site, which is labs.adobe.com, the same place where people are getting the Photoshop Beta. That's the exciting part—this is going to be the very first time that the public can freely go in and get Apollo and start building and start playing around with it. It's completely targeted at Web developers—we're focusing on developers for our public Alpha, so this isn't a consumer/end user thing. This is purely for Web developers at this point.

So, you asked to give you the quick elevator pitch—what is Apollo? We try and stay very consistent in how we describe what it is, so it's a very short description. Apollo is a code name for a cross-operating system application runtime that allows Web developers to leverage their existing skills and tools in HTML, JavaScript, Ajax—as well as Flash and Flex from Adobe—to build and deploy rich internet applications on the desktop. So basically, it's a runtime that will run on Mac, Windows, and eventually Linux. It'll have one set of APIs, and any Web developer—and you know there's millions of them—any Web developer can use all of the skills and knowledge and tools that they already have. They're not learning any new languages, they're not learning any new frameworks, anything new there, [using] existing skills that they already have, and all of a sudden now they can actually build desktop apps. Very, very powerful, full-featured desktop apps. That's why everybody's so excited, because this isn't something so different and so new that they're going to have to learn all these new things. This is something that is an extension of the work that they're doing now, but a very, very powerful one.

KS: Now, is PDF part of this as well?

MD: Absolutely. So, within Apollo you'll be able to actually hook into the Adobe Reader and fully visualize and control PDF files within your Apollo application. Now, the PDF reading capability won't be built into the Apollo runtime; it will link into the Adobe Reader.

KS: OK, so that's an extra install on top of whatever the Apollo framework install ends up being, correct?

MD: Right. So, the Apollo runtime itself will be between 5-9 megabytes. Really, really small. Then, if you want to use PDF functionality the user just has to get the Adobe Reader. It's a separate install.

KS: OK. So here's a follow up on that. I'm speaking from a background as a multimedia producer and as someone who still manages to put out offline CD ROM-based products every so often, and have historically used a combination of Flash and Director for something like that. Would that sort of application fit into what you can do in Apollo?

MD: Well, I think the type of applications would be similar, and of course, supported, in Apollo. So things that you might have done as as CD ROM or Director application in the past, you'll be able to build that same type of application in Apollo. What we're focusing on, though, is building full-fledged desktop apps, the only limitation being that you won't have needed extensibility for using a Windows DLL library, or something like that, because we want to maintain consistency. So we want every application to run the same on every platform. That's why we don't want people building Windows-only Apollo apps—that would detract from what the value of Apollo is to begin with.

So actually, let me give you [an example] of what people are building. We have a private Beta; we've been working with some customers very, very early on just to help us test as validate the platform and get some partnership going, [one of which] is eBay. We've been working with eBay for a while now, and we helped get them in touch with a really great small development agency that has a lot of really advanced Flash and Flex expertise. That agency is called effectiveUI, and effectiveUI is working with a team of in-house Flex developers at eBay building what they call the eBay Desktop, and the code name for the project is San Dimas, which is a reference to Bill and Ted's Excellent Adventure. So the San Dimas Project at eBay is basically allowing eBay to build a full desktop application experience and test out an entirely new user interaction model for accessing eBay's core services, and they can do it all without spending a dime on back-end infrastructure.

Figure 1: In eBay's not yet released "San Dimas" Apollo pilot application, users can search by keyword and retrieve an easy-to-navigate list of results with images, prices, and remaining time for the auctions.
(image and description courtesy Adobe PR)

MD: They're able to use their existing Web services that are already there, that access all of eBay's core services. They can build this desktop app, send it out to the end users' machines, so eBay's not paying for hard drive space, they're not paying for memory, they're not paying for CPU, it's all going out to the end user's machine, and they're able to test an entirely new UI for getting eBay information. So they're pretty excited about the project. They've told us, and mentioned publicly in a variety of demonstrations that they've done, that the two big areas of interest for eBay with regard to Apollo were that one, what I just mentioned, which is eBay can actually try out new services, [a] new UI, just simply new ways of getting at [and] visualizing auctions without spending any money on their infrastructure, and without risking their existing business. Now, if they redesigned eBay.com right now they'd have a lot of risk involved—people get confused, they don't know how to access the service—so Apollo is going to let them try something entirely new. That was one of the big keys. Then the other one is a feature that we're going to be putting into Apollo that allows you to tie into system alerts and notifications. So, for eBay, their number one goal is to get all eBay users to use eBay more often, and they've actually done some pilots of different programs. One of them involved a toolbar that eBay did that allowed them to issue notifications and alerts when, for example, you're outbid on an auction. And they found that in those situations that users' participation with eBay increased by 10x just by having alerts. So Apollo does that, so eBay Desktop will alert you when somebody's bid on your own auction, or when you've been outbid on an auction, and that's huge for them. That drives a 10x increase in traffic and business for them.

Figure 2: Sellers using eBay's not yet released "San Dimas" Apollo pilot application can photograph their items using a Webcam (if connected) or simply upload images from the hard drive. Sellers can also see all past and current auctions on the same screen.
(image and description courtesy Adobe PR)

KS: That sounds like pretty interesting stuff. It's almost hard to grasp just because something like this really hasn't come along in quite this fashion, so I can see where the buzz is coming from.

MD: Yeah—this is very new. The closest you can really, I think, get to the idea of Apollo would be Java, right? But Java never really made it on the desktop. In fact, it didn't make it at all, and I think there's a variety of reasons for that. One of them is that you had to be a Java developer to begin with; it's a whole new language and a whole new framework. But I think, actually, the biggest key reason [it] didn't really work for desktop apps is that every Java Virtual Machine was implemented differently, and they had fragmentation of their runtime. So, if I wanted to run a Java application I had to go download a very specific JVM, and they were usually pretty big—over 20 megabytes. So that immediately just completely killed the prospect of Java working for desktop apps. But Apollo is completely different. Apollo [is] 5-9 megabytes, so very small, and every release of Apollo will be incremental so that we'll always have backwards compatibility. So all you need to know is that the user has a certain version of Apollo, and that's it—it'll work.

KS: I'm sort of curious at this point—you're talking about having HTML, CSS, JavaScript, Flash, and the PDF player all working together. Is there some sort of a glue language where you can get these all talking to each other? How's that going to work?

MD: That's a big key. So down at the technical level, one of the biggest values to a Web developer is that in Apollo we have the full capabilities of the Flash Player, plus more. We've added more capabilities to it that are specific to Apollo. You have an entire HTML engine built into it as well, so we've taken the WebKit engine, which is the same engine used for Apple's Safari browser, that's fully integrated into Apollo. And, of course, we have the Adobe Reader capabilities. The way we've integrated it is at a native level so that when you're writing an application for Apollo, whether it's a HTML-based application or a Flash- or Flex-based application, you can have full access from your programming language—whether it's ActionScript or whether it's JavaScript—you have full access to the capabilities of the other engine, natively. You've never had that before. So, from ActionScript, I can actually access the entire DOM of the HTML engine built into it. From JavaScript, I can access everything in Flash Player, so from JavaScript I can create a Movie Clip, or I can put a blur on it, or whatever I want. So that's completely new—you've never been able to do something like that before. So it's basically all the capabilities of a browser added to all the capabilities of the Flash Player in one native environment.

KS: So it sounds like there's not a new middle language that you've invented for this—you're using the languages that are native to the specific technologies, and then having them be able to communicate with each other.

MD: That's the value. That's why this is such a big deal. Because, like I said earlier, to build an Apollo app, I don't have to learn a new language. I don't have to learn a new framework. I just keep using the stuff I've been using as a Web developer, and that's who this is targeted at. It's targeted at Web developers. Whether you're Ajax or whether you're Flash or Flex, you just keep building using the tools and the language and the skills and even the existing code libraries that you've already written—you can repurpose those and use them for building a desktop app.

KS: Is there any sort of reverse effect to talk about here? You're going to have the Flash and the PDF players and the WebKit engine feeding into Apollo; is there any sort of feedback loop going on? Is the direction of Apollo necessarily going to affect the direction of at least the players you have control over, like the Flash and PDF viewers?

MD: Right. So, I assume you mean the relationship between the work we add to Apollo and how does that get integrated in with the Web player and the Reader, and things like that?

KS: Yeah, and whether future Apollo development is going to have changes on the standalone players as they develop as well.

MD: Ah. Yeah. So basically, yes. What's going to happen is we will add capabilities to the Web player that will be new, and we'll take that and we'll roll it into Apollo, right? The Flash Player Team right now [is] working the next version of the Flash Player—Player 10—they're going to do a lot of really big, huge, cool features in that. Once they've got that running and stable, we'll take that and we'll integrate it into Apollo for our next release. So we'll inherit all the Web capabilities, and then as we do things that are specific to Apollo, where they make sense at running inside of the security sandbox of the browser, the Player team will take that code and integrate it into the Web player. So there is sharing of code between [us], and that [goes for] the Adobe Reader team as well. But it's only really the stuff where it makes sense to go down to the browser, because obviously we always have the security sandbox in the browser, so there are things that we can't do. Most of the features we're adding to Apollo that are Apollo-specific are features that only really make sense outside of the browser. But there will be a few things that'll make sense to roll into the Web player.

KS: So now I'm sort of stuck on the full desktop application part of it, so I'm thinking, how close is this going to be to real desktop apps? I mean, are you going to be able to take an Apollo app and have it generate out documents, and have those documents be double-clickable and they'll open in the Apollo app?

MD: Yep. Yeah, you're going to be able to do all of that. So here's the only limitation that you'll hit versus a native desktop app like you'd write in, like, C++. In Apollo, at least for 1.0, we're not planning on allowing native extensibility. So if you have a DLL for Windows that does CD ROM burning, Apollo doesn't have an API for burning a CD ROM, so you won't be able to do that, right? That doesn't mean we won't add that capability to Apollo in the future, but if you want to hook into a native library, we're not going to allow that for 1.0. And the primary reason for that is we don't want fragmentation of the runtime. We don't want a bunch of Windows-only Apollo apps. The value of Apollo is that you write one app and it automatically runs on every platform. So that's one thing you wouldn't have. The only other thing that's going to be a big difference is we don't have native hardware support for graphics acceleration. We have a layer of DirectX and OpenGL support, but you wouldn't use Apollo to build World of Warcraft. You know what I mean? If you really need to get into deep hardware access or USB devices, we're not going to have that for 1.0, but those kinds of things we will be doing over time in the future.

KS: It sounds like you'll have some level of OS integration in terms of things like file I/O, and other things like that?

MD: Let me give you a few of the things that we are going to do so you have some of the high-level features. So, full file I/O. You'll be able to read and write files, you can generate Word docs, you can generate Excel spreadsheets, PNG files, whatever. You can do all of that in ActionScript 3. So you'll have full file I/O. You'll have full drag-and-drop support, so you can drag-and-drop from the desktop into an Apollo app, or the opposite direction between the native app and the Apollo app, so all the drag-and-drop support will be there. Cut and paste, so you'll have clipboard access. Multi-window support, so you'll actually be able to have multi-window applications, which is something you can't do in a browser now. Let's see... local data storage, so we'll have a pretty complex capability for storing and manipulating data locally. APIs for knowing when you're online and offline, so I can make an app automatically tell you, "hey, you're offline now," and then switch modes, start caching data, or whatever. So as a programmer, I can actually know and account for when somebody goes offline, and then I can also know when they go back online again, and I can automatically sync data, which is something that eBay is doing. Another one is, and I think I mentioned this earlier, Apollo will allow you to tie into system notifications, so you'll be able to issue alerts and notifications of events when something happens, so that'll be pretty popular. One of the other features is full custom chrome support, so you can make your Apollo application look like anything you want. It can be non-rectangular, it could be circular if you want. You have full control over the chrome and transparency.

There's probably a whole list of other features I'm going to forget, but let me clarify [something]. So for the Alpha, most of the core functionality will be in there. The HTML engine is about halfway done, so some things will work, and some things won't work. For [the] Alpha, we haven't yet added in support for running Flash inside of HTML, but we will be adding that, just not for the Alpha. We don't yet support PDF, but that's coming. The Alpha won't support drag-and-drop yet, so we're getting to that. It also won't have support for transparency in HTML, but most of the other big things should be working. You're not yet able to register a file extension, but you will by the time we ship 1.0. So, I can have an Apollo app say, "I own .flv," so anytime I click on an FLV file it could launch into a little media player.

KS: Well, Mike, this all sounds pretty cool. I know we only have a couple minutes left, but I just wanted to say that from a developer standpoint this sounds pretty darn awesome, especially from someone who does desktop-based stuff and not a lot of browser-based stuff, that this is definitely something worth diving into. I guess it's all going to depend on what the final adoption rate is, but if it's anything like Flash and PDF, that shouldn't be much of an issue.

MD: Yeah, I like to tell people [that] if any company on the face of the planet can distribute software to a lot of people, it's Adobe. You know, we've done more than even Microsoft has, so that's an advantage going into it. But this is also a new beast. With Apollo, I'll be able to deliver a native installer that includes both the runtime and my application, so I have a lot of flexibility as a developer. I can tell people, "hey, just download this native installer," and it has the Apollo runtime, and it has my app, or I'll be able to automatically detect whether they already have Apollo or not.

KS: Mike, thanks a lot for all this information!

MD: No problem.

And there it is, ladies and gentlemen. Thanks again to Mike Downey for the time and the plethora of data on Apollo. And yes, I got my gushing geek on a little bit, but probably for good reason. The only other item of interest that wasn't covered in our interview was that of price. What's Apollo going to cost? The answer, apparently, is nothing: both the Apollo runtime and SDK will be free to download and use. Adobe plans to monetize Apollo through what they hope will be added sales of Adobe authoring solutions and server products in order to take advantage of the Apollo platform, as well as the sale of actual derivative applications built using Apollo itself.

So what are you waiting for? Head over to the Adobe Labs site and check out the Apollo Alpha for yourself, which should be available by the time you read this.

Filed under: Feature on March 19th, 2007
Tags: Adobe, AIR, Apollo

^ Top of Page

Got Feedback? to send an email. I'll do my best to answer. Really.