Más información sobre PastryKit ☆ ★

Friday, 18 December 2009

Más información acerca de PastryKit, la plataforma de desarrollo de Apple para crear aplicaciones web para el iPhone con un aspecto y funcionamiento muy cercano al de las aplicaciones nativas para el iPhone.

Las diversas plataformas JavaScript de Apple

Jonathan “Wolf” (lobo) Rentzsch ha publicado un fantástico resumen de las plataformas JavaScript conocidas y utilizadas actualmente por distintos equipos dentro Apple. Algunas de ellas son públicas. Otras, como PastryKit, no lo son. Si que tienen puntos en común; en concreto, varias de ellas tienen un patrón muy similar a Cocoa, no sólo en términos de MVC, sino hasta detalles como los nombres de las clases. (No había oído hablar de Gianduia hasta ahora, pero parece tratarse de algo muy gordo. El equipo de ventas online de Apple lo está usando para cosas como el sistema de reservas del Genius Bar).

Pero PastryKit es la única plataforma destinada específicamente a la creación de interfaces para el iPhone similares a los de las aplicaciones nativas. Entre las otras, una parece estrechamente relacionada con PastryKit: TuneKit, la plataforma (ahora disponible públicamente) para crear LPs de iTunes y paquetes de Extras para iTunes. Alrededor del 40 por ciento del código de PastryKit es idéntico al de TuneKit (si uno ignora la diferencia entre los prefijos “PK” y “TK” usados para nombrar las clases). El lector de DF Greg Sadetsky me envió un correo electrónico con la siguiente comparativa, tras procesar el código con un programa para expandirlo, devolviéndole una estructura más legible. En primer lugar, un fragmento de PastryKit:


const PKTransitionDefaults = {
duration: 0.5, delay: 0,
removesTargetUponCompletion: false,
revertsToOriginalValues: false
};
const PKTransitionStyles = [
"-webkit-transition-property",
"-webkit-transition-duration",
"-webkit-transition-timing-function",
"-webkit-transition-delay",
"-webkit-transition"
];

Lo siguiente es de TunesKit, y es idéntico salvo por los prefijos PK/TK TunesKit:


const TKTransitionDefaults = {
duration: 0.5, delay: 0,
removesTargetUponCompletion: false,
revertsToOriginalValues: false
};
const TKTransitionStyles = [
"-webkit-transition-property",
"-webkit-transition-duration",
"-webkit-transition-timing-function",
"-webkit-transition-delay",
"-webkit-transition"
];

Etcétera… O PastryKit y TuneKit son proyectos afines, o son obra de la misma persona. (Además, Daniel Dilger encontró en Septiembre algunas referencias a “PastryKit” en el paquete de Extras para iTunes de Wall-E).

Ayuda de iDisk

Unos cuantos lectores me hablaron sobre otro caso de PastryKit en plena acción: las páginas de ayuda de la aplicación iDisk para el iPhone. Si tienes instalada la aplicación iDisk que se distribuye en el App Store, puedes ver de lo que hablo pulsando “Configuración” y después en “Ayuda de iDisk”. Parece igual que el resto de la aplicación, pero hay unas cuantas señales que delatan que en realidad es PastryKit funcionando en una vista web a pantalla completa (por ejemplo, al tocar la barra de estado los contenidos no hacen scroll hasta la parte superior).

¿Es PastryKit un sobrante de la época anterior al kit de desarrollo para el iPhone?

