Home » Opinión » El coste de las actualizaciones para los desarrolladores
Team Developer App

El coste de las actualizaciones para los desarrolladores

23 de septiembre de 2015, solo una semana después del lanzamiento de iOS 9.0, Apple ha propagado la primera actualización hot fix con la versión 9.0.1 que soluciona una serie de errores y corrige otros tantos fallos de seguridad. Ese mismo día, tras la publicación el 9 de septiembre de Xcode 7.1 Beta e iOS 9.1 Beta, Apple publica la Beta 2 de ambos y una nueva versión (también en beta) de Swift 2.

La ahora versión 2.1 (insistimos, aun en beta) incluye una serie de mejoras principalmente en la integración con los tipos nativos de C, creando equivalencias entre tipos de los lenguajes así como conformar al protocolo de igualación Equatable una serie de tipos de datos para poder usar en comparaciones del lenguaje. Por otro lado, incorpora la curiosa posibilidad de incluir variables que usen literales dentro de una interpolación, de forma que ahora podemos incorporar un dato de un diccionario dentro de una.

La primera reacción de la comunidad de desarrolladores no se ha hecho esperar y muchos se han quejado que aun no han conseguido actualizar sus desarrollos y productos a iOS 9 con Swift 2 cuando Apple ya está lanzando una versión 2.1 con cambios. Está claro que es una versión beta que no verá la luz hasta finales del próximo mes con el lanzamiento de tvOS y el nuevo Apple TV, pero este hecho me ha dado que pensar sobre un tema: ¿cuál es el coste que tiene para los desarrolladores las actualizaciones?

El problema de las actualizaciones

Vamos a ejemplificar este problema en el reciente caso de Bioshock, de la desarrolladora 2K Games. Este juego, que cuesta 9,99$, fue retirado sin publicidad ni aviso a nadie de la App Store hace unas semanas sin posibilidad de poder volver a descargarlo o instalarlo para sus actuales compradores y sin actualización alguna. ¿El motivo? La actualización de iOS 8.4 que lanzó Apple en el mes de junio hizo que dejara de funcionar y para evitar errores mayores y reviews negativas, la desarrolladora decidió “tirar por la calle de en medio” y quitar el juego de la venta para intentar arreglarlo, en una estrategia que tiene a todos sus compradores en un limbo por el que si actualizan el sistema no pueden jugar.

Hay aplicaciones, como por ejemplo la app de Yomvi de Movistar+, que tuvo que incluir un mensaje al iniciar la misma avisando a sus usuarios que iOS 8.4 provocaba errores en la reproducción de vídeo y hubo que esperar semanas hasta que sus desarrolladores lanzaron una actualización que solucionaba el problema y Apple se la aprobaba (tiempo a sumar). Pero, ¿de quién es la culpa?

App Review Times

Apple lanza siempre versiones beta para desarrolladores con un claro propósito: que estos prueben y verifiquen con estas versiones sus desarrollos para que “no les pille el toro”. Pero resulta que el tiempo medio de revisión de una app actualmente es de 7 días y el lanzamiento de las versiones nuevas nunca se publicita en forma alguna hasta que han salido o pocos días antes. Eso supone que nuestros usuarios siempre van un tener un “gap” o espacio de tiempo muerto en que el sistema se actualizará pero nuestra actualización no les va a llegar hasta pasada, al menos, una semana. El castigo y la mala imagen siempre recae sobre los desarrolladores y un sinfín de reviews negativas que afectan a la vida útil de la app.

Y por otro lado, y está demostrado, Apple sigue haciendo cambios beta tras beta y las verdaderas pruebas finales solo pueden certificarse con las versiones finales que lanza, lo que aumenta más el tiempo entre que el desarrollador lanza la actualización y el usuario puede descargarse estas. El desarrollador de Onyx (excelente herramienta de mantenimiento de OS X) ya dice en su web que no da soporte a versiones beta porque Apple cambia muchas cosas en su desarrollo con respecto a las versiones finales, lo que supone que hasta que no se lanza la versión final no se pone a trabajar en adaptar sus programas a nuevas versiones.

El coste de las actualizaciones

Si analizamos el panorama nos encontramos que Apple lanza una nueva versión de su sistema todos los años, sistema que en apenas una semana ya está instalado en más del 50% de los dispositivos activos, lo que supone que la mayoría de nuestro público actualiza y quiere las nuevas funciones del sistema y eso nos obliga a actualizar. El problema de las major versions puede verse mitigado porque en cierta forma estamos prevenidos, pero durante el año Apple lanza más versiones. iOS 8 ha tenido versiones hasta la 8.4.1, y todas ellas con cambios donde las betas no han sido suficientes para anticiparse.

