Adobe AIR is user-hostile compared to native apps says BankSimple CTO

Alex Payne, CTO at BankSimple, has written an analysis of Adobe AIR from the user’s perspective. The scenario: his team was looking for a an alternative to Campfire for group chat, and selected HipChat. They liked the features of HipChat, but not the desktop app, which is built using Adobe AIR:

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

Payne investigated further and came to the conclusion that users prefer native apps; and that cross-platform toolkits are for the benefit of software companies not users. Echoes of Steve Jobs’ Thoughts on Flash:

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps.

And lest you think this is bad for AIR but good for Java, note that Payne adds:

For anyone who used a computer in the 1990s, AIR probably brings back scarring memories of Java apps: slow, ugly, inconsistent, awkward.

I was also reminded of Evernote’s experience with .NET versus native code, which I blogged here.

Payne is not all wrong, neither is Jobs. That said, the distinction between what is good for users and what is good for developers is not absolute. Maintaining a single cross-platform code-base, for example, is good for both users and developers, because it reduces bugs and assists feature-compatibility across platforms. It is also good for users of minority platforms who might otherwise have nothing.

Another question: how many of the issues Payne identifies are inherent to using AIR (or another cross-platform runtime), and how many are implementation issues? It is impossible to know without drilling into the details; but I don’t believe that all AIR (or Java, or .NET) apps have “lousy performance”.

It is true that ActionScript code is slower than Java or .NET code, and much slower than compiled C/C++, but speed of script execution is not always the performance bottleneck that users will notice most.

This is seemingly one of those never-ending computing debates; but a post like Payne’s is a reminder that neither Adobe AIR, nor any cross-platform runtime, is a perfect solution to the challenge of multiple client platforms.

VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. Native apps better than web apps? That’s silly talk says PhoneGap president
  2. Google Native Client: browser apps unleashed, or misconceived and likely to fail?
  3. Native code interop in Adobe AIR vs Microsoft Silverlight
  4. No Java or Adobe AIR apps in Apple’s Mac App Store
  5. Is Appcelerator Titanium native? And what does native mean anyway?

2 comments to Adobe AIR is user-hostile compared to native apps says BankSimple CTO

  • Non-native (and “custom” native) UIs always seem to get details wrong, like this observation from Jan Miksovsky:

    http://miksovsky.blogs.com/flowstate/2011/01/custom-context-menus-always-forget-to-support-right-clicking-on-the-context-menu.html

    Or Java UIs which don’t work with screen readers, and have no context menu for scroll bars.

    These details seem unimportant to 99% of people. But there are thousands of them, and the same 99% will probably encounter at least one such detail which bugs THEM.

  • As a user, there is nothing more annoying that opening up a often used program on a different OS and find out the program is missing a feature that you are dependent on, because that code for that feature hasn’t been ported over.

    Also native UIs can be built into AIR, it just takes time to do so and many either don’t do it or are not given the time to do so for the project. Also on the flip side, there’s many native applications that still manage to do non-native custom UI’s.