Existe ahora una eclosión de aplicaciones para iPhone/iPod/iPad, una «fiebre del oro» sobre todo en lo que a contenidos digitales se refiere, un deseo de que nuestras ideas o contenidos estén presentes en la pantalla de ese objeto de deseo llamado iPad.
Por ello cada día asaltan ese gran mercado llamado la App Store centenares de aspirantes a aplicación, en forma de videojuegos, libros, utilidades, etc. Al inicio, cuando había pocas apps disponibles, era relativamente sencillo que cualquier pequeña aplicación, por simplona que pareciera, obtuviese el permiso para ser publicada en la App Store. Pero las cosas han cambiado, con casi 400 000 apps (a fecha de Marzo de 2011) se podría decir que le mercado está saturado y Apple ya no aceptará cualquier cosa.
Es por eso que en el post de hoy quisiera mencionaros algunas líneas generales a tener en cuenta a la hora de empezar o seguir vuestra App editorial, la mayoría de bastante sentido común, así como algunos puntos concretos que pueden ser más controvertidos o que podrían tumbar vuestra solicitud y proporcionaros una pequeña dosis de amarga frustración. Estos puntos han sido traducidos y extraídos desde la «App Store Review Guidelines», disponible para desarrolladores de Apple iOS. Las he separado en dos categorías: «Cosas de Cajón» y «Puntos Sensibles» (con los que hay que tener más cuidado, sobre todo si vamos a hacer contenidos editoriales):
COSAS ‘DE CAJÓN’
- Una app que «pete» (se cuelgue o presente bugs) es rechazada de forma inmediata
- Una app que se presente como versión «Test», «Prueba» o «Beta», también
- La app tiene que comportarse como se anuncia en su descripción, de manera fidedigna
- Una app que sea «otra más»; es decir una copia de una utilidad ya muy manida en la App Store, como por ejemplo linternas, niveles o aplicaciones que simulan eructos o pedos (sic) serán rechazadas
- La app no puede solicitar datos personales del usuario (como el nombre, teléfono, etc) para que pueda funcionar
PUNTOS SENSIBLES
- Una app que utilice una API de programación que no sea pública, será rechazada.
- Apps que «no son muy útiles» (sic), o que sean sencillamente sitios web empaquetados como apps, o que no representen un «entretenimiento duradero» (sic) podrían ser rechazadas
- Si la app navega por la web, debe emplear exclusivamente el sistema de WebKit de iOS y el JavasScript de WebKit.
- Una app que sea […] simplemente un libro debe venderse a través de la iBooks Store (a fecha de Mayo de 2011 no existe iBooks Store en España)
- Una app que contenga texto falso será rechazada
- Antes de enviar una app para su aprobación, deben estar listas al 100% las URL de soporte para las mismas (página de descripción y política de privacidad)
- Una aplicación que en lugar de usar los componentes de interface (y según las guías de uso del Apple Human Interface) y traten de imitar el interface del iPod serán rechazadas. De hecho todas las apps deben cumplir con los términos del Apple iOS Human Interface Guidelines. Tampoco se pueden imitar ninguna de las aplicaciones que vienen por defecto con el iPhone / iPod / iPad.
- Si tu interfaz de usuario es compleja o menos que «muy buena» (sic), podría ser rechazada.
- Un app que desbloquea funcionalidades o permite nuevas funcionalidades con mecanismos que no sean puramente la App Store, serán rechazadas. Hay que meplear el App Purchase API (IAP)
- Apps que sean sencillamente recortes de una web, agregadores de contenidos (RSS) o una colección de links, también serán rechazadas
En resumen, y aunque estos puntos, como cualquier ley, tienen flecos difusos a los que se puede recurrir y a pelar, vuestra app deberá ser lo más única y original que podáis, ha de tener una interfaz de usuario trabajada para que su uso sea tan fácil e intuitivo como las propias que hace Apple y deben tener un valor añadido con respecto a lo que ya existe.
¡Suerte con vuestras apps, no os desaniméis! Y pensad que tenéis la alternativa de diseñar WebApps para vehicular contenidos en el iPad sin necesidad de pasar por el filtro de la App Store.
Cuando hablas de una "API no pública" a qué te refieres exactamente? Algun ejemplo?
Una app que sea simplemente un libro debe venderse a través de la iBooks Store
— FALSO
Antes de enviar una app para su aprobación, deben estar listas al 100% las URL de soporte para las mismas (página de descripción y política de privacidad)
— La página de descripción puede ser solo el sitio web de referencia del desarrollador
—No es obligatorio tener una página y una politica de privacidad.
Una API no pública es cualquiera que cuyo código fuente no esté disponible públicamente. Por ejemplo, la API de Google Maps (en javascript) es pública.
Por otro lado, lo de "Una app que sea simplemente un libro debe venderse a través de la iBooks Store " no es falso, es una traducción literal de uno de los puntos de la Guía de Apple para la AppStore. Lo que pasa es que se refiere a "libros de texto", no tanto por ejemplo a cuentos infantiles, y por otro lado todavía no existe la iBooks Store en España, por lo que esta condición es incluso dificil de cumplir para libros "de texto". Pero la cláusula en sí no es falsa, es literal.
De igual modo la cláusula de las URLs también es una traducción literal. Que estén al 100% hace referencia a que existan dichas URLs y no estén en construcción.
Este artículo menciona algunos puntos clave del Acuerdo de Desarrollo de Apps para la App Store, no implica que estas condiciones las apliquen siempre a rajatabla.
Gracias a todos vosotros "Anónimos" por vuestras puntualizaciones.
Buenos dias mi pregunta es la siguiente, trabajo en una empresa que diseña y programa App, actualmente estamos desarrollando una app catalogo y venta de zapatillas, segun tengo entendido apple es el unico encargado de cobrar si es que un cliente quiere comprar un modelo de zapatilla desde mi aplicacion, ya que la app dispondra de un boton que diga comprar. o en todo caso apple me la rechazara. podrian despejar mis dudas, gracias.