Admite múltiples versiones de aplicaciones móviles

Estamos creando un conjunto de aplicaciones móviles nativas para complementar nuestra aplicación existente que actualmente solo admite una interfaz web para el servidor. La aplicación puede ser instalada y alojada por clientes en su propia infraestructura o alojada por nosotros mismos para clientes que quieran utilizarla. Los clientes de grandes empresas generalmente optan por autohospedarse, mientras que los clientes más pequeños eligen nuestra opción de alojamiento.

Necesitamos soportar múltiples versiones de la aplicación. No todos los clientes desean actualizar al mismo tiempo. Con la interfaz web, el soporte de múltiples versiones no es difícil ya que la interfaz web usa automáticamente la versión del servidor asociada con su instalación del servidor. Con las aplicaciones móviles en las que normalmente solo tiene una aplicación disponible en las tiendas de aplicaciones, el soporte para diferentes niveles de API del servidor y la funcionalidad en la aplicación móvil se convierte en un desafío. Me interesa saber cómo otras personas están resolviendo el problema. En mi opinión, tienes opciones como:

1. Admite múltiples versiones de la aplicación en la tienda de aplicaciones.
2. Desarrolle soporte en las aplicaciones móviles para determinar automáticamente la versión API del servidor con el que está hablando y enrutar llamadas a los puntos finales API del servidor relevante. También presente el uso de algún tipo de mecanismo de alternancia de funciones para habilitar / deshabilitar la funcionalidad en la aplicación móvil en función de lo que está disponible en las diferentes versiones del servidor.
3. No use la tienda de aplicaciones para implementar su aplicación. Dirige a los usuarios a una URL específica de la versión que pueden usar para descargar e instalar la aplicación.

Opción 1 : IMO creará confusión para los usuarios de la aplicación. Tampoco hay una buena ruta de migración de una versión de la aplicación a la siguiente, ya que realmente son dos aplicaciones separadas.

Opción 2 : por otro lado, puede volverse muy complejo rápidamente si tiene en cuenta que las imágenes de su interfaz de usuario ahora básicamente necesitan adaptarse a cualquier funcionalidad disponible en la versión de la API del servidor con la que está hablando. También debe admitir las diferentes versiones de las llamadas API del servidor que debe realizar.

Opción 3 : es posible en el mundo de Android cuando se realiza una carga lateral de su aplicación, pero que yo sepa no es compatible con iOS y no estoy seguro de cuál será la imagen para las aplicaciones móviles de Windows 10 en adelante.

¿Qué otros enfoques hay para abordar el problema? No discuta el hecho de que estamos escribiendo aplicaciones nativas. Eso no es lo que estoy preguntando. Estoy buscando orientación sobre cómo otras personas están abordando el problema de admitir múltiples versiones de la misma aplicación móvil nativa hablando con diferentes versiones de una API de servidor.

Mira lo que sucederá ...

La opción 1 generará llamadas de soporte cuando los usuarios instalen la versión incorrecta. Siempre habrá un usuario que no podrá leer o elegir la última versión pensando que lo conoce mejor ... y tendrá una gran cantidad de versiones a las que posiblemente respaldar las correcciones si es necesario.

La opción 2 agrega cierta complejidad al código de la interfaz de usuario, cuánto depende de qué tan bien la interfaz de usuario esté escrita para ser adaptativa. Pero tiene la mejor experiencia de usuario.

La opción 3 no puede suceder en iOS (Android y Windows lo permitirán en ciertas configuraciones), lo que significa diferentes comportamientos para diferentes plataformas. Eso hace que las cosas sean inconsistentes, lo cual es una receta para los problemas.

Fuera de eso, hacer una interfaz de usuario receptiva y apuntar al punto final correcto es, con mucho, la mejor manera de ir para sus usuarios.

He tratado esto en un contexto ligeramente diferente, pero lo que se nos ocurrió fue que si usabas nuestro servidor público, necesitábamos que actualizaras. Si se hospeda por su cuenta, le permitimos permanecer en la versión que desee.

Sé que esa no es la respuesta más amigable para el cliente, y puede que no sea una opción dependiendo de su situación, pero fue la postura que terminamos tomando.

Una cosa a tener en cuenta: terminamos teniendo que hacer muchas excepciones basadas en líneas de base antiguas que se alojaban automáticamente cuando encontramos problemas de seguridad o errores importantes. Si admite varias versiones, ya sea como lo hicimos nosotros o si termina admitiendo múltiples API por completo, debe asegurarse de tener una gestión de configuración sólida y un control de origen. A medida que encuentre errores, asegúrese de tomarse el tiempo para volver a encontrarlos en su origen, ya que es posible que deba repararlo en una rama antigua.

El control de versiones de la API está bien, pero esto requeriría más trabajo en la capa de la interfaz de usuario a) La interfaz de usuario necesita saber qué versión de la API invocar dependiendo de la configuración (use un archivo de propiedades o un archivo de recursos en el dispositivo cliente)

b) Además, el servidor debe tener soporte para múltiples versiones de las API.

¿La API del servidor solo atiende a clientes móviles o también tiene otros clientes? Si atiende a otros clientes, entonces solo para dispositivos móviles es posible que desee obtener una API de contenedor que básicamente llame a la API del servidor en un extremo con soporte de versiones.

Básicamente, el control de versiones es difícil en la API del servidor si hay otros clientes como API públicas que son atendidos por la API del servidor; de lo contrario, es simple.

Mis 2 centavos