Aplicativos para Smartphones: Nativos ou Multiplataforma?

Paulo Matuki da Cunha
Venturus
Published in
6 min readApr 4, 2019

Precisamos de um aplicativo compatível com Android e iOS”. Este é um requisito inicial muito comum de se ouvir em uma primeira conversa com potenciais clientes. Exceto em casos mais raros em que a aplicação deve rodar em dispositivos móveis específicos, abranger as duas plataformas é obrigatório para que o produto não exclua uma fatia enorme de usuários.

Normalmente, esse requisito vem acompanhado de uma pergunta importante do cliente: é possível reduzir os custos de desenvolver aplicações utilizando uma ferramenta multiplataforma e “gerar” versões para qualquer dispositivo?

Antes de tudo, não existe “bala de prata”

Uma resposta fácil para a questão, sem considerar em detalhes os requisitos de projeto e de negócios do cliente, deve ser recebida com desconfiança. Será feita uma escolha entre desenvolver dois projetos “nativos” com pouco ou nenhum código compartilhado, utilizar um framework multiplataforma como o React Native ou partir para uma alternativa web como Progressive Web Apps (PWA). Cada uma dessas opções pode impor ao cliente restrições técnicas, financeiras ou de distribuição que devem ser ressaltadas pelo parceiro ou time de desenvolvimento.

Requisitos: O diabo mora nos detalhes

Requisitos simples como “meu aplicativo precisa mostrar notificações a partir de mensagens push” ou “meu app precisa ser distribuído pela App Store” já poderiam excluir PWA como opção de projeto, pois o iOS não mostra notificações push de PWAs e a Apple não permite que esse tipo de aplicativo seja distribuído pela App store. Por outro lado, a facilidade de se distribuir PWAs pela web sem a necessidade de publicá-las no Google Play ou na App Store pode ser vista como uma vantagem dependendo dos objetivos do projeto.

Outros requisitos bem comuns como “meu aplicativo precisa estar integrado ao Amazon Web Services (AWS)” podem tornar o Flutter, um framework multiplataforma do Google que vem ganhando muito destaque ultimamente, caro ou inviável pela falta de um SDK para integração com o serviço. Apesar de ser possível contornar esse tipo de limitação escrevendo-se código nativo para cada uma das plataformas, o custo adicional diminui a competitividade e a própria vantagem de se desenvolver aplicativos híbridos.

Portanto, uma análise cuidadosa de quais plataformas ou alternativas conseguem atender a todos os requisitos técnicos e de distribuição do cliente é crucial antes de colocar todas as opções em cima da mesa.

Investimento e Talentos

O caminho tecnicamente seguro de desenvolver dois aplicativos nativos (Android e iOS) pode não ser uma alternativa viável para projetos pequenos ou mais simples que contam com um menor valor de investimento. Além de ser necessário executar na prática dois projetos paralelos, com recursos distintos, não se pode esquecer dos custos de manutenção duplicados. Além do duplo trabalho na correção de defeitos, tanto Google quanto Apple frequentemente pressionam desenvolvedores a atualizarem seus aplicativos devido a novas diretrizes de layout e segurança, por exemplo.

Por outro lado, mesmo utilizando-se um framework robusto como o React Native, é frequentemente necessário que os desenvolvedores também tenham algum conhecimento em Android e iOS para desenvolver ou utilizar componentes não fornecidos pela plataforma. Um dos problemas que levou o Airbnb a abandonar o React Native foi justamente a dificuldade em se encontrar desenvolvedores com experiência em React/Javascript, Android e iOS ao mesmo tempo.

É muito comum que empresas já estabelecidas tenham disponível um time de desenvolvimento experiente em tecnologias web. Uma solução inteligente nesses casos poderia ser escolher uma alternativa que aproveitasse esses talentos como desenvolver um PWA ou escolher um framework que gere aplicativos híbridos web como o Ionic. Porém, as restrições técnicas e de distribuição, além da performance e usabilidade inferiores dessas soluções precisam ser consideradas.

As opções

Poderíamos escrever um artigo para cada uma das opções de desenvolvimento, mas o infográfico acima é uma tentativa de resumir alguns dos principais prós e contras de cada uma. Da esquerda para a direita, o investimento em desenvolvimento tende a diminuir, assim como a curva de aprendizado para desenvolvedores Web. Porém, nesta direção diminui também a performance, a experiência do usuário e aumentam as limitações impostas aos requisitos de projeto, principalmente quando é necessário o acesso a funcionalidades de hardware.

Pode-se dizer que, as opções mais à direita do infográfico, tendem a ser mais vantajosas em termos de custo-benefício quando o projeto é mais simples, pouco dependente de hardware e mais focado em ilustrar dados disponibilizados por um serviço ou por redes sociais. Ainda assim, tais padrões normalmente não são suficientes para uma tomada de decisão informada e uma análise cuidadosa dos requisitos específicos de um projeto frente às capacidades de cada opção é essencial.

No infográfico, assim como neste artigo, citamos apenas algumas das principais plataformas híbridas disponíveis para cada opção. Para escolhe-las, levamos em conta a maturidade, o suporte da comunidade de desenvolvimento e a solidez das companhias por trás das mesmas.

Tomando a decisão

Levando-se tudo em consideração, ao selecionar um parceiro externo, é importante ter uma estimativa de tempo e custo da opção mais conservadora — dois projetos nativos (Android e iOS) — para servir como parâmetro de comparação. Qualquer opção que resultar em uma estimativa próxima à dos dois projetos nativos torna-se menos interessante, já que estes oferecem menos risco de projeto e maior qualidade.

O parceiro externo ideal também deveria apresentar uma ou duas alternativas ao desenvolvimento nativo e, no caso de rejeição de alguma, prover uma justificativa objetiva como “não podemos desenvolver um PWA porque seu aplicativo precisa utilizar Geofencing”. Esse tipo de detalhamento é importante pois permite que alguns requisitos sejam cortados caso não sejam essenciais, reabrindo o leque de opções de custo menor.

Quando se opta por desenvolver internamente, com equipes existentes ou contratando novos desenvolvedores, as linguagens de programação e plataformas nas quais esses profissionais têm experiência costumam ter um peso muito grande em suas respostas se são perguntados sobre quais são as melhores opções. É importante certificar que uma equipe mais voltada para tecnologias Web não superestime as capacidades de um framework específico e realmente garanta que todos os requisitos técnicos e de distribuição podem ser cumpridos pela plataforma ou ferramenta que escolherem. Por outro lado, é comum que desenvolvedores para plataformas nativas Android e iOS descartem rapidamente opções híbridas ou web, citando impedimentos como performance ou incapacidades que na realidade podem ser contornadas ou toleradas. Em alguns casos, uma pequena prova de conceito pode ser desenvolvida para “testar” a capacidade de uma tecnologia e medir a dificuldade de aprendizado que a mesma impõe à equipe.

Uma boa escolha entre as diferentes opções disponíveis deve ser compatível com os recursos disponíveis para investimento e o retorno esperado, mas também deve garantir que o cliente possa se concentrar nos seus requisitos de negócios sem ficar refém de limitações impostas pela plataforma que escolheu.

Fontes

[1] Progressive Web Apps (Google)

[2] Progressive Web Apps on iOS are here

[1] React Native at Airbnb

[3] React Native at Airbnb

[4] Flutter: the good, the bad and the ugly

[5] Lessons Learned from Cross-platform Mobile Development with Flutter

[6] Native, React-native or PWA, what should I choose?!

--

--