Admito que el artículo es algo técnico. Pero lo que viene a transmitir es que a RogueSheep le han hecho una buena jugarreta al ver cómo su aplicación ha sido rechazada por este motivo. Su aplicación estaba enlazada con una versión de la plataforma Three20 que no llamaba, sino que sobreescribía una API privada — quiere decir que sustituía un método privado con su propio método de igual nombre. Y el caso es que Postage, la aplicación, no siquiera estaba invocándolo. Aparentemente, la herramienta de Apple no es capaz de distinguir ambos casos, así que los desarrolladores deben estar atentos o se expondrán a el rechazo automático de su aplicación.
Chris Parrish, de RogueSheep, llega a la siguiente conclusión:
Personalmente, me encantaría que Apple nos concediera acceso a la herramienta de análisis para comprobar nuestras propias versiones antes de enviaras [para su publicación en el App Store]. O, si eso no es posible, quizás una modificación del proceso de revisión de aplicaciones para que este análisis automático se realice en las primeras etapas del proceso, de modo que no perdamos tanto tiempo durante los 14 días que está tardando ahora en completarse el proceso de verificación de aplicaciones.
Poner la herramienta de análisis a disposición de los desarrolladores sin duda sería de ayuda. Pero intuyo que no funcionaría, en términos de las reglas del juego. Los desarrolladores honrados podrían aprovechar el acceso a la herramienta, para hacer que sus proyectos no empleen APIs privadas. Pero los desarrolladores deshonestos usarían la herramienta para idear formas de colar llamadas a APIs privadas sin que el sistema las detecte. La segunda petición de Parrish, que Apple realice esta comprobación en una fase más temprana del proceso de verificación, sí que me parece razonable.
ACTUALIZACIÓN: A continuación, un mensaje escrito por un lector de DF bien informado:
Sobreescribir métodos privados de una categoría es mucho peor que invocarlos directamente.
Todo lo que contenga el proceso heredará el comportamiento sobreescrito del método privado y todo lo que uno asuma sobre los efectos laterales se va por el sumidero.
Una consecuencia de la lucha de Apple contra el uso de llamadas a APIs privadas es que algunas aplicaciones las utilizan, o al menos las incluyen en sus binarios sin que los autores lo sepan. Un Una plataforma de desarrollo de código abierto muy extendida, Three20, creada por Joe Hewitt (enlazada aquí en DF el pasado Marzo), se lanzó alegremente a emplear las APIs privadas, y ahora hay muchos desarrolladores cuyas aplicaciones están siendo vetadas por contener llamadas a APIs privadas producidas por la plataforma Three20. Esta discusión de Google Groups tarta el problema y el trabajo que se está llevando a cabo para crear una variante de Three20 que no contenga llamadas a APIs privadas.
(Hewitt, por supuesto, apareció en las noticias la semana pasada al dimitir como programador principal de la aplicación de Facebook para el iPhone mencionando la frustración que le producía el proceso de aprobación del App Store. Es razonable preguntarse si su decisión tenía algo que ver con la persecución llevada a cabo por Apple contra el uso de APIs, porque la plataforma Three20 fue originalmente retirada de la aplicación de Facebook. He intercambiado algunos correos con Hewitt discutiendo el asunto, y ese no parece ser el caso — su frustración con el proceso del App Store tiene otros motivos).
Nota del Traductor El artículo de John Gruber enlazado al principio del texto no está disponible en español. Como dato curioso, en él se comenta que el nombre Three20 (tres 20) proviene de la resolución de pantalla del iPhone.
John Herrma explica en Gizmodo los fundamentos de la herramienta estática de análisis que Apple usa ahora para revisar las aplicaciones enviadas al App Store, con objeto de identificar (y rechazar) aquellas que usen llamadas a APIs privadas. Apple ha sido muy explícita desde el comienzo, dejando claro que usar estos métodos es una mala idea y constituye un motivo para que se rechace la aplicación, así que en general esta herramienta me parece una buena idea. El secreto será asegurarse que no genere falsos positivos.
¿Notáis algo especial en la mayoría de los portátiles?
Lo difícil a la hora de criticar el App Store es que no se presta a una interpretación en la que todo es blanco o negro. No es bueno o malo. Es las dos cosas. De hecho, es más radical aún — es a la vez sorprendementemente bueno y horriblemente malo. Y lo que resulta frustrante es que muchos de nosotros vemos de qué modo podrían mejorarse los aspectos malos sin sacrificar los buenos.
Este artículo de Paul Graham trata semejante dicotomía, e intenta analizar el motivo de la aparente ceguera de Apple ante los graves problemas del App Store:
En realidad, supongo que Apple interpreta erróneamente algo más: creen que todas las quejas existentes por el proceso de aprobación del App Store no son un problema serio. Deben ver que los desarrolladores se quejan. Pero los socios y los proveedores siempre se están quejando. Si no lo hicieran serían una mala señal; significaría que uno está siendo demasiado blando con ellos. Mientras tanto, el iPhone se vende mejor que nunca. De modo que, ¿por qué tendrían que arreglar nada?
Más adelante, Graham resume lo que verdaderamente me da Miedo:
Una organización que se impone haciendo valer su poder pierde la capacidad de imponerse haciendo algo mejor que los demás.
Ojalá hubiera escrito yo esa frase.
Michael Gartenberg:
Solía argumentar que Apple se había convertido en el Nordstrom de la venta de tecnología. ¿Alguna vez habéis comprado en Nordstrom’s? Si no lo habéis hecho, deberíais probarlo sólo por vivir la experiencia. De hecho, si estás a cargo de una organización encargada de dar soporte, deberías visitar Nordstrom’s y comprar allí como formación, para aprender.
No creo que Apple siga siendo el Nordstrom de los productos tecnológicos. Creo que son el nuevo Nordstrom de acuerdo al nivel de servicio.
Vale, ¿pero acaso bailan?
Montones de novedades en esta estupenda aplicación de Twitter para el iPhone, creada por Buzz Andersen. Entre las novedades está el soporte para incluir imágenes de Flickr en los mensajes y una excelente integración con la API de geolocalización de Twitter, recientemente puesta a disposición de los desarrolladores.
Lucas Mearian:
Google Inc. ha declarado hoy que su sistema operativo Google Chrome, que será lanzado próximamente, no permitirá el uso de discos duros tradicionales, en favor de las unidades de disco de estado sólido (SSD).
Una decisión inteligente. Primero, Chrome no necesita una gran capacidad de almacenamiento local. Segundo, al decidirse por usar únicamente unidades SSD, Google puede emplear un sistema de archivos diseñado totalmente para unidades de acceso aleatorio. Si puedes contar con que la unidad de almacenamiento sea una memoria de estado sólido, se pueden realizar toda clase de optimizaciones para mejorar el rendimiento. Están preparándose para el futuro.
Lo más inteligente que he visto por el momento sobre el sistema operativo Chrome OS es este tweet de Alex Payne:
No me he formado una opinión sobre Chrome OS. Lo único que sé es que el hardware barato da mala impresión. No es tanto “computación en la nube” como “computación desechable”.
Muchísima información sobre el aspecto que tendrá Chrome OS, el sistema operativo de Google, y sobre cómo funcionará. En pocas palabras, es un sistema operativo que arranca en menos de 10 segundos y que presenta un navegador basado en WebKit. Puede hacer más cosas que un navegador, como detectar que se ha conectado un dispositivo USB de almacenamiento (cámaras, teléfonos Android, etc.), pero no se realizan otro tipo de tareas como lidiar con un sistema de archivos local o instalar aplicaciones. Lo enciendes, y usas la Web.
(Al igual que ocurre con el navegador Chrome, con el sistema operativo Chrome OS, “Chromium” es el nombre del proyecto open source).