Un poco de historia de herramientas de desarrollo en Mac, por Alberto Corbi

Llevo más de 20 años desarrollando software para Mac a pequeña escala y, en gran medida, para un uso personal.

Pero como decía, son muchos años y, si bien no lo he visto todo, he visto mucho. Hoy quiero compartirlo con vosotros empleando un vocabulario no demasiado técnico y lo suficientemente divulgativo para que cualquiera, desarrollador o usuario, con su iPad, un mojito, y desde la playa, pueda seguirme. Os planteo este artículo de la forma que más me gusta presentar información a los newcomers, desde un punto histórico. También voy a intentar evitar cualquier texto o referencia obtenido desde fuentes externas como Wikipedia –que siempre podéis consultar vosotros–. Tan sólo voy a emplear mi memoria y mi experiencia, así que si bien alguna información pueda no ser del todo correcta, os aseguro que es real. Tened en cuenta que también voy a omitir muchos detalles por cuestión de espacio, tiempo y claridad.

Los 90 y pre Mac OS X: Sangre, sudor, código.

Con este lema, que no es mío, sí de una valiente empresa llamada Metrowerks, es como mejor definiría esta etapa. Curiosamente, en estos años, a pesar de existir herramientas de desarrollo propias de Apple (MPW, entre otros), poca gente las utilizaba. Los principales proveedores de este tipo de herramientas, que pueden considerarse básicas, eran completamente externos a Apple. El primero de ellos (desde un punto de vista cronológico) fue Symantec (sí, los de los antivirus del tío de las gafas). De Symantec recuerdo su maravilloso visor de documentación que utilizaba tecnologías de hypertexto mucho antes de la existencia del primer navegador y de su capacidad de minimizarse de una forma muy maja (a lo Dock). El Symantec Think Reference ha estado vigente como biblioteca de documentación hasta hace muy pocos años, y es una prueba de que el buen software puede parecerse al buen vino. El compilador de Symantec y entorno de desarrollo se llamaba ThinkC/ThinkPascal y, aunque era muy bueno, no tardó en verse derrotado por el joven, viril y soñador Codewarrior de Metrowerks.

Aún recuerdo la caja del CD (sí, el primer entorno de desarrollo distribuido en formato digital) en que venía empaquetado. Posiblemente el envoltorio más divertido que jamás haya visto para un producto de software o de cualquier otra cosa. Era un dibujo modernista de mineros, soldadores y escultores fabricando –literalmente– software. Se trataba casi de un icono comunista. El texto en la parte inferior, era sencillo: Metrowerks Codewarrior. Sangre, sudor, código. El boxing del producto te invitaba a instalarlo inmediatamente y a empezar a manufacturar programas bajo calderas de software, fuego y acero incandescente.

Codewarrior ha sido la herramienta de desarrollo de referencia hasta hace muy pocos años, incluso llegando a competir con las de Apple entre los nostálgicos. No fue hasta la llegada de los Mac Intel que Metrowerks cedió ante el dominio de Apple con su fantástico, independiente de arquitectura –y gratuito, cosa que Codewarrior no– Xcode.

Curiosamente, la herramienta de desarrollo de interfaces (con la que se dibuja el aspecto del programa) durante estos años sí que provenía de Apple. Todos los que tenemos un Mac desde hace más de 22 años la conocemos. ResEdit. Creo que sólo Powerplant (de Metrowerks) y Resourcerer (Mathemaesthetics) le hicieron un poco de sombra.

En los ’00. Un paraíso para los desarrolladores.

El lema de esta época –que tampoco es mío, sino que se podía leer en la página de desarrolladores de Apple– lo dice todo. Había llegado Mac OS X, un Unix revestido de simplicidad, erotismo y belleza. Esto quería decir que todas las herramientas de programación Unix eran compatibles y usables en el entorno de La Manzana (Python, perl, bash, etc.). A parte de eso, Apple también puso sus piedras angulares para que un programador se sintiera atraído por su plataforma:

Carbon. Lo primero, los desarrolladores originales del sistema antiguo. Carbon permitía que los pioneros de la programación en Mac se sintieran relativamente cómodos en el nuevo entorno Unix y portaran sus apps con rapidez.

Java. Sí, Apple se curró un puente –o bridge– entre el entorno Java y el Desktop del Mac, lo que posibilitaba que aplicaciones Java corrieran de forma completamente transparente.

AppleScript. En contra de lo que yo mismo esperaba, esta tecnología no sólo no murió, sino que resucitó con fuerza. Applescript aportaba mucho sentido en los sistemas antiguos (pre OS X) donde la multitarea y la scriptabilidad (capacidad de enviar órdenes y solicitar datos a una aplicación tanto al iniciarla, en su final o durante su ejecución) eran muy pobres. Pero con Mac OS X y todas las tecnologías Unix, esto parecía un escollo resuelto y a Applescript sólo le quedaba dormir el sueño eterno. Sin embargo, Applescript fue puesta en el altar, no del sacrificio, sino de los honores y hoy en día es la base de la automatización de Mac OS X.

Cocoa –cacao en castellano–. El hijo amado, el preferido, el elegido para el desayuno de los campeones. Cocoa es un lenguaje nuevo (Objective-C) para el mundo y un conjunto de código básico orientado a objetos que poco a poco ha ido barriendo a los anteriores (menos AppleScript, al que se le reserva un cuarto de juegos especial). Con llegada de los dispositivos móviles y los 64 bits es prácticamente la única manera de programar en Mac hoy en día. Por suerte, Apple ha ido instruyendo a sus desarrolladores hacia este nuevo entorno y hoy día goza de una base de usuarios firme, experta y ávida de conocimiento. Una vez que tienes una buena base, la ramas son incómodas y hay que podar.

Xcode. Un entorno de desarrollo integrado para dominar a todos los anteriores y atarlos al Mac. Pero curiosamente, el compilador, que es el corazón de este entorno y lo que traduce el programa a lenguaje que entienda la máquina, dependía de terceros. El GCC o GNU Compiler Collection es el mismo que utiliza, entre otros, Linux.

La actualidad. Desarrolla, escribe, construye, innova.

Nuevamente el eslogan es de Apple. Cocoa sigue siendo (y la curva es ascendente) el sistema “por defecto”. Apple ha invertido en nuevos compiladores propios (ya no depende de GNU, aunque eso no representaba problema alguno) y puede decirse que Apple lo tiene todo bien atado en lo que a Cocoa se refiere. No le falta ninguna pata y no depende de terceros. Las herramientas de desarrollo son propias, potentes, estables, tienen personalidad y dan carisma a la plataforma.

También se ha esforzado en que otros marcos de trabajo estén disponibles y a buenas con Mac OS X. Por ejemplo, MacRuby permite que los expertos en el lenguaje Ruby desarrollen aplicaciones Mac sin problemas. PyObjC permite lo mismo para Python.

El futuro o Una vez que has probado el amor.

El futuro inmediato parece claro. Todo tiene el color del batido de cacao y Apple y los desarrolladores más acólitos así lo quieren una vez que lo han probado. Están –estamos– enamorados. Sin embargo, hay grupos de programadores entusiastas del Mac que se resisten y que son críticos con la dirección que se ha tomado desde Cupertino en relación con las herramientas de desarrollo.

Por un lado tenemos a los que no consideran apropiado que Apple abandone Java, Carbon, etc. en favor de Cocoa. Les comprendo a ellos, pero también a Apple. Dar soporte a estas tecnologías tuvo su razón de ser (atraer desarrolladores al Mac, cuando estuvo a punto de sucumbir), pero ya no es así. Darles soporte no hará otra cosa que retrasar al equipo.

En otro bando tenemos a los que creen que, si bien las herramientas de desarrollo son buenas, son mejorables. En este grupo me gustaría mencionar a Miguel de Icaza y a su proyecto Mono. Mono es una reescritura del lenguaje, compilador, máquina de virtual y código básico de DotNet (.Net) de Microsoft. Mono funciona sobre Linux, Mac y Windows porque así fue pensado desde su esencia. ¿Cómo? ¿Microsoft pensando en los demás? Pues sí y además, dotNet es un estándar ECMA e ISO, cosa que Objective-C y Cocoa no. Según los entendidos, DotNet –y su clon de código abierto, Mono– es grande. DotNet/Mono incluye un lenguaje de programación moderno (C#), seguro (pues los programas corren virtualizados) y estándar. De Icaza y compañía piensan que Apple debería adoptarlo para su plataforma, pero mientras lo no hace, De Icaza, antes en la difunta Novell y ahora en Xamarin (empresa que acaba de fundar hace tan sólo unos días) ha portado Mono al Mac y al iPhone. Hoy en día es posible crear aplicaciones DotNet (que recuerdo que son tecnologías de Microsoft) para Mac e iPhone. Y según leo en las redes sociales, estas son estables, robustas y rápidas.

¿Pero es que Objective-C/Cocoa no es rápido y seguro? Lo primero desde luego. Lo segundo no está tan claro. ¿Por qué? Pues porque Objective-C es heredero de C. En C, un programa tiene más facilidades para sufrir fallos de seguridad. Ante esto Apple ha adoptado una táctica intermedia: en lugar de virtualización, ha apostado por el Sandboxing (“patio de juegos de arena”). En el sandboxing, las aplicaciones creen que el sistema en el que se ejecutan cuenta con menos recursos de los que de verdad están disponibles. Estas cajas de arena son lo que hace posible –o imposible, según se vea– que una aplicación de iPhone no sepa nada de las demás ni del sistema de archivos. Ahora Apple está llevando este juego al Mac y según se comenta, a partir de noviembre, las aplicaciones deberán estar preparadas para correr en este patio de arena infantil si quieren ser publicadas en el Mac App Store.

Mi opinión final.

Cocoa es un buen entorno. Apple puede seguir así e ir mejorándolo desde el núcleo. Me gustaría que se estandarizada Objective-C como lo está C#. Apple ha añadido características con los años a Objective-C que ni siquiera se corresponden con una versión determinada. Vamos, un poco caótico. Estaría muy bien que la oferta de tecnologías de desarrollo fuera amplia, pero comprendo que, a pesar de que es una de las empresas más solventes del mundo, no puede permitirse tal inversión de tiempo y esfuerzo. Quizás una solución intermedia sea delegar en terceros (empresas, proyectos opensource) el mantenimiento de herramientas y entornos adicionales. No hablo de una delegación sin compromiso, sino de un acuerdo responsable. Por ejemplo. Apple podría invertir –y sí, hablo de dinero– en empresas y proyectos jóvenes y apasionados como Xamarin y Mono, Ruby, etc. sin llegar a depender de ellos, pero manteniéndolos a punto por si algún día tienen que –y empleando las metáforas de Metrowerks– pasar a formar parte de la cadena de montaje.

Alberto Corbi Bellot