The first thing I had to ask was: why?
At first glance, Apollo is a re-invention of the wheel. Cross-platform development has been easily accessible using many popular scripting languages (Python, Ruby, Perl, and even PHP) and a cross-platform GUI toolkit (GTK, Qt, tk, etc). Every scripting language has cross-platform IO libraries, and rich libraries for accessing web services, binary sockets, platform-specific features, and more. Many of the GUI toolkits have design applications such as Glade. Adobe has apparently gone to some lengths to include such features in their Apollo product. It seems to me that they’ve wasted a lot of time and money; developers are likely to get more flexibility from the open-source solutions that already exist.
At the moment I believe Adobe is pushing this product as a way for novice programmers and designers to develop desktop applications. I’m not really sure how comfortable I am with this idea. On one hand, Adobe may be giving access to forms of expression previously cryptic and difficult to reach (while I think developing desktop applications with Glade and Python is a fluid and easy endeavour, I suppose I should assume that it’s in fact a difficult task for a web designer type that has only familiarity with PHP, but not programming as a whole). On the other; it may introduce a generation of developers who develop applications without understanding the underlying technology. Personally, I think a developer is more valuable if they are passionate enough about programming to learn how to build their own desktop applications using the wide array of technologies they have to choose from. The fact that the end result could be of higher quality than an Apollo application is a bonus.
The drawback I see for Apollo applications is the runtime they require to execute. It’s like requiring your target users to download the Java JRE or install an interpreter. It’s a small, albeit annoying, UX issue — users may eventually get comfortable with it, but unless there’s a compelling reason to install yet another program and keep it up to date to use your application; you may be turning away a significant potential user base.
At least with many interpreted languages and GUI toolkits, the developer has options. They can try to maintain a high level of operating system independence by requiring users install the interpreter their application will require. Another option is to compile your application into a system-targeted binary — py2exe is a great example. It’s also possible with languages like Perl and Python to write and compile performance-heavy pieces of an application in a lower-level language like C. These options are good things and shouldn’t scare away potential developers — many developers worked hard to bring other programmers the benefits of these higher-level tools. The benefits a potential developer can bring to a project by being able to at least understand the underlying technology they are using are exponential.
Ultimately, I feel that Apollo will produce a generation of ignorant developers. Maybe it’s elitism. Maybe it’s the underlying dream of technology — for anyone anywhere to be able to do anything. This could be an early sign telling us that one day we won’t have hierarchies and the concept competition will one day be erased from our minds. I could be terribly close-minded in feeling that developers should understand the tools they are using before they start building houses. The success or failure of Apollo won’t be a clear indicator, but it may be an omen.
Apollo itself may be just the wrong solution or the perfect one for the desktop. However, from my first impression it seems like they are developing it for the wrong reasons; and with a little bit of pomp. It’s almost like Adobe isn’t even aware of the software landscape beyond their corporate walls. Maybe they are though. We’ll have to see how deep the market penetration this new application framework will get.