El panorama actual de dispositivos móviles, ha quedado, podríamos decir que reducido a iOS de Apple, Android de Google, y Windows Phone de Microsoft (con el permiso del marginal TabletOS de RIM).

La evolución ha llevado a que el código bytecode sea el que domine estas plataformas. Java para Android, y .NET para Windows Phone. La excepción es en este caso Objective-C en iOS.

En general defiendo el código nativo, pues por rendimiento, y a pesar de las mejoras que sucesivamente se implementa en la VM de Java y en el CLI de .NET, éstos están todavía lejos del código nativo en cuanto a velocidad del código, y consumo de memoria. Puntos que son especialmente importantes en dispositivos móviles, donde los recursos de CPU, memoria y almacenamiento son bastante limitados, y donde sobre todo, el uso de CPU va invariablemente condicionado al uso de la batería.

La apuesta de Apple en iOS, me parece atrevida, todos sabemos que es más difícil desarrollar código nativo que requiere liberar aquello que se reserva, y donde facilidades aparte, no hay un Garbage Collector como tal. Sin embargo, los números en cuanto a Apps disponibles, y número de desarrolladores, no sustentan de momento esta afirmación, y a pesar de ser de desarrollo más complejo, la comunidad iOS, supera a la de Android y Windows Phone. Y es que, se puede criticar el uso de Objective-C, más si consideramos que C++ es un lenguaje maduro, muy estandarizado, portable, con un elevado rendimiento, y sobre todo conocido; pero en mi opinión, la decisión de usar código nativo, es la correcta.

Naturalmente, entornos puramente interpretados como PHP, Perl o Python tienen grandes ventajas en lo que a velocidad de desarrollo se refiere, pero no llegan al nivel de eficiencia del código nativo. Estos lenguajes, permiten desarrollar y probar de inmediato, no hay que compilar, y no hay que generar archivos intermedios.

El siguiente paso, serían los lenguajes que compilan en tiempo de ejecución, como las últimas versiones de las máquinas virtuales de Javascript, ASP.NET o JSP. Aquí, se pierde algo de tiempo al compilar el código fuente a código nativo o bytecode, pero al menos es transparente para el desarrollador, y obtiene unos rendimientos aceptables.

La nota disonante, sería .NET (para escritorio, y para dispositivos móviles), Java (para escritorio, applets, y servlets), ActionScript, etc, que no dejan de ser entornos que ejecutan bytecode, pero que además requieren que el desarrollador deba compilar y generar paquetes cada vez que quiere probar. Es decir, requiere tiempo e interacción para compilar, pero no generan un código tan eficaz como el nativo.