Una pregunta que he visto con mucha frecuencia (por citar un ejemplo, en esta discusión de Hacker News) es si PastryKit podría ser un sobrante de la época en que Apple esgrimía el argumento de “las aplicaciones web son una solución estupendísima para crear software para el iPhone”. Mi opinión es que no. Para empezar, siempre ha existido un manual de usuario del iPhone, y por lo que recuerdo, el manual siempre ha ido más o menos en consonancia con el aspecto y funcionamiento de una aplicación nativa, aunque la versión del manual para el iPhone OS 3 es mucho mejor. De hecho, si cambias el agente de usuario en Safari a MobileSafari 2 (en lugar de 3) y abres la web del Manual del Usuario, te aparecerá una versión anterior correspondiente al iPhone OS 2.0, que es mucho menos impresionantes desde un punto de vista técnico. Ni scroll especial, ni los degradados azules típicos del iPhone al resaltar las filas seleccionadas, etc. Lo que es más, PastryKit aprovecha funciones de Mobile WebKit que sólo están disponibles en iPhone OS 3.0. PastryKit es algo nuevo.

La postura de Apple respecto a la competencia entre las aplicaciones web y el App Store

Por último, está la cuestión de hasta qué punto le preocupa a Apple desde un punto de vista estratégico que una API sólida para el desarrollo web y su consiguiente mercado perjudiquen al App Store. Y en ese caso, ¿les preocupa desde el punto de vista económico? Creo que seguramente no. No creo que el 30 por ciento que Apple se lleva de los ingresos del App Store sean cosa de risa; además, el App Store está creciendo rápidamente. Pero no hay duda de que la razón de ser del App Store es vender unidades del iPhone y el iPod Touch, no al revés.

Algo más preocupante podría ser el hecho de que las aplicaciones web funcionan en cualquier plataforma. Apple emplea actualmente la detección de los datos del agente de usuario para evitar que sus manuales de usuario creados con PastryKit puedan abrirse en otro navegador que no sea MobileSafari, pero no creo que haya ninguna razón técnica por la que estas aplicaciones no puedan funcionar perfectamente y tener el mismo aspecto en Android y WebOS. La tipografía sería ligeramente distinta, ya que ninguno de estos teléfonos incluyen Helvetica, pero aparte de esto tendrían el aspecto de una aplicación para el iPhone.

El desarrollo web de vanguardia nunca parece funcionar “a la perfección” al cambiar de plataforma, pero estos tres sistemas — iPhone, Android, WebOS — se basan todos en el mismo núcleo WebKit. E incluso si hacen falta ajustes para que funcione en cada plataforma, es seguro que sería mucho menos costoso que desarrollar aplicaciones nativa independientes usando las APIs de Cocoa Touch, Android y Mojo, que sí son muy diferentes.

Espero que a Apple no le preocupe esto. Pensemos que las aplicaciones web destinadas a ordenadores de sobremesa no han afectado a la demanda de Macs. En cualquier caso, el Mac se ha beneficiado enormemente de que la web sustituya a Windows como la plataforma de software más extendida. Creo que Apple haría bien en impulsar la creación de aplicaciones web como solución para el desarrollo de aplicaciones móviles multiplataforma, cosa que no disminuiría el interés en el desarrollo de aplicaciones nativas con Cocoa Touch para un mejor rendimiento (sobre todo en juegos) y con acceso al hardware (como la cámara), cosas que escapan a las posibilidades de las aplicaciones web. También creo que tanto los usuarios del iPhone como Apple se beneficiarían de un aumento de las aplicaciones web (que no requieren aprobación) como alternativa al App Store, que es un espacio totalmente controlado. [1. Esto no quiere decir que unas APIs más potentes para el desarrollo web sean la panacea que solucione todos los problemas del App Store. Al fin y al cabo, muchas de las aplicaciones que Apple ha vetado del App Store no se pueden reproducir como aplicaciones web por motivos técnicos. Google Voice es el ejemplo más lamentablemente conocido. Además, para un programador que acaba de crear una aplicación nativa para el iPhone usando Cocoa Touch no supone un gran consuelo que le digan que su creación no se publicará en el App Store, pero que es libre de recrear la aplicación desde cero usando APIs y tecnologías totalmente distintas.] Es algo humano enfatizar el conflicto y el drama, pero no hay razón por la que las aplicaciones nativas y las aplicaciones web para el iPhone no puedan ser dos plataformas llenas de vida y en pleno crecimiento.