El coste de una actualización

Pero, ¿qué cuesta actualizar una app? Depende del tipo que tengamos, pero hacer pruebas unitarias de la misma para verificar que todo funciona no es tarea sencilla. Por ejemplo, existen muchas apps que funcionaban a través de red que han dejado de funcionar convenientemente con iOS 9 porque ya no admite conexiones no cifradas a través de red.

Existen muchos casos de desarrolladores contratados para un trabajo concreto que, terminado el trabajo, ni se han preocupado de actualizaciones ni de nada. Ni siquiera sabrán que su app no funciona porque ellos ya vendieron y “no es su responsabilidad”. Lo es de una empresa que quiere dar un servicio y que, al delegar tareas técnicas en subcontrataciones, ni se han enterado que su app ya no sirve.

Equipo de desarrolladores de Agile Bits (1Password)

Tener una app que funcione como un reloj en cuanto a actualizaciones y desarrollos supone un coste muy alto y la implicación de un gran equipo, como el que podemos ver en la imagen: el equipo de Agile Bits, creadores de 1Password, que son una de las pocas compañías que consiguen ir por delante del ciclo de las actualizaciones e incorporar los primeros la gran mayoría de nuevas funciones de las nuevas actualizaciones o de nuevos dispositivos que Apple pueda lanzar.

Si el producto es nuestro supone costes a veces muy altos y que no todos los estudios podemos asumir fácilmente. Por ejemplo: centrémonos en el caso del nuevo iPad Pro o el que sucedió hace un año con los nuevos iPhone. Por mucho que Apple ponga las cosas fáciles, si tenemos un juego o una app que usa recursos gráficos, adaptar la misma no es tarea fácil y pueden pasar meses hasta que conseguimos adaptar convenientemente nuestro trabajo (con el consiguiente coste económico). A día de hoy, existen multitud de aplicaciones que aun no están adaptadas a las pantallas del iPhone 6 o 6 Plus. Solo tenemos que recordar apps como LinkedIn o Whatsapp que tardaron meses en actualizarse para estas.

Adaptar una app a nuevas funciones no es sencillo en muchos casos y supone mucho tiempo de desarrollo para obtener una satisfacción de cliente que no reporta una monetización directa del trabajo en muchos casos. Entre otras cosas supone:

  • Rediseño de las interfaces soportando nuevas reglas de restricciones de los auto-layout que las nuevas versiones pueden ir incorporando y que a veces puede llegar a suponer un rediseño desde 0.
  • Actualizar todas las interfaces a nuevos estilos como la incorporación de las clases de tamaño que iOS 8 añadió. Igualmente esto supone a veces volver a la mesa de diseño desde 0.
  • Generar recursos gráficos para soportar nuevos modos como el @3x del iPhone 6 Plus, el nuevo modo @1x del Apple TV que tiene un set de gráficos para él solo, o el futuro y posible modo @3x del nuevo iPad Pro (aun no activo). Si trabajamos con gráficos vectoriales puede ser sencillo, si no, puede que hasta tengamos que re-generar los recursos gráficos de nuestra app o juego.
  • Adaptación a nuevos modos de pantalla y relación de aspecto en determinados tipos de productos, o por ejemplo, adaptar interfaces y aspectos a la nueva multitarea del iPad con los nuevos modos Slide Over y Split View.
  • Adaptar nuestras comunicaciones de red en las apps a nuevas librerías de comunicación o criterios como el actual de iOS 9 que exige comunicaciones encriptadas a través de TLS 1.2.
  • Refactorización del código en Swift de nuestras aplicaciones, ya que la versión 1 no es compatible con la 2 y el asistente de refactorización de Xcode 7 no es 100% efectivo y requiere un importante trabajo de revisión por nuestra parte.

