Recientemente leí este interesante artículo y este otro en donde se especula que el procesador (CPU) del iPad, al que Apple llama el "A4", no es un procesador con la arquitectura ARM basado en un núcleo ARM Cortex A8, como hasta el momento todos especulan, sino que en realidad es un procesador propietario basado en dos núcleos de PowerPC basados en un procesador PA Semi PA6T, y eso me puso a pensar profundamente...

Primero que todo, recuerden que Apple compró la empresa PA Semi en el 2008, una empresa especializada en chips de alta eficiencia energética y de alto rendimiento basados en la arquitectura PowerPC, razón por la cual en mi predicción #5 para este año 2010 que hice el año pasado escribí:

"Otro elemento que podría jugar un papel importante es que quizás este [el iPad] sea el primer dispositivo que veamos utilizando chips fabricados por Apple, después de haber comprado la empresa PA Semi, compuesta por algunos de los mas talentosos diseñadores de microprocesadores de la industria."

De ser esto cierto, esto explicaría por qué el iPad se siente como el dispositivo multi-táctil mas rápido jamás salido al mercado, y de por qué se siente al menos el doble de rápido que el iPhone 3GS (que de por sí es el doble de rápido que el iPhone 3G).

Sin embargo, se ser cierto esta especulación, esto significa también que el iPad se pondrá muchísimo mas rápido aun, pues por el momento se especula que en realidad está ejecutando aplicaciones en modo de emulación ARM, similar a como las Macs recientes con procesadores Intel x86-64 emulaban a los procesadores PowerPC durante la gran transición entre esas dos arquitecturas.

Como explican en uno de los artículos que referencié al inicio de este artículo, eso explicaría por qué Apple en su nueva política de uso de las herramientas de desarrollo para el iPhone, iPod Touch y iPad, exige que solo se puedan utilizan herramientas Xcode de Apple para desarrollar.

¿Por qué? Por la misma razón que Apple recomendó el uso de XCode durante la transición entre PowerPC y x86: Si los desarrolladores de software se apegaban a las herramientas de Apple, y a los APIs (interfaces de programación) estándares de Apple, el proceso de cambiar una aplicación de la arquitectura vieja a la nueva era tan sencillo como simplemente recompilar la aplicación eligiendo crear un binario universal para PowerPC y x86, lo que facilitó enormemente la transición.

Pero he aquí la parte que me hizo pensar...

ACTUALIZACIÓN del 22 de Junio 2020: Poco más de 10 años después de esta predicción que hice, Apple anuncia hoy que migrará sus Macs a sus propios microprocesadores ARM, utilizando como medio de transición precisamente la técnica que expongo en este artículo por medio de la herramienta XCode.

Por años, desde los tiempos de la IBM VM, pasando por todo tipo de técnicas desde el JVM (Máquina Virtual de Java) hasta interpretadores dinámicos de Perl o Javascript, el mundo del software ha estado en una cruzada por buscar la forma ideal de crear una forma universal de desarrollar, independiente de hardware.

Pues creo que Apple muy bien se ha tropezado con una gran solución al problema, y es una combinación de Xcode y el App Store (la Tienda de Aplicaciones del iPhone, iPod Touch y iPad), y se trata de lo siguiente...

Hoy día sabemos que existen varias maneras de crear un programa que funcione en mas de una arquitectura, sin embargo estas se pueden resumir en las siguientes maneras:

1. Compilación de APIs a código nativo, que es lo que sucede cuando uno programa en C o C++, en donde por medio de varios flags (banderas, indicadores) uno compila un código y librería de funciones a una arquitectura específica. Esto se utiliza mucho por ejemplo para crear distintas versiones de Linux para distintas variates de arquitecturas de hardware, y esta es la forma mas difícil de crear código multi-plataforma, aunque produce el código mas eficiente en la mayoría de los casos.

2. Máquinas Virtuales, en donde el código se compila a un bytecode intermedio, y después es o (1) interpretado en tiempo real o (2) compilado dinámicamente a la arquitectura local en casi tiempo real. Esto es lo que hace Java, es una forma bastante fácil de crear código multi-plataforma.

3. Interpretadores, en donde se escribe en un lenguaje de alto nivel (como Perl o javascript) y el código es o (1) interpretado en tiempo real o (2) compilado dinámicamente a la arquitectura local en casi tiempo real. Esta es la forma mas fácil de crear aplicaciones multi-plataforma, pero quizás la que produce el ejecutable menos eficiente.

Sin embargo, Apple parece haber creado una manera alternativa a todo esto, que combina lo mejor de todos los mundos, y el truco está en el App Store y su relación con el sistema operativo iPhone OS.

Lo que sucede es lo siguiente: De vez en cuando, Apple ofrece una nueva versión del iPhone OS, y dependiendo de qué tanto cambie el OS (Sistema Operativo), Apple puede requerir que las aplicaciones deban ser recompiladas para el nuevo OS por sus desarrolladores.

