Cualquier estratagema de regulación ambiciosa estará sometida a presión para ser ampliada, a fin de proteger los flancos de la regulación principal en contra de las soluciones creadas por los usuarios. La estrategia de Apple de controlar que aplicaciones se pueden ejecutar en el iPhone y el iPod es una de estas regulaciones, y en la última semana Apple ha tenido que ceder a la presión para expandir sus regulaciones.
Para ilustrar el problema, consideremos una aplicación hipotética para el iPad llamada Ed’s App World (EAW). EAW nos permite descargar elementos llamados EdApps, que consisten en instrucciones que la aplicación ejecuta. Cualquier desarrollador puede crear una EdApp que interpretara sus instrucciones en el lenguaje de programación Ed. Es perfectamente posible crear una aplicación como EAW.
El problema de regulación de Apple es que Ed’s App World es en realidad una tienda de aplicaciones competidora – Las EdApps pueden hacer cualquier cosa que las aplicaciones nativas puedan hacer, y cualquier desarrollador puede crear y distribuir una EdApp. Si Apple quiere evitar la competencia de App Stores, ellos deben evitar que aplicaciones como EAW existan.
Apple ha tratado durante mucho tiempo mantener a tecnologías específicas, como Adobe Flash, fuera del iPhone/iPad debido a que estas tecnologías tienen características como EAW. Ahora Apple ha ampliado sus regulaciones al decirnos que sólo ciertos métodos de programación son aceptables. En la sección 3.3.1 del acuerdo de licencia de desarrollador se establece:
3.3.1 – Las aplicaciones sólo podrán utilizar APIs documentados en la forma prescrita por Apple y no deben usar o llamar a cualquier API privado. Las aplicaciones deben haber sido escritas originalmente en Objective-C, C, C + + o JavaScript ejecutado por el motor de Webkit, y sólo el código escrito en C, C + + y Objective-C puede ser compilado y enlazado directamente con los APIs documentados (por ejemplo, las aplicaciones que tienen enlaces a los APIs documentados a través de una traducción intermedia o una herramienta de compatibilidad de nivel superior están prohibidas).
Esto deja fuera a muchos lenguajes de programación y herramientas comunes. Para los desarrolladores, parece que Apple está tratando de micro-gestionar cómo deben hacer su trabajo
La prohibición de Apple de aplicaciones programables va más allá de Flash. Esta semana Apple prohibió Scratch, una herramienta educativa ampliamente utilizada que introduce a los estudiantes al mundo de la programación e informática al permitirles construir animaciones. ¿Por qué Apple veto a Scratch? Presumiblemente por que las animaciones de Scratch contienen elementos de programación. Los educadores no se encuentran contentos, por decir lo menos. Mark Guzdial de Georgia Tech lo expresó así: “¿Quieren ser realmente letrados en informática, en donde pueden escribir, así como leer? No hay una aplicación para eso.
Lo que es realmente interesante es que pese a los esfuerzos de Apple para bloquear estas aplicaciones, hay un enorme sistema de tipo EAW que Apple no ha tenido las agallas de bloquear: la web. Gracias a las tecnologías Ajax, la web se ha convertido en un vehículo para poder entregar funcionalidades de tipo aplicación (dentro de las páginas web). El navegador Safari de Apple en el iPhone y iPad soporta estas aplicaciones. Es difícil imaginar que Apple podría salirse con la suya al bloquear todos los sitios habilitados con Ajax que usamos todos los días. Y el problema de Apple con Ajax será aún peor a medida que HTML 5 surja con un mejor soporte para aplicaciones basadas en web.
Si no son aficionados a la tecnología, este tema puede parecer como de otro mundo. Pero sí afecta lo que pueden hacer y ver. Es posible que no conozcan todos los detalles del por qué la App Store empieza a verse más y más como Disneylandia, pero se darán cuenta que esto está sucediendo.
Por último, me gustaría abordar la objeción común que la mayoría de las personas no se preocupan por los límites en la programación, porque no saben programar. Para mí, esto es como decir que no les importa el cierre de restaurantes porque nadie en su casa sabe cocinar. Si ustedes no pueden cocinar ustedes mismos, les debería importar más la calidad del restaurante. Si todos los buenos restaurantes cierran, los buenos cocineros terminaran por cocinar sus propias comidas – pero ustedes no tendrán la misma suerte
* Nota: Este articulo apareció originalmente en Freedom To Tinker por Ed Felton y yo me he encargado de traducirlo al Español.
Social Media