Written by

Aplicativos híbridos ou nativos: o quê levar em conta na escolha?

Sem categoria| Views: 385

Várias discussões mantém o mundo mobile aquecido, desde o notável crescimento de algumas fintechs mobile based, passando pelas novas versões de sistemas operacionais ou devices (smartphones e wearables) e é claro, as diferenças do desenvolvimento mobile frente a outras plataformas. A escolha da tecnologia para criar um app é uma destas discussões e a seguir discorremos sobre como enxergamos a diferença entre lamentar prejuízos e escolher com louvor:

 

Falando em bom senso

Nada melhor do que o bom senso para conduzir reuniões, sejam elas de planejamento de escopo de projeto ou definições técnicas relacionadas a arquitetura do aplicativo. O fato é que a presença ou ausência do bom senso traz consigo elogios e críticas, respectivamente.

Este comportamento será o amigo número um durante a escolha da tecnologia a ser utilizada para desenvolvimento do aplicativo. Dizemos isso pois à primeira vista é muito simples considerar o desenvolvimento híbrido ou cross-platform como as melhores opções, afinal, quem não quer construir um aplicativo em menor tempo e ainda vê-lo operar em todos os Sistemas Operacionais mobile? Agir desta maneira ou criar projetos para atender nativamente os SOs mais expressivos (Android, iOS, W. Phone)? A diferença é insana e parece injustificável, contudo, nem tudo deve ser levado a ferro e fogo, keep reading.

“Escolhi a melhor tecnologia” vs “Escolhi uma boa tecnologia”

Observamos que, na esmagadora maioria dos casos, o desenvolvimento híbrido é levado em conta na situações abaixo:

 

  1. “Não tenho tempo para desenvolver um aplicativo nativo para cada Sistema Operacional.”

  2. “Não tenho dinheiro para desenvolver um aplicativo nativo para cada Sistema Operacional.”

 

O que as situações 1 e 2 têm em comum é que são cenários nos quais o dev. híbrido está sendo levado em conta pois falta algum recurso – tempo ou dinheiro – alegadamente requerido para o desenvolvimento nativo, e não por ser a melhor opção. Caso a decisão não leve outros fatores em conta, agir assim pode ser equivalente a beber óleo por falta de dinheiro ou tempo para buscar água. O exemplo anterior parece extremo, mas observe as situações 3, 4 e 5 abaixo, nas quais os motivos do desenvolvimento híbrido ser considerado nos parecem muito mais plausíveis:

 

  1. “O escopo do meu aplicativo é enxuto, de modo que seu uso não será recorrente ou este manipulará dados em um cenário de baixa complexidade (integrações e carga)”;

 

  1. “O grau de exigência de meu público alvo frente a performance do app não é alto”;

 

  1. “Meu aplicativo não abriga funcionalidades específicas que requerem uso desenvolvimento nativo para sua operação adequada.”

 

Nestas situações, o desenvolvimento híbrido foi tratado como a melhor opção por motivos baseados no projeto e público alvo, e não como uma medida paliativa ao desenvolvimento nativo. Compreende a diferença?

 

Haters gonna hate

O desenvolvimento híbrido e também o cross-platform são excelentes abordagens de desenvolvimento para aplicativos, entretanto, devemos avaliar sua escolha sob os mesmos parâmetros que utilizamos ao avaliar o dev. nativo: os seus prós e contras se encaixam na realidade e expectativa atuais e futuras do projeto? (Quem sabe tema de um próximo artigo, rs).

 

Enxergamos que surgem várias opiniões fanáticas sobre essa escolha, principalmente porquê aqueles que formam tais opiniões buscam escolher o que lhes é mais favorável como fornecedores e não o que é mais favorável ao projeto/cliente.

 

Gato por lebre

É responsabilidade do fornecedor explicar tais diferenças ao patrocinador do projeto e embasar a decisão em argumentos concretos. Quando isso não acontece, a negligência entra em cena e a tecnologia mais favorável ao fornecedor (nativa ou híbrida) é utilizada, seja para aumentar sua lucratividade ou até mesmo por este não possuir uma equipe especializada que atenda o que o projeto precisa. Sabemos quem paga essa conta.

 

A verdadeira lebre não é o desenvolvimento nativo ou híbrido, mas sim desenvolver algo mais robusto do que o necessário ou algo que atenda a necessidade momentânea mas falhe na evolução. Copy?

 

Contrate certo

A contratação de um bom fornecedor mitiga as situações adversas que abordamos neste artigo.

 

Seja tempo: caso o projeto grite por dev. nativo, a boa fábrica de software mobile deve possuir equipes de desenvolvimento especialistas em cada Sistema Operacional. Isso permite que o desenvolvimento seja realizado paralelamente e que haja entrega única.

A garantia de que os profissionais (analistas, designers e desenvolvedores) envolvidos em seu projeto sabem como o SO funciona e, ainda mais, como os usuários do referido sistema se comportam durante o uso de um app trará absurdo ganho na aceitação de seu aplicativo.

 

Seja custo: neste cenário cremos que a argumentação é um tanto contextual, visto que declinar o uso de uma tecnologia por custo pode ou não ser viável de acordo com a realidade do seu projeto/empresa. Além disso, existem diversas abordagens para que o projeto seja bem sucedido com orçamento reduzido, isso nos leva ao Mínimo Produto Viável 🙂

 

Esperamos que a reflexão acima tenha sido imparcial e esclarecedora, assim como que contribua com seus projetos.

 

Capptan | mobile expert.

Comments

comments

[mc4wp_form id="154"]