Question: Do intermediate layers always produce substandard applications? Answer: No

This blog post was originally written by Patrick Broman and explains how powerful and  important a cross platform framework is when you produce Mobile applications.

The Gartner group rates cross platform development tools very important to reach out and maintain Mobile Applications.

"Cross-platform mobile development tools will become more numerous, more capable and more popular in the near term. Architects, developers and strategists should consider such tools to deal with the growing challenge of supporting mobile applications on several platforms" Gartner 2 February 2010.

This is what Patrick Broman wrote

Last month the internet was buzzing with discussions about 3.3.1, the new section in Apple's iPhone SDK license agreement stating that all applications must be "originally" written in one four programming languages approved (and incidentally, provided) by Apple.
Allegedly, Steve Jobs himself has said the following in an e-mail conversation with blogger and developer Greg Slepak:

"We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform."

A lot of more or less philosophical questions have been raised, and I won't go into all of them - instead, let's take a closer look at the arguments against these so-called "intermediate layers".

There are a lot of sound arguments, and there's a lot of  historical data to support them. However, that's not the same as them being true for every possible solution out there. Let's look at them one at a time, and see how MoSync stacks upp....

Abstraction invariably imposes overhead and hurts performance
-------------------------------------------------------------
With any cross-platform solution, the differences in how system APIs are accessed must somehow be abstracted away. In many cases, this is done by adding a "wrapper" layer that ensures that all such functionality can be accessed through a common interface. This can be done in several ways:

Dynamically, where the correct native invocations are carried out through series of expensive virtual function calls, and possibly involve complex marshalling of types.

Statically, where the appropriate implementation of the abstraction layer is decided upon during compile time, reducing the function call overhead to a simple CALL instruction. However, argument type conversions may still incur a significant pentalty in some cases.

Transformatively, where invocations of the abstraction layer's functions are actually _transformed_ into corresponding invocations of the underlying APIs, without any indirection.

MoSync is capable of all three approaches, and normally uses well-chosen defaults to select the appropriate one. These can of course be overridden in special cases. So, whenever performance considerations outweigh the benefits of dynamicity, the overhead can be eliminated.

Abstraction condemns developers to mediocricy and least common denominators
---------------------------------------------------------------------------
Conventional wisdom says that if you want to use the exact same codebase to target multiple platforms, you are confined to using only those features that are available across all your targets. In other words, you can do no more than what is possible on the crappiest of the target platforms.

This is of course not true. First of all, if we for instance limited ourselves to only making use of input mechanisms that are available on both a Sony Ericsson k700 and an iPhone, we would not be able to do any input at all. That is clearly unacceptable, so we conclude we must make our app support both touch input and keypad/joystick input.

Now, you might be wondering if we're departing from the premise of a single codebase by supporting different input mechanisms. We're not. We still have a single codebase, only it handles multiple types of input. Granted, some code paths will never be excercised on the iPhone and others never on the k700, but it's still one codebase.

So, it's quite possible to expose the full set of features, from the simple, widely available ones to the most advanced and rare ones. There's no inherent limitation in the concept of a cross-platform solution that precludes that.

One might argue that having to deal with different code paths defeats the puropuse of having a cross-platform solution in the first place. Isn't the idea that you shouldn't have to worry about platforms being different? The answer is "kind of". If a cross-platform toolkit does nothing but remove every non-essential difference, leaving only those that are truly essential to be dealt with by the developer, it has still completed a Herculean task and saved the developer a world of headaches.

Is it really an abstraction then, when it allows for doing things that will not work on some platforms? Yes! While it will not magically turn your k700 into a touch phone, it will let you deal with touch events exactly the same way on both iPhone, Android and Windows M obile. That k700:s don't have touch screens is an essential difference; that various touch APIs are different but functionally equivalent is not, and can thus be abstracted away.

MoSync exposes as much as possible of the features available, and provides facilities for managing their availability.

Cross-platform toolkits will always be playing catch-up with new features
-------------------------------------------------------------------------
The argument is roughtly: Assuming a cross-platform solution becomes sufficiently popular, it will in practise have the power to dictate which features are available to developers, rather than the hardware and OS vendors.

First of all, I would argue that adding support for features more or less instantly as they are made available is crucial for any cross-platform solution that hopes to become sufficiently popular. The majority of developers will settle for nothing less.

Secondly, the ability to add new features should not be dependent on the original supplier of the cross-platform toolkit. Rather, it must be possible for any member of the community to do so. In the case of MoSync, this is achieved by the SDK being open source, and extensibility being built in from day one.

Of course, we're always going to make sure all of the big, popular features are available as soon as humanly possible, but this way we make sure than even the obscure, niche features can be made available if they're needed.

Cross-platform toolkits don't produce applications that look and feel native
----------------------------------------------------------------------------
In many cases, this is true. And whenever it is true, it sucks. Anything that requires the user to have a proprietary runtime preinstalled in order to run it is guilty. Anything that tries to provide an indentical user interface regardless of where it's running is going to provide substandard user experiences. Indeed, many existing cross-platform systems get busted on this one. However, MoSync is not one of them.

When you build an application with MoSync, targeting a JavaMe feature phone, you get a jar file. When you go for Symbian, you get a sis file. Windows Mobile, you get a cab file. And so on. There's no way you can tell that it's not a regular native application.

We're working hard to provide access to native UI widgets on most of our platforms. Let's face it - you can't really say you support iPhone unless you provide access to its unique user experience.

Intermediate layers can have bugs, and developers have no control over them
---------------------------------------------------------------------------
When writing apps natively, you have full control, and whatever problems arise, you have the means to solve. Except if the bugs are in the OS or the APIs, or the runtime libraries. Or the drivers. Or the hardware itself. So, the last thing you need is another layer where things can go wrong, right? Well, not exactly.

First of all, a well-tested cross-platform framework will help you avoid most of the bugs and problems you would run into on lower levels, effectively AT LEAST cancelling out any additional  ones potentially introduced by the framework itself.

In MoSync's case, of course we have bugs. We test a lot, and fix them as soon as we can, but nothing is ever 100% bug free. BUT - you DO have full control over them, again because we're open source. If there really is a showstopper bug, you CAN fix it yourself if need be.

In conclusion, there are a lot of things to be worried about in the general case of cross platform solutions. At MoSync, we've seen a lot of really bad abstraction layers ourselves, but we build MoSync with a conviction that it doesn't have to be that way. So far, it's seems we're right!