¿Debería una aplicación forzar al usuario a actualizarla o admitir compatibilidad con versiones anteriores?

Lo que hacemos es solo permitir versiones de aplicaciones lanzadas en los últimos K meses. Para esas versiones, escribimos código compatible con versiones anteriores. Un script desprecia automáticamente las versiones anteriores y crea tareas para eliminar el código para la compatibilidad con versiones anteriores de esa versión.

Mantener versiones antiguas es malo para la velocidad de desarrollo y la calidad del código, pero actualizamos con la frecuencia suficiente para que los usuarios puedan desinstalarlo si los obligamos a actualizar cada vez. También debe escribir cierto grado de compatibilidad con versiones anteriores, independientemente de que sean posibles los lanzamientos por etapas (generación de inserción al x% de los usuarios), por lo que el costo adicional de mantenimiento durante unos meses no es tan grande.

Esta es también una ventaja de las aplicaciones basadas en webview: podemos agregar características a las compilaciones antiguas, por lo que hay menos trabajo para admitir versiones antiguas de aplicaciones.

Si es posible, forzar la actualización.

Este es un gran problema para Microsoft. Todavía hay sitios que ejecutan XP. Es probable que haya cajeros automáticos y terminales POS que ejecuten incluso versiones anteriores.

Microsoft ha cavado el agujero: al cobrar por cada nueva versión, en lugar de solo suscribirse, las personas ven cada versión de Windows como un producto. Además, Microsoft tiende a hacer “saltos de estupidez” terribles al diseñar algunas de esas versiones. Por ejemplo, diseñar Windows 8 para tabletas, olvidando que necesita una PC para realizar cualquier trabajo. De esa manera, muchos se quedaron con Windows 7. Incluso cuando salió Windows 10, no fue una actualización obvia para muchos.

Suscripciones y “kill-switches” es el futuro.

Hay una versión de API para eso. En cada versión de la aplicación que distribuya, puede codificar la versión de API con la que puede funcionar. En los encabezados de solicitud, el cliente declara automáticamente su versión definida, que es compatible. Por lo tanto, puede ver dinámicamente qué clientes admiten las nuevas funciones (por ejemplo, la versión 0.3 ), pero cuáles están atascadas con las versiones anteriores de la API ( 0.1 o 0.2 por ejemplo). Y proporcionar las nuevas estructuras de datos solo para los clientes que pueden manejar eso.
De esa manera puede actualizar el lado del servidor sin romper los clientes heredados. Será complicado con ramificaciones y múltiples IF, pero podría valer la pena si tiene suficiente base de usuarios.

La alternativa fácil es simplemente mostrar “por favor actualizar” y cerrar. Puede ser complicado si las nuevas versiones de la aplicación son solo para las nuevas versiones del sistema operativo Android (5 o 6), pero el usuario ya usa la más antigua que se puede instalar en el Android 2.3 o 4.x heredado.

Personalmente, no creo que los usuarios deberían verse obligados a actualizar en general, pero en un mundo donde las aplicaciones se actualizan en base a una extensa investigación de los usuarios y donde el objetivo principal de las actualizaciones es mejorar la experiencia del usuario, creo que debería ser una obviedad para usuarios para decidir actualizar, pero la decisión siempre debe ser tomada por el usuario.

Brian (todavía pensando con cariño en los viejos tiempos de XP)