Tag Archives: native code

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.

No native code development on Windows Phone 7 says Microsoft – so what about Flash?

Windows Phone 7 is a managed code platform, we’ve been told at Mix10 in Las Vegas. Development is via Silverlight or XNA; there is no native API.

Of course there is a native API; the question is more about what code is allowed to access it. Still, in the press briefing the spokesman was clear that native code development will not be supported.

What about projects like Adobe’s Flash runtime, which both Microsoft and Adobe have said is planned, or at least (in Microsoft’s case), not blocked – although we already know that Flash will not be available in the first release.

All my spokesman would say is that nothing has been announced about that.

My suspicion is that in reality certain privileged vendors will be able to, in effect, extend the operating system with native code libraries. Adobe could be one of those; so too could a company like Rhomobile, which has a cross-compiler for a variety of mobile platforms. So I doubt that Microsoft has yet given us the full story here.

Update: The latest on this is that Microsoft’s Charlie Kindel says that Adobe will have special native access for Flash, but that no other vendor will have that privilege. This still does not make sense to me. Let’s suppose that Windows Phone 7 is a big success. What justification could Microsoft have for supporting the Flash runtime but not the Java runtime, for example? I suspect that Microsoft is chasing the Flash checkbox to one-up Apple; but if Adobe gets native access, others will no doubt follow.