Eso bajo otras plataformas es algo impráctico, por la sencilla razón de que no existe una manera directa de controlar esas aplicaciones, como la tiene Apple con el App Store. Es decir, en Windows, Mac OS X y Linux, cualquiera puede crear una aplicación con cualquier herramienta, sin el consentimiento (o incluso conocimiento) de Apple, por lo que se hace difícil poner reglas en ese escenario.

Sin embargo, con el App Store, Apple sabe al 100% cuáles aplicaciones están instaladas en tu iPhone o iPad, y permitir que funcionen solo aquellas que son compatibles con tu versión del iPhone OS.

Recuerden ahora que Apple ofrece una manera de auto-actualización (aunque con la autorización del usuario) del iPhone OS en sus dispositivos, lo que tiene como efecto que en todo momento la gran mayoría de usuarios del iPhone OS estén actualizados a la última versión (si su hardware lo soporta, obviamente).

¿Qué efecto tiene esto? Que los desarrolladores, que utilizan XCode, simplemente tienen que recompilar su aplicación, especificando crear un ejecutable para la última versión del iPhone OS, y si los programadores siguieron las reglas impuestas por Apple, el programa genera un binario que funciona en la mas reciente versión, sin el programador tener que preocuparse por problemas de incompatibilidad.

Pero he aquí lo interesante: Apple puede, en ese proceso de compilación, tras bastidores, compilar el software para otra arquitectura totalmente diferente (si eliges por ejemplo que tu programa es exclusivo al iPad), o crear un binario universal (si tu aplicación funcionará en el iPhone 2G/3G/3GS y el iPad), todo sin el conocimiento del desarrollador de software.

¿Qué se gana con eso? Pues lo siguiente:

1. El programa siempre funcionará no solo en la mas reciente versión del sistema operativo, sino que además (y esto es lo importante) en cualquier arquitectura de hardware imaginable, sea ARM, PowerPC, x86 o cualquier otra que surja en el futuro.

2. Esto es totalmente transparente tanto para los desarrolladores de software, como para el usuario final.

3. Toda la comunidad de desarrolladores y usuarios caminan en conjunto conforme la plataforma avanza, siempre estando sincronizados con la mas reciente versión.

4. El software nunca tiene que ser interpretado, o compilado para una máquina virtual, sino que es siempre nativo y funciona al 100% de su velocidad nativa, ya que es código nativo lo que genera XCode.

Como ven, al juntar el App Store, el iPhone OS, y XCode, se eliminan básicamente todas las deficiencias de aplicaciones multi-plataforma que a la fecha existen en otros esquemas, ya que Apple ahora tiene la libertad de adoptar cualquier arquitectura posible en el futuro, para seguir siendo relevante ante avances que podrían hacer otros mejor que Apple en el campo de los CPUs.

Así que por ejemplo si Intel o AMD sacaran una arquitectura móvil revolucionaria, y Apple notara que su propia arquitectura local del chip A4 (y sus sucesores) no pueden competir, lo único que tienen que hacer es fabricar sus próximas versiones del iPhone y iPad con ese nuevo chip, sacar una nueva versión del iPhone OS, actualizar XCode para que soporte la nueva versión, y después de ahí los programadores simplemente tardan unos minutos en recompilar sus aplicaciones, y estas se hacen automágicamente compatibles con el nuevo chip, sin ningún trauma técnico para los desarrolladores o los usuarios finales.

No se ustedes, pero si todo esto es como creo es, hay que quitarse el sombrero ante los ingenieros de Apple por tan asombroso ingenio...

Nota a técnicos: Antes de que comenten, sepan que estoy bastante consciente de que por "multi-plataforma" uno por lo general se refiere a software que funciona bajo diferentes sistemas operativos y/o arquitecturas de hardware, y que en este artículo utilizo como ejemplo software que puede ejecutar en distinto hardware pero aparentemente en un solo sistema operativo (iPhone OS), sin embargo, si profundizan un poco mas en el tema (y yo no quería hacer el artículo mas largo de lo necesario), notarán que es el mismo caso, pues Apple muy bien podría portar sus APIs a un sistema operativo alternativo (digamos, Linux, aunque altamente improbable) y la técnica descrita aquí seguiría funcionando al 100% igual.

Noten además que de ser todo lo que se especula en este artículo cierto, que eso explicaría también porque Apple tiene una razón real para su cláusula contractual que dice que no se permite desarrollar con otras herramientas que no sean XCode con Objective-C en el iPhone OS, como lo hizo Adobe para crear su controvertido convertidor de Flash al iPhone OS, ya que ese tipo de aplicaciones no se podrían convertir de manera automatizada a una nueva arquitectura.

Finalmente, también estoy bastante consciente que si tomamos todas las cosas que Apple hace bajo este esquema por separado, que aquí no aparenta haber nada nuevo o notorio. La novedad aquí es que cuando todos estos elementos se unen en una sola solución, al final se crea un ecosistema que permite que todos los usuarios migren a nuevos dispositivos y arquitecturas de hardware de manera totalmente transparente para todos.

Y como siempre, pueden leer mas de mis opiniones y análisis en la sección bajo ese nombre a la derecha de la página principal de eliax...

autor: josé elías