Leonardo Peron6 min de leitura
Se o aplicativo é para a sua equipe e a empresa compra o aparelho, lance numa plataforma só, a do aparelho que você vai comprar. Se é para o cliente final, lance nas duas ao mesmo tempo, porque nenhum cliente aceita ser deixado para a segunda fase.
A pergunta "iOS ou Android" quase sempre esconde outra: quem vai usar, e de quem é o celular. Respondida essa, a escolha de plataforma se resolve sozinha, e a de tecnologia fica bem mais simples do que parecia.
Três públicos, três respostas
Equipe de campo, com aparelho da empresa
Técnico, entregador, vistoriador, repositor. Quando a empresa compra o aparelho, a pergunta deixa de ser de mercado e vira de compra. Vale escolher um modelo, padronizar a frota e construir para ele. Uma plataforma, um modelo, testado de verdade, é mais valioso que duas plataformas testadas por amostra.
Na prática a escolha costuma cair no Android, por um motivo que não tem nada a ver com preferência: a oferta de aparelhos reforçados para campo, com leitor de código de barras embutido, capa que aguenta queda e bateria trocável, é majoritariamente Android. Se a empresa já tem uma frota de iPhone gerenciada, com política de segurança e suporte montados, o raciocínio se inverte. O critério é o mesmo: a plataforma do aparelho que já está, ou vai estar, na mão da equipe.
Equipe com celular próprio
Vendedor externo, representante comercial, corretor autônomo. Aqui a empresa não escolhe o aparelho, e qualquer decisão de plataforma deixa parte do time de fora. O app precisa sair nas duas. É o caso típico de um aplicativo de força de vendas: o representante usa o que já tem no bolso, e um app que não roda no celular dele é um app que ele não usa.
Cliente final
As duas plataformas, no mesmo dia. O cliente não sabe que existe uma fila de desenvolvimento e não vai esperar a versão dele. Lançar numa só é dizer a uma parte da base que ela não é prioridade, logo na primeira impressão.
Antes disso vale uma pergunta mais dura: o cliente vai abrir esse app com que frequência? Quem usa duas vezes por ano não instala aplicativo, e para esse público um portal responsivo resolve melhor, sem loja no caminho.
A estatística nacional não decide
É comum abrir a discussão pela divisão de mercado entre as duas plataformas no Brasil. Ela não ajuda. O público de um app de concessionária de carro de luxo não tem a mesma divisão que o de uma distribuidora de material de construção, e nenhuma média nacional conta isso.
O dado que importa é o seu. O relatório de acesso do site mostra de quais aparelhos os seus clientes chegam. O sistema atual, se tem versão web, mostra o mesmo sobre quem já usa. E no caso da equipe própria, basta perguntar.
Multiplataforma ou nativo
Esta é a decisão que mais mudou o peso da anterior. Com uma base multiplataforma, como React Native ou Flutter, o mesmo código atende as duas lojas, e a segunda plataforma custa principalmente teste, ajuste pontual e publicação, não uma reescrita. É o que usamos na maior parte dos projetos, e cobre o que um app de empresa costuma precisar: formulário, lista, câmera, foto, mapa, notificação e funcionamento sem sinal.
O nativo, com Swift no iPhone e Kotlin no Android, se justifica em casos específicos:
- integração pesada com hardware que só tem biblioteca nativa, como leitor industrial, impressora térmica por Bluetooth ou NFC com protocolo próprio;
- processamento intenso de imagem ou vídeo no próprio aparelho;
- recurso do sistema que acabou de ser lançado e ainda não chegou às bibliotecas multiplataforma.
Mesmo nesses casos a porta não se fecha: dá para escrever em nativo só o pedaço que precisa e manter o resto compartilhado. O custo real do nativo puro não é a primeira versão. São duas bases de código, duas filas de correção e, com o tempo, dois produtos que divergem em detalhes que ninguém decidiu.
O que cada plataforma cobra de quem desenvolve
Escolher uma plataforma é também escolher um conjunto de problemas.
No Android, a variedade é o ponto. Muitos fabricantes, muitas versões do sistema em uso ao mesmo tempo, e alguns fabricantes aplicam economia de bateria própria, que interrompe tarefa em segundo plano. Para app que sincroniza sozinho ou registra localização durante o dia, isso significa testar no modelo que a equipe vai usar, e não só no emulador.
No iPhone, a regra é o ponto. As restrições para rodar em segundo plano são mais rígidas, e o uso de localização contínua exige uma justificativa que o usuário lê e aceita. Tarefa que no Android roda sozinha pode precisar de outro desenho aqui. Em compensação, são poucos modelos para testar.
Nenhuma das duas é mais fácil. Elas são difíceis em lugares diferentes, e o desenho do app precisa saber em qual está pisando.
Quando lançar uma primeiro faz sentido
Lançar numa só é a escolha certa em três situações:
- Frota da empresa numa plataforma só. Não há o que esperar da outra.
- Piloto com um grupo pequeno. Quando a pergunta ainda é se a equipe vai trocar o papel pelo app, testar num grupo e numa plataforma responde mais rápido. É a lógica de uma primeira versão que responde uma pergunta, e não a de um produto pela metade.
- Prazo amarrado a uma data. As duas lojas têm contas, testes e revisões próprios, e a primeira publicação em cada uma tem os seus prazos. O caminho está no texto sobre publicação.
Fora dessas três, com base multiplataforma, lançar as duas juntas custa pouco a mais e evita a pior conversa do projeto: explicar para metade dos usuários por que eles ficaram para depois.
Para decidir esta semana
Cinco perguntas, nesta ordem:
- De quem é o aparelho: da empresa ou da pessoa?
- Quem usa: a equipe ou o cliente?
- O app precisa de algum hardware específico?
- Com que frequência cada pessoa vai abrir o app?
- Existe uma data que não pode escorregar?
Se as respostas apontarem para a equipe com aparelho da empresa, o caminho é um aplicativo Android na maioria dos casos, ou um aplicativo para iPhone quando a frota já é Apple. Se apontarem para cliente com uso raro, a resposta honesta é não fazer app, e é isso que dizemos no diagnóstico.