Híbrido vs Nativo

Vantagens e desvantagens de desenvolver um app híbrido

Taqtile

Published in

TaqtileBR

7 min readOct 13, 2016

“ Por que não híbrido? "

Essa é uma pergunta relativamente comum, mas que temos ouvido com maior frequência nos últimos tempos. É o reflexo natural que vem em resposta à oferta de um desenvolvimento nativo.

E entender a natureza dessa curiosidade foi o que mais me empolgou quando me pediram para escrever sobre o ~polêmico~ embate do título. O que tem sido dito por aí que captou o interesse das pessoas? O que as motiva a buscar por um modelo alternativo de desenvolvimento?

Provavelmente um desses curiosos seja você, que chegou até esse post procurando as respostas de todas suas dúvidas (no clássico “quem é melhor”). Já peço desculpas de antemão. O intuito aqui não é deter a verdade, e sim, esclarecer algumas impressões sobre o desenvolvimento híbrido e dar a nossa opinião do cenário atual.

Primeiro, vamos definir quem é quem nessa disputa.

Nativo

Aplicações nativas são aquelas desenvolvidas com linguagem específica para cada plataforma. Seja Swift e Objective-C para iOS ou Java para Android. O modelo mais conhecido, mas nunca ortodoxo ou antiquado.

Híbrido

Aplicações híbridas são aplicações multi-plataforma. Elas permitem, por exemplo, que você construa um produto iOS e Android simultaneamente, em vez de desenvolver duas vezes usando a linguagem nativa de cada plataforma. Existem diversos caminhos para chegar lá, então explicamos alguns para pautar nosso comparativo.

Abordagem #1

São websites escondidos por trás de uma maquiagem nativa. Usando tecnologia mais relacionadas à web — como HTML5, CSS e Javascript — o código é encapsulado em containers nativos, carregando a maior parte da informação das páginas conforme o usuário vai navegando. Exemplos desse framework são Cordova e PhoneGap.

Abordagem #2

É o desenvolvimento utilizando uma única linguagem, nativa ou não, e que o framework compila para as demais plataformas. O resultado final são aplicativos com linguagem nativa que não foi gerada pelo desenvolvedor — o que pode dificultar muito sua evolução. Exemplo de tecnologia com essa abordagem é o Xamarin que gera aplicativos para iOS e Android usando C#.

Abordagem #3

É um misto no qual você pode criar partes do aplicativo em linguagem nativa e outras partes utilizando uma única linguagem que foi traduzida. A grande diferença entre essa e a abordagem anterior, é que o desenvolvedor tem total autonomia de editar o código gerado, podendo inclusive alterar a forma como ele trabalha. React-Native e Silver são exemplos de tecnologias que seguem esse formato.

A realidade

Todo mundo sabe como uma startup tem que fazer o melhor possível com recursos limitados. É nessa dinâmica que elas, mais que todo mundo, procuram otimizar e economizar. Logo, faz sentido a excitação anos de atrás em volta do surgimento do modelo híbrido. Dois apps pela metade do tempo (e do preço). Soa bem, né? Lançar um app simples o quanto antes, validar o investimento e partir para próxima etapa. Além de que os híbridos não precisam de mão de obra especializada em cada plataforma na sua manutenção. Ou seja, mais uma economia a longo prazo.

Mas será que isso se aplica à realidade de grandes empresas também? Aliás, será que o modelo híbrido é a melhor opção para qualquer tipo de startup? Conforme a mentalidade de startup penetrou em grandes corporações, alguns modelos vieram junto. Normalmente, a decisão de criar um app implica em alcançar um competidor ou aproveitar uma brecha de mercado. Em ambos os casos, as diretrizes do projeto são as mesmas: o quanto antes e com o menor custo. Mas às vezes, o barato sai caro. Por isso, trouxemos abaixo algumas peculiaridades para você se questionar.

Tecnologia

Roi Kraus, CTO da LTG Exam Platform, escolheu o modelo híbrido para desenvolver a primeira versão de um app preparatório para testes de pós graduação em admnistração, o Prep4GMAT. Alguns formulários com perguntas, alguns relatórios e tudo certo. Fácil, né? Não. Se o escopo aparentemente simples permitiu adotarem o modelo híbrido, à medida que o app foi se tornando mais complexo tiveram que optar pelo desenvolvimento nativo.

“ The simplicity of hybrid development was the driving factor for deciding to adopt it when we began working on the Android version of our first app, Prep4GMAT. But as we found out first hand, simplicity and ease of use can come with high costs once your app gets more complex; we had no choice but to switch back to native development. ”
Roi Kraus

Aplicativos que exigem tarefas mais complexas, acessando funções nativas do aparelho como câmera, localização e outros sensores, não se saem tão bem quando desenvolvidos em linguagens diferentes da nativa. Nesse quesito, os híbridos da primeira abordagem são os que mais deixam a desejar.

Em seguida vem a abordagem que tem seu código final nativo gerado pelo framework — que muitas vezes é uma “caixa-preta” para o desenvolvedor — e em que a resolução de bugs acaba sendo mais difícil. Já a terceira abordagem permite a evolução do código gerado para cada plataforma apresentando uma flexibilidade maior.

Usabilidade

A experiência atrelada ao uso de um aplicativo é um dos fatores que mais importam para o usuário não desinstalá-lo. Quando a experiência não se oferece como natural e a interface não é intuitiva, o app perde seu espaço para a concorrência. Nesse aspecto, os híbridos da abordagem #1 pecam quando trabalham com uma arquitetura única para Android e iOS.

Alguns usuários podem não se sentir confortáveis ao se virar em um app híbrido. Isso porque as diretrizes do guideline do sistema operacional não são atendidas quando componentes já conhecidos pelo usuário são adaptados em uma experiência não completamente nativa. É como esperar que um usuário de Android use iPhone com a mesma facilidade.

Nesse aspecto, novamente, a abordagem híbrida tradicional é a que mais peca ao trabalhar com uma interface única para Android e iOS. As outras abordagens híbridas permitem que os desenvolvedores criem diferentes interfaces para cada plataforma. Já a terceira abordagem é a que dá maior liberdade, uma vez que você pode ter código 100% nativo para criar as interfaces do aplicativo e um código “replicado” rodando nas outras camadas da aplicação.

Performance

Se problemas de design não são o suficiente para estragar a experiência de um usuário, problemas de performance são o que realmente compromete um aplicativo. Ninguém gosta de apps lentos e que travam.

Nesse aspecto, apps nativos são bem mais confiáveis e rápidos já que são desenvolvidos especificamente para o sistema operacional em que rodam. Seguindo os guidelines já citados, eles são mais refinados na interação de componentes, como em animações, transições, conteúdos, estrutura e elementos que já são parte do sistema, carregados sem dificuldade e garantindo uma experiência mais suave.

A abordagem #1 traz ainda outras desvantagens, como maior tempo para carregamento ao depender da internet para carregar conteúdos estáticos-que muitas vezes são baixados já na instalação em aplicativos nativos.

Conclusão…

O que captou o interesse das pessoas e quais as motivações delas em buscar uma abordagem de desenvolvimento híbrido? Talvez seja entregar mais rápido um produto mais barato. Em todo caso, isso se mostra uma tarefa difícil falando principalmente de híbridos-web, e levando em consideração as ressalvas que explicamos aqui. No fim, tentamos resumir assim:

Ou seja, se os recursos disponíveis são limitados e o objetivo é testar um projeto com pouco prazo, os híbridos (no geral) são um caminho. Entretanto, ao mesmo tempo existem diversas outras maneiras de se fazer isso. Você pode fazer um POC (proof of concept), começar com um MVP (minumum viable product) ou testar um protótipo de alta fidelidade. No fim, não importa como, ter linguagem nativa na aplicação definitiva é fundamental. Híbrida ou não.

Final thoughts

Muitos players conhecidos têm histórias interessantes ao fugir do nativo puro e do híbrido-web. Por exemplo, Facebook e Instagram levaram até o Netflix a migrar para React-Native. Já na Taqtile, estamos pilotando alguns projetos em Silver e React, e aos poucos, vemos o leque de possibilidades se abrir à medida que o mercado procura opções.

Mas escolher uma delas significa fazer uma aposta, principalmente quando essas tecnologias se tornam open-source. Significa ser suscetível à vontade de quem as incentiva. Seja o Facebook por trás de React-Native, Microsoft por trás de Xamarin, Basecamp por trás de Turbolinks, Apple por trás de Swift, ou Google por trás de algumas outras iniciativas. Ao fazer parte de uma comunidade e ajudá-la a evoluir, você escolhe um caminho e se faz uma aposta na sua continuidade. Mas tudo isso é assunto para outro dia.

À medida que a divisão entre mobile web e mobile apps se torna mais turva, podemos pensar em novas formas de chegar onde queremos. Por isso, quando nos deparamos com um projeto, já apontamos na direção de um produto final de qualidade.

Mas se nada do que tivermos a mão atenda, procuramos levantar algumas hipóteses e encontrar outras soluções que se encaixam melhor na realidade do cliente. Foi nesse contexto que construímos uma arquitetura para Silver e estudamos Progressive Web Apps como outra alternativa. Mas isso também é outro assunto.

Por hoje, paramos por aqui.
Obrigado pela leitura e até a próxima!

Vá mais fundo conhecendo sobre nosso processo de design e desenvolvimento e fique à vontade para compartilhar suas ideias, nos dizendo sua experiência com apps nativos e híbridos.

Referências

Creditos

Capa — Dirck Halstead/Getty Images
Ícones — Denis Sazhing
Fontes — Chocolate Covered Raindrops