Aplicativos Nativos vs Híbridos

Introdução
Como uma desenvolvedora que atualmente usa React-native pra tudo, e que já trabalhou com Android, percebo algumas diferenças durante o desenvolvimento dos mesmos. Não sou nenhuma expert em Mobile, porém me interesso muito sobre o assunto e pretendo trazer aqui algumas informações úteis sobre as diferenças de cada tecnologia (principalmente Android e React-native pois são as únicas com quais eu já trabalhei).
Como qualquer técnico ou engenheiro da área de software (não exclusivamente mobile), sabemos que em toda empresa, projeto ou idéia, devemos pensar com muita cautela em qual tecnologia ideal para utilizarmos em determinado cenário. Assim como o DBA pensa na melhor base de dados para determinado projeto, um arquiteto planeja a melhor arquitetura de um software específico, e nós meros humildes desenvolvedores, seja qual for a modinha do momento, (no momento em que estou escrevendo esse artigo, é Flutter, por exemplo), devemos pensar porquê aquela tecnologia é a ideal para nosso aplicativo.
Hoje, é possível escolher várias formas de escrever seu aplicativo, seja Android, Xamarin, Cordova, React-native. E se parar pra pensar, há 10 anos atrás não tínhamos tantas opções disponíveis para podermos desenvolver nossos aplicativos. E isso é muito legal!
O que são aplicativos nativos?
Aplicativos nativos são aplicações desenvolvidas para uma plataforma específica, onde eles são capazes de executar e explorar todas as funcionalidades do dispositivo, ter uma melhor performance e uma comunicação mais direta com o hardware.
E híbridos?
São aqueles aplicativos cross platform que geram um build para Android e IOS, o projeto é feito em uma linguagem só. Apenas um projeto de desenvolvimento que será transpilado pra cada plataforma.
No meu trabalho!
Lá na squad da qual trabalho atualmente, utilizamos React-native para desenvolver o nosso aplicativo, temos diversas funcionalidades como: abrir a 2ª via de faturas, negociar contas atrasadas, utilizar a Aura (inteligência artificial), acionar o Suporte Técnico para resolver problemas, etc. A tecnologia funciona super bem para o negócio.
Porém, há algumas funcionalidades por baixo dos panos que me faz pensar qual seria a arquitetura ideal para certas funcionalidades do app, como por exemplo, pegar a data de instalação do aplicativo no device, mandar uma hash encriptada para o microsserviço (pensa num trabalho que deu). E se um dia a área de Negócios decidir que precisa autenticar o aplicativo com a digital? E se eu precisar utilizar uma lib que não tem no JS? (ok, irônico). Mas tudo isso é de se pensar na hora de se escolher uma linguagem, um framework, uma lib.
Vantagens e Desvantagens
Por ser um aplicativo desenvolvido para o próprio sistema operacional do smartphone, os nativos tem uma melhor performance, onde conseguimos usar da melhor forma os recursos do hardware, como geolocalização, câmera, push notifications, etc. Isso é um benefício quando se trata de aplicativos complexos que vão utilizar mais memória e recursos do software do smartphone, como por exemplo, jogos ou IA’s. Agora, muitos aplicativos muito conhecidos no mercado como Amazon e Netflix são híbridos. Ou até WebApps.
A principal vantagem de um aplicativo híbrido é ele ser multiplataforma, roda em Android e IOS um código só, isso é um benefício no custo do desenvolvimento, levando em conta que você não precisará pagar por dois times de engenheiros que programe em Objective-C/Swift e outro que programe em Java/Kotlin, (embora eu ache que saber apenas JS não basta pra criar um baita app em React-native).
Todo desenvolvedor Mobile sabe que um aplicativo nativo é muito mais interativo pro usuário. É claro que as tecnologias híbridas estão evoluindo cada vez mais pra captar informações dos devices, porém é muito mais fácil implementar as funcionalidades numa tecnologia nativa como Android (há controvérsias). Eu ainda não tive a oportunidade de trabalhar com IOS, mas imagino que seja da mesma forma.
Agora vamos falar sobre o processo de desenvolvimento !
Na primeira aula de TM (Tecnologia Mobile), meu professor de Android disse a seguinte frase:
“Para desenvolver Android, só precisamos de um computador com 16GB de RAM pra rodar o Android Studio”.
E devo dizer que hoje eu concordo com ele, hehe.
Brinks, além de você ter um bom conhecimento de Java, introduzir-se ao mundo das Activities e do SQLite é um pouco chato sim. Fazer tudo em Java pode ser mais demorado, existem outras tecnologias bem menos burocráticas (sorry Java), hoje, quando falamos em Android, falamos em Kotlin, linguagem da JetBrains, então não tenha receio caso deseja aprender do zero. A Google já presta suporte para Kotlin e já podemos considerá-la a linguagem oficial do Android e tem uma comunidade grande! Caso queiram conhecer melhor:
De fato, desenvolver em Android é muito simples quando já se tem os requisitos principais (conhecimento da linguagem e ferramentas, Android Studio, emulador e vontade). Existem milhares de lib em Android super fáceis de usar no projeto e com o Gradle (gerenciador de automação de compilação e também utilizado pra declarar configuração das dependências do projeto), é muito simples configurar as dependências e buildar.
Experiência pessoal:
Já tive que desenvolver um protótipo de meio de pagamentos usando QR Code, no qual eu teria que apenas digitar o valor do pagamento, gerar um QR Code e também ser possível escanear esse código. O tempo de demorei pra desenvolver essa POC? Pasmem, menos de 4 horas, em Android!
- Criar o projeto, configurar o device, procurar uma Lib, codificação e testes.
Enquanto fazer esse mesmo protótipo em React-native, deu um trabalhinho… Consegui fazer em mais ou menos uma semana, eu tive um problema pra conseguir colocar a lib no projeto e configurar o ambiente.

Configuração
Configurar o React-native no computador é um parto! Principalmente se você tiver um Windows ou Linux, o ideal seria usar um Mac para poder testar as funcionalidades também em IOS. A parte chata é que você vai precisar tanto configurar o ambiente Android quanto o IOS (configurar JDK, variáveis de ambiente, instalar o Xcode, rodar os emuladores), mesmo se você seguir a risca os tutoriais sobre como montar um ambiente React-native, vai dar pau!

Libs
No desenvolvimento híbrido é possível cair em um cenário cuja lib específica não atenda as mesmas funcionalidades pra Android como pra IOS. Como no exemplo da lib do react-native “react-native-device-info” que possui métodos que funcionam pra Android, e que pra IOS ou Windows, nem todos funcionam.
Inclusive, é muito fácil cair em ciladas de libs de JS. Principalmente a galera que veio da web (como eu) que acha que só porquê o app é híbrido em Javascript, é festa ! Não é. Já caí nessa de desenvolver funcionalidades usando libs que estavam publicadas no NPM que funcionavam apenas em modo debug, então foi difícil chegar no entendimento de que aquele código é feito em uma linguagem que as libs irão funcionar, porém sem o debug, aquilo vai virar Java ou Objective-C, ou seja, aquela lib não irá funcionar nativamente, só será suportada no navegador ! Esse foi meu entendimento depois de muito tempo batendo cabeça, se alguém souber melhor sobre como libs JS funcionam depois que são “transpiladas” pra nativo, comenta aqui embaixo ! Conclusão: sempre verifique se a lib é suportada nos devices.
Aliás, existem milhares de libs do próprio React-native que são utilizadas para o desenvolvimento.
Bom, então vamos fazer um comparativo das minhas impressões.
Entendimento
- Eu tive uma curva de aprendizado muito grande ao aprender React-native, passei uma semana pra conseguir rodar o aplicativo no emulador. Já conversei com pessoas que tiveram a mesma experiência que eu, e acredito que de fato, é um mundo totalmente novo. Eu aprendi SPA com Vue.js e fui direto pro React-native sem entender os recursos do React.js antes, então pra mim, foi um pouco mais difícil. Nunca havia usado Redux por exemplo. Ou seja, é uma chuva de aprendizado.
- Ao aprender Android na escola, foi um pouco mais simples, não tivemos infraestrutura pra desenvolver muitas coisas porém o básico tivemos. Rodamos na primeira aula e já aprendi os conceitos de Activity e depuração. Acredito que a facilidade também veio do conhecimento da linguagem Java. Em Kotlin também, apesar da curva de aprendizado da linguagem, super simples de programar !
Depuração
- Confesso que até hoje debugar em React-native é um mistério. Eu utilizo o debugger do navegador, porém, as vezes o debugger do Chrome deixa a desejar, por mais que exista várias extensões, sinto falta de um Launch App no Vscode mais simples.
- Debugar no Android Studio (prefiro IntelliJ) é muito mais simples, é como depurar um código Java na IDE. Adoro!
Testes
- Testes unitários são muito importantes a se considerar no código. Em React-native utilizei a lib Jest pra escrever testes unitários. A princípio é simples de se fazer, desde que tenha conhecimento da arquitetura do React em si (state, props, reducer, etc).
- Em Android eu utilizei a lib AndroidJUnitRunner, que suporta testes unitários e é compatível com JUnit 4, então novamente, quem veio do Java, consegue implementar de forma simples. Existe o UI Automator que é um framework de testes da interface do usuário que deve ser mais utilizado por QA, que você consegue acessar esse programa só com o Android Studio instalado, dentro da pasta “/Android/tools/bin”.
Hot Reloading e produtividade
- O React-native entrega bastante produtividade, depois que você acaba entendendo e criando seu ambiente de desenvolvimento fica mais fácil depurar e desenvolver utilizando o Live Reload e Hot Reloading, é muito rápido porém depende de alguns fatores, tipo máquina ou até tamanho do aplicativo, lembre-se que pra quase tudo você vai precisar de uma lib em React-native podendo deixar a aplicação mais pesada e possivelmente mais lenta. Nas minhas POC’s consigo ser mais produtiva do que em uma empresa que preciso carregar várias requisições, libs, dependências internas, preciso estar em um ambiente correto, preciso rodar Android & IOS, aliás, estou desenvolvendo pra duas plataformas e preciso testar minha funcionalidade nas duas, de preferência antes de comittar.
- O Hot Reloading do Android perde um ponto por ter que configurar no projeto. No entanto, no nativo eu só precisarei rodar e testar uma vez, o time de IOS fará a mesma coisa na plataforma deles. E a produtividade no meu ponto de vista deve ser maior pois o engenheiro de cada plataforma deve ser mais especializado nela enquanto os engenheiros de React ficam malucos e as vezes esquecem de validar algumas coisas a não ser que o negócio especifique os comportamentos esperados de cada plataforma! E isso é um problema, exige muito foco e comunicação entre o time.
E a pergunta que não quer calar: Qual tecnologia usar para o meu app?
Levando em consideração que meu artigo é focado na escala de desenvolvimento, muita gente pergunta no final das apresentações qual tecnologia usar.
E a resposta é: depende do que sua empresa ou você busca ! É só pensar nos seguintes fatores:
- Eu tenho capital pra investir em um aplicativo completo? Ou pretendo ter um custo baixo?
- Consigo pagar dois times de engenheiros especializados na plataforma X e Y?
- Qual é minha deadline? Quanto tempo e recursos terei pra fazer o aplicativo?
- É um MVP? É um protótipo?
- É um jogo? Vou precisar ter muitos recursos de hardware? Terá que ser muito performático?
- É um aplicativo simples, preciso fazer ele rápido pois tenho pouco tempo?
Ao responder essas questões, você chegará em uma conclusão rápida. Ainda assim, sugiro que consulte pessoas da área técnica, caso não seja, para ter certeza de que escolheu a melhor opção!
Com tudo isso, espero ter ajudado a ter deixado mais claro os desafios no desenvolvimento que iremos enfrentar em cada Stack. Sei muito pouco, existem várias por aí no mercado, porém achei interessante compartilhar essa experiência! Valeu. ☺
Meus contatos:
@smariane no Telegram
@amarianesantana no Instagram e Twitter.
