Suporte para várias versões de aplicativos para dispositivos móveis

Estamos construindo um conjunto de aplicativos móveis nativos para complementar nosso aplicativo existente que atualmente suporta apenas uma interface da web para o servidor. O aplicativo pode ser instalado e hospedado por clientes em sua própria infraestrutura ou hospedado por nós mesmos para clientes que desejam utilizá-lo. Os clientes de grandes empresas geralmente optam por se auto-hospedar, enquanto os clientes menores escolhem nossa opção de hospedagem.

Precisamos oferecer suporte a várias versões do aplicativo. Nem todos os clientes desejam atualizar ao mesmo tempo. Com a interface da web, o suporte a várias versões não é difícil, pois a interface da web usa automaticamente a versão do servidor associada à instalação do servidor. Com aplicativos móveis nos quais você normalmente só possui um único aplicativo disponível nas lojas de aplicativos, o suporte a diferentes níveis da API do servidor e a funcionalidade no aplicativo móvel se tornam um desafio. Estou interessado em saber como outras pessoas estão resolvendo o problema. Na minha opinião, você tem opções como:

1. Ofereça suporte a várias versões do aplicativo na loja de aplicativos.
2. Crie suporte para os aplicativos móveis para determinar automaticamente a versão da API do servidor com o qual está falando e rotear chamadas para os terminais da API do servidor relevantes. Também introduza o uso de algum tipo de mecanismo de alternância de recurso para ativar / desativar a funcionalidade no aplicativo móvel com base no que está disponível nas diferentes versões do servidor.
3. Não use a loja de aplicativos para implantar seu aplicativo. Aponta os usuários para um URL específico da versão que eles podem usar para baixar e instalar o aplicativo.

Opção 1 - O IMO criará confusão para os usuários do aplicativo. Também não há um caminho de migração agradável de uma versão do aplicativo para a próxima, pois são dois aplicativos separados.

Opção 2 - por outro lado, pode se tornar rapidamente muito complexa se você levar em consideração que os recursos visuais da interface do usuário agora precisam basicamente se adaptar a qualquer funcionalidade disponível na versão da API do servidor com a qual está falando. Ele também precisa oferecer suporte às diferentes versões das APIs do servidor que ele precisa fazer.

Opção 3 - é possível no mundo Android ao fazer o carregamento lateral do seu aplicativo, mas até onde eu sei não é suportado no iOS e não tenho certeza de qual será a imagem dos aplicativos móveis do Windows 10 no futuro.

Que outras abordagens existem para resolver o problema? Por favor, não discuta o fato de que estamos escrevendo aplicativos nativos. Não é isso que estou perguntando. Estou procurando orientação sobre como outras pessoas estão lidando com o problema de oferecer suporte a várias versões do mesmo aplicativo móvel nativo conversando com versões diferentes de uma API de servidor.

Veja o que vai acontecer ...

A opção 1 gerará chamadas de suporte quando os usuários instalarem a versão errada. Sempre haverá um usuário que não pode ler ou escolher a versão mais recente pensando que conhece melhor ... e você terá um grande número de versões para possíveis correções de backport, caso seja necessário.

A opção 2 adiciona alguma complexidade ao código da interface do usuário, quanto depende de quão bem a interface do usuário foi escrita para ser adaptável. Mas tem a melhor experiência do usuário.

A opção 3 não pode acontecer no iOS (o Android e o Windows permitirão isso em determinadas configurações), o que significa comportamentos diferentes para plataformas diferentes. Isso torna as coisas inconsistentes, o que é uma receita para problemas.

Portanto, criar uma interface do usuário responsiva e direcionar o endpoint correto é de longe o melhor caminho a percorrer para os usuários.

Eu lidei com isso em um contexto um pouco diferente, mas o que descobrimos foi que, se você usava nosso servidor público, solicitávamos a atualização. Se você se hospedou, permitimos que você permanecesse na versão que mais gostou.

Sei que essa não é a resposta mais amigável para o cliente e pode não ser uma opção, dependendo da sua situação, mas foi a postura que acabamos adotando.

Uma coisa a ser observada: acabamos tendo que realizar várias ações pontuais com base em linhas de base antigas que estavam sendo auto-hospedadas quando encontramos problemas de segurança ou bugs significativos. Se você oferece suporte a várias versões, seja como nós, ou se você suporta totalmente várias APIs, precisará garantir um gerenciamento sólido de configuração e controle de origem. À medida que você encontrar erros, reserve um tempo para fonte-los de volta para onde foram originados, pois talvez você precise corrigi-lo em uma ramificação antiga.

O controle de versão da API é bom, mas isso exigiria mais trabalho na camada da interface do usuário a) A interface do usuário precisa saber qual versão da API chamar dependendo da configuração (use um arquivo de propriedades ou um arquivo de recurso no dispositivo cliente)

b) Além disso, o servidor precisa ter suporte para várias versões das APIs.

A API do servidor atende apenas a clientes móveis ou possui outros clientes também. Se ele atende a outros clientes, apenas para o Mobile, convém obter uma API de wrapper que basicamente chama a API do servidor em uma extremidade com suporte a versão.

Basicamente, o controle de versão é difícil na API do servidor se houver outros clientes, como APIs públicas, atendidos pela API do servidor, caso contrário, é simples.

Meus 2 centavos.