App Thinning

  • Incorporación de nuevos modos de trabajo y funcionamiento de apps, como el App Thinning, muy interesante para los desarrolladores pero que supone un trabajo extra de organización de contenidos.
  • Actualizar las librerías de terceros que usemos para todo tipo de tareas (tareas de red, publicidad, compras…) que en muchos casos tardan más tiempo de lo necesario en actualizarse o ni se actualizan. Tenemos casos como librerías que soportan apps completas que obligan a los desarrolladores a mantenerlos ellos mismos y no quien las creó o, por ejemplo, el caso de Cocos2D que actualmente ha detenido su desarrollo quedando condenado a la obsolescencia hasta que sea hecho desde 0 en Swift.
  • Depender de ciclos de actualización de herramientas que usemos, que no sean Xcode, como Unity o Unreal en caso de juegos o Xamarin en caso de apps (por citar algunos ejemplos). Hasta que estas herramientas no se actualizan, no podemos actualizar y soportar las nuevas funciones e incluso a veces, nuestra app falla en las nuevas versiones por culpa de una mala adaptación de las herramientas que por otro lado, tardan más de la cuenta en actualizarse ya que no es tarea sencilla. Cosa que puede ser aplicada también si usamos SDKs de terceros como Facebook o Google para integrar servicios de estos.
  • Lidiar con fallos no corregidos por Apple, como el hecho que a día de hoy SpriteKit (juegos 2D) no puede usarse junto a los nuevos catálogos de recursos porque no reconoce correctamente las imágenes y no podemos usar App Thinning hasta que se arregle.
  • Sufrir los cambios de criterio en las normas de la App Store de la noche a la mañana, que retrasan desarrollos y que no pueden justificarse en manera alguna ante clientes o proveedores y suponen pérdidas. En nuestro caso, hace años vimos como una app que dependía de una fecha para ser publicada con el objeto de ser presentada en una feria, era rechazada por Apple porque en la librería que habíamos incluido de Google Analytics, se usaba un modo de rastreo a través de un identificador, que Apple decidió de la noche a la mañana que solo podía usarse si la app tenía publicidad. Una norma que activó durante el periodo de espera de revisión de nuestra app y que supuso un retraso de una semana en la publicación, quitar Google Analytics porque no se había arreglado este error y se tardó meses en que se corrigiera por parte de Google y unas consecuentes pérdidas económicas y mala imagen ante proveedores por una consecuencia que no era culpa nuestra.

Estos son pequeños ejemplos del camino de espinas que un desarrollador tiene que recorrer para “estar al día” cuando, como hemos dicho, la monetización y amortización del esfuerzo no aporta nada al mismo o casi nada. Hace años, cuando Rovio lanzaba una nueva actualización de Angry Birds con nuevos episodios (cuando el juego era de pago) suponía un aumento de las descargas. A día de hoy, el lanzamiento de una actualización, aun con más contenido, no supone un pico de nuevas descargas ni repercute o beneficia a nadie, salvo a Apple que ve que las apps se adaptan a las nuevas funciones de su sistema.

El trabajo que realizan en Apple es encomiable porque en muchos casos la incorporación de nuevas funciones está muy trabajada, pero en otros no tanto y al final nos encontramos con que el trabajar con una app es un trabajo que nunca acaba, a no ser que publiquemos y nos importen poco las nuevas funciones, dispositivos y demás, provocando que nuestro trabajo se vaya convirtiendo en obsoleto por sí solo con el paso del tiempo hasta que llegue un momento en que deje de funcionar directamente en ninguna nueva versión.

Posibles soluciones

La solución a este problema pasa por una unión y esfuerzo de cada uno de los grupos implicados, a mi modo de ver. Por un lado Apple tendría que arrimar el hombro con los desarrolladores y permitirles ventanas más claras para probar y actualizar sus desarrollos, para que el estar al día no suponga para quien desarrolla un tiempo de incertidumbre mientras espera que aprueben su app. Este año, ha habido una ventana de 7 días desde que Xcode 7 permitió enviar actualizaciones a iOS 9 hasta que se lanzó el sistema. El mismo tiempo que tardan en revisar. Es claramente insuficiente.

Además, Apple debería incorporar nuevos modelos de negocio a la App Store que permitieran monetizar a los desarrolladores el coste de los desarrollos. Son muchos meses de trabajo y prueba para darlos gratis porque sí, salvo que nuestra monetización no dependa de la app o juego en sí. Un sistema de pago por upgrades que permita que nuestros usuarios puedan volver a pagar (si quieren) por obtener la nueva versión que hace cosas mucho mejores que la anterior (pudiendo quedarse con la versión anterior si les es suficiente) incentivaría la inversión en trabajar en más y mejores actualizaciones.

