Un poco de historia de herramientas de desarrollo en Mac Llevo ms de 20 aos desarrollando software para Mac a pequea escala y, en gran medida,

para un uso personal. Pero como deca, son muchos aos y, si bien no lo he visto todo, he visto mucho. Hoy quiero compartirlo con vosotros empleando un vocabulario no demasiado tcnico y lo suficientemente divulgativo para que cualquiera, desarrollador o usuario, con su iPad, un mojito, y desde la playa, pueda seguirme. Os planteo este artculo de la forma que ms me gusta presentar informacin a los newcomers, desde un punto histrico. Tambin voy a intentar evitar cualquier texto o referencia obtenido desde fuentes externas como Wikipedia que siempre podis consultar vosotros. Tan slo voy a emplear mi memoria y mi experiencia, as que si bien alguna informacin pueda no ser del todo correcta, os aseguro que es real. Tened en cuenta que tambin voy a omitir muchos detalles por cuestin de espacio, tiempo y claridad.

Los 90 y pre Mac OS X: Sangre, sudor, cdigo. Con este lema, que no es mo, s de una valiente empresa llamada Metrowerks, es como mejor definira esta etapa. Curiosamente, en estos aos, 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 bsicas, eran completamente externos a Apple. El primero de ellos (desde un punto de vista cronolgico) fue Symantec (s, los de los antivirus del to de las gafas). De Symantec recuerdo su maravilloso visor de documentacin que utilizaba tecnologas 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 documentacin hasta hace muy pocos aos, 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 soador Codewarrior de Metrowerks. An recuerdo la caja del CD (s, el primer entorno de desarrollo distribuido en formato digital) en que vena empaquetado. Posiblemente el envoltorio ms divertido que jams 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, cdigo. 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 aos, incluso llegando a competir con las de Apple entre los nostlgicos. No fue hasta la llegada de los Mac Intel que Metrowerks cedi ante el dominio de Apple con su fantstico, 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 aos s que provena de Apple. Todos los que tenemos un Mac desde hace ms de 22 aos la conocemos. ResEdit. Creo que slo Powerplant (de Metrowerks) y Resourcerer (Mathemaesthetics) le hicieron un poco de sombra.

En los '00. Un paraso para los desarrolladores. El lema de esta poca que tampoco es mo, sino que se poda leer en la pgina de desarrolladores de Apple lo dice todo. Haba llegado Mac OS X, un Unix revestido de simplicidad, erotismo y belleza. Esto quera decir que todas las herramientas de programacin Unix eran compatibles y usables en el entorno de La Manzana (Python, perl, bash, etc.). A parte de eso, Apple tambin puso sus piedras angulares para que un programador se sintiera atrado por su plataforma: Carbon. Lo primero, los desarrolladores originales del sistema antiguo. Carbon permita que los pioneros de la programacin en Mac se sintieran relativamente cmodos 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 tecnologa no slo 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 aplicacin tanto al iniciarla, en su final o durante su ejecucin) eran muy pobres. Pero con Mac OS X y todas las tecnologas Unix, esto pareca un escollo resuelto y a Applescript slo le quedaba dormir el sueo eterno. Sin embargo, Applescript fue puesta en el altar, no del sacrificio, sino de los honores y hoy en da es la base de la automatizacin 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 cdigo bsico 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 mviles y los 64 bits es prcticamente la nica manera de programar en Mac hoy en da. Por suerte, Apple ha ido instruyendo a sus desarrolladores hacia este nuevo entorno y hoy da goza de una base de usuarios firme, experta y vida de conocimiento. Una vez que tienes una buena base, la ramas son incmodas 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 corazn de este entorno

y lo que traduce el programa a lenguaje que entienda la mquina, dependa 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. Tambin se ha esforzado en que otros marcos de trabajo estn 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 ms aclitos as lo quieren una vez que lo han probado. Estn estamos enamorados. Sin embargo, hay grupos de programadores entusiastas del Mac que se resisten y que son crticos con la direccin que se ha tomado desde Cupertino en relacin 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 tambin a Apple. Dar soporte a estas tecnologas tuvo su razn 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 gustara mencionar a Miguel de Icaza y a su proyecto Mono. Mono es una reescritura del lenguaje, compilador, mquina de virtual y cdigo bsico de DotNet (.Net) de Microsoft. Mono funciona sobre Linux, Mac y Windows porque as fue pensado desde su esencia. Cmo? Microsoft pensando en los dems? Pues s y adems, dotNet es un estndar ECMA e ISO, cosa que Objective-C y Cocoa no. Segn los entendidos, DotNet y su clon de cdigo abierto, Mono es grande. DotNet/Mono incluye un lenguaje de programacin moderno (C#), seguro (pues los programas corren virtualizados) y estndar. De Icaza y compaa piensan que Apple debera 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 slo unos das) ha portado Mono al Mac y al iPhone. Hoy en da es posible crear aplicaciones DotNet (que recuerdo que son tecnologas de Microsoft) para Mac e iPhone. Y segn leo en las redes sociales, estas son estables, robustas y rpidas.

Pero es que Objective-C/Cocoa no es rpido 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 ms facilidades para sufrir fallos de seguridad. Ante esto Apple ha adoptado una tctica intermedia: en lugar de virtualizacin, 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 estn disponibles. Estas cajas de arena son lo que hace posible o imposible, segn se vea que una aplicacin de iPhone no sepa nada de las dems ni del sistema de archivos. Ahora Apple est llevando este juego al Mac y segn se comenta, a partir de noviembre, las aplicaciones debern estar preparadas para correr en este patio de arena infantil si quieren ser publicadas en el Mac App Store. Mi opinin final. Cocoa es un buen entorno. Apple puede seguir as e ir mejorndolo desde el ncleo. Me gustara que se estandarizada Objective-C como lo est C#. Apple ha aadido caractersticas con los aos a Objective-C que ni siquiera se corresponden con una versin determinada. Vamos, un poco catico. Estara muy bien que la oferta de tecnologas de desarrollo fuera amplia, pero comprendo que, a pesar de que es una de las empresas ms solventes del mundo, no puede permitirse tal inversin de tiempo y esfuerzo. Quizs una solucin intermedia sea delegar en terceros (empresas, proyectos opensource) el mantenimiento de herramientas y entornos adicionales. No hablo de una delegacin sin compromiso, sino de un acuerdo responsable. Por ejemplo. Apple podra invertir y s, hablo de dinero en empresas y proyectos jvenes y apasionados como Xamarin y Mono, Ruby, etc. sin llegar a depender de ellos, pero mantenindolos a punto por si algn da tienen que y empleando las metforas de Metrowerks pasar a formar parte de la cadena de montaje. Alberto Corbi Bellot