Pero para eso los usuarios tienen que acostumbrarse a pagar por las apps. Estamos hablando de un problema gravísimo en donde la piratería se ceba con el software. La música y el cine tienen índices de piratería y pérdidas ínfimos comparados con el software (se estima que en 2014 el cine perdió 73.000 millones por la piratería y el software 652.000 millones). Los desarrolladores tienen que luchar con que el pirateo es una costumbre aceptada y el repartirse gratis el trabajo de equipos de personas durante meses no despierta conciencia alguna en muchos usuarios.

Piratería 2014

Imagine que usted es panadero y tiene que lidiar en su negocio que todos los días más del 50% de lo que produce la gente se lo lleva gratis sin que usted pueda hacer nada. O que sea fontanero y la mitad de los clientes le paguen por su trabajo y el resto no lo hagan y no pueda hacer nada al respecto. Sería absurdo, ¿cierto? Por ese mismo motivo se han creado modelos como los de las apps que piden una monetización mínima que aun así, sigue siendo pirateada sin ningún tipo de problema.

Voy a ejemplificar un caso concreto: “Monument Valley” de usTwo. La compañía hizo públicos los costes de producir el juego no hace mucho: 852.000$ en 55 semanas de trabajo de un equipo de 8 personas para sacar adelante un juego de 4$. 549.000$ en el caso del episodio extra que sacaron después durante 29 semanas a un coste de 2$ la actualización. Y el juego se llenó de reviews de una estrella porque la gente se creía en el derecho que los nuevos episodios fueran gratis. ¿De verdad? ¿Por 2$? ¿Para amortizar 29 semanas de trabajo de un equipo de 8 personas y una inversión de más de medio millón de dólares?

Sin embargo, no se pierdan el curioso tweet que la compañía publicó sobre sus índices de piratería, a pesar de haber conseguido amortizar suficientemente el producto.


¡Solo un 5% de las copias en Android son legales y un 40% de las de iOS! Más de la mitad de los usuarios de iOS tienen el juego pirata a través de jailbreak y un vergonzoso 95% de los de Android no han pagado por el mismo (¿alguien duda por qué Android no es una plataforma rentable donde invertir en productos de pago?). Busquen en Google “Monument Valley” y vean como una de las opciones que da de búsqueda sugerida es “Monument Valley apk”… ya sabemos qué significa. Un juego de 6$ en total que ha requerido una inversión de más de un millón de dólares como producto y un año y medio de trabajo. ¿De verdad a alguien le parece justo este hecho?

Y sinceramente, no sé qué placer obtiene alguien en piratear el trabajo de un equipo de personas o de una persona durante semanas y meses, sacrificando mucho, cuando el coste de su producto es un dólar o 2 o como mucho 6, como el caso expuesto. Cantidades que gastamos libremente en muchas otras cosas más superficiales o efímeras en el tiempo. Mucha gente prefiere tomarse dos cervezas por 5€ que se las toma y se acabó, pero la app Fantastical que me permite trabajar día a día la tengo pirata. Se mire como se mire no tiene sentido. Por eso, una parte de la solución la tiene el usuario.

Y la parte del desarrollador también existe, porque parezca o no mentira, el 97% de la piratería actual de software en todos los sistemas está propiciada por un trabajo deficiente en los sistemas de protección del propio software (casi parece como que el desarrollador acepte que será pirateado y por eso no invierte en proteger su trabajo). Y también el trabajo está en probar y sacar con mejores garantías las aplicaciones para garantizar una correcta funcionalidad desde el momento 0 y no acostumbrarse a la tan poco profesional filosofía de: “tú sácalo ya, que si tiene fallos ya los iremos corrigiendo”.

Conclusiones

Es un problema, importante, requiere de todos los actores para ser solucionado y esperemos que poco a poco vaya llegando a buen puerto. Este artículo pretende exponer problemas, intentar despertar alguna conciencia de todos los actores implicados y exponer una realidad. ¿Qué opináis vosotros de este tema? Dejadnos vuestra opinión para así tener más puntos de vista. Espero que esto genere un debate interesante. Un saludo y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Phil Schiller - App Store

Mantener un desarrollo con el precio que se pagó hace años

Analizamos y opinamos sobre el difícil modelo de mantener una app con el cobro realizado en el pasado y las últimas opiniones de Phil Schiller, responsable de marketing de Apple. Opinamos sobre la difícil situación de mantener un producto vivo cuando ya se cobró por él y el usuario no tiene la percepción que debería pagar de nuevo e incluso periódicamente. Un debate abierto para opinar.