Esta é uma pergunta que assombra os desenvolvedores de aplicativos para dispositivos móveis, em especial celulares, nos últimos anos. Digo nos últimos anos pois até pouco tempo não havia dúvidas sobre a necessidade de aplicativos nativos, eles eram necessários e ponto. Mas hoje há opções muito boas de frameworks de desenvolvimento e outros recursos para “generalizar” o desenvolvimento de aplicativos para dispositivos móveis.
Antes da resposta, vamos dar um passo para trás. Embora este seja um blog de tecnologia, nem todos os leitores estarão familiarizados com todos os conceitos e assuntos que abordamos neste espaço. Vamos então começar do básico: o que é um aplicativo nativo para dispositivo móvel?
Aplicativos nativos
Olhem nos seus bolsos agora, ou sobre a mesa ou ainda em suas bolsas, quase certeza de que vocês encontrarão seus celulares (ou pode ser que alguns de vocês estejam lendo este artigo diretamente nele). Se eu tivesse que chutar, diria ainda que este celular ou é um iPhone rodando alguma versão do iOS, ou um modelo das dezenas de fabricantes que utilizam o sistema operacional para celulares (e outros dispositivos móveis) do Google, o quase onipresente Android.
Não vou entrar aqui na disputa de fãs de um ou de outro. Os dois são excelentes sistemas operacionais, cada um com suas qualidades e pontos fracos. Mas, estes dois são sem dúvida os melhores do mercado (em conjunto) e por isso dominam quase que completamente os celulares espalhados pelo mundo.
Acontece que, do ponto de vista técnico, Android e iOS são bem diferentes. São plataformas distintas. Embora ambas utilizem um kernel compatível com POSIX (o iOS com um mix de XNU/FreeBSD/OpenBSD enquanto o Android utiliza um kernel Linux modificado, e simplificado, com suporte GNU parcial). Isto significa que do ponto de vista prático um programa feito para iOS não funciona no Android e vice-versa.
Ok, mas como desenvolvedores o que nós temos a ver com isso? Bem meus amigos, o problema é que se vocês quiserem atender aos dois públicos vão ter que fazer dois programas. Pior, as linguagens nativas (e, portanto, com melhor suporte ao desenvolvedor) não são as mesmas. Não é que se pode fazer um programa e apenas compilar para um ou outro target, iremos precisar fazer duas vezes. O código, até mesmo das bibliotecas, não pode ser reaproveitado pois o Android prefere Java enquanto o iOS dá preferência para Swift/Objective-C. Se quisermos atender ambos teremos o dobro do trabalho, simples assim.
O caminho da Web
“Legal, tive uma ideia então” pensou o programador mais ligeiro, “vou fazer um site que funciona bem também em dispositivos móveis. Assim eu resolvo três problemas de uma vez: quem tem Android, quem tem iOS e quem esteja em um navegador rodando Windows/Mac/Linux, todos eles conseguem acessar (e usar) um site bem construído e terão uma boa experiência”.
A ideia é boa, aliás é ótima, mas tem suas limitações. É verdade que com alguns frameworks de desenvolvimento web dá para fazer sites que funcionam muito bem no celular (ou outros dispositivos móveis). Isso, com certeza reduz o tempo de desenvolvimento (embora os testes continuem
custosos, afinal só dá para garantir que seu site funcione bem em um MotoX com Android se você testar ele em um MotoX com Android). Mas, dependendo do que precisemos oferecer ao usuário, pode não ser o suficiente.
A pergunta que devemos nos fazer é: por que meu usuário está acessando o sistema de um celular?
Há várias respostas para isto:
- porque ele pode querer acessar a qualquer momento e de qualquer lugar, ou;
- porque é mais cômodo fazer aquela tarefa de um celular (por exemplo se ele estiver fazendo um inventário de estoque e queira registrar as contagens de materiais diretamente no local onde ele está contando, ao invés de tomar nota em papel para só depois transcrever os dados em um sistema, em um PC, aliás não existe nada mais anos 90 que isso), ou ainda;
- porque o celular traz um recurso que facilita ou é condição para trabalho (utilizar a câmera para ler códigos de barras de produtos, o GPS para fazer medidas topológicas, etc.)
Aí eu tenho más notícias: sites não estão prontos para ler dados da câmera (pode-se até fazer upload de fotos, mas se quisermos utilizar recursos mais avançados como realidade aumentada ou escaneamento em tempo real não dá). Quanto aos dados de GPS então, estes são ainda mais inacessíveis para um browser (precisa-se de boa vontade do usuário autorizar e ainda assim não será muito preciso). Fora isto, os celulares atuais têm uma série de outros recursos interessantes (leitores RFID, infravermelho, acesso ao microfone, …) que são inalcançáveis a partir do browser.
Em resumo, fazer um site funcionar bem no celular só atende uma parte pequena das necessidades dos usuários (mobilidade para fazer aquilo que ele já podia fazer na frente do computador) e desperdiça uma série de funcionalidades que os dispositivos móveis têm e que ficam inacessíveis
Não dá para dar um jeitinho?
E se pudéssemos fazer aplicativos para celular do mesmo jeito que fazemos sites (se possível utilizando as mesmas ferramentas como HTML5, CSS e Javascript). Mas, se estes “sites” rodassem em browser especial ou aplicativo especializado que permitissem mais poder às páginas web? Acesso à câmera (direto), ao GPS, ao leitor RFID e outros?
Pois bem meus amigos, isto é o que motivou a criação de frameworks como o React Native e Nativescript. Esses dois são baseados em tecnologias de desenvolvimento Web (HTML5, CSS e Javascript) e os aplicativos feitos desta forma são chamados de híbridos. Isso porque eles juntam uma tecnologia generalista (aplicativos web que rodam em browsers) com funcionalidades acessíveis apenas para aplicativos nativos.
Há também outras opções para manter uma base única de código, mas que seguem um paradigma diferente como Xamarim (da Microsoft com NET) e o Flutter (que utiliza a linguagem de programação Dart). No entanto, eu não vou me aprofundar muito nestas outras tecnologias porque eu não considero que eles gerem aplicativos híbridos. O que elas fazem é gerar aplicativos nativos a partir de um mesmo código fonte e de um conjunto de bibliotecas que tentam abstrair as diferenças entre os sistemas operacionais dos dispositivos móveis.
Em todo caso, a ideia permanece a mesma: que se consiga desenvolver um único aplicativo (um único código-fonte) e estas ferramentas façam a mágica de fazerem este mesmo programa rodar nativamente (alguns utilizam compilação nativa para a plataforma, enquanto outros funcionam com emuladores (alguns com JIT para ter uma performance aceitável).
Embora eu tenha falado em “jeitinho” não entendam mal. Não é que seja uma gambiarra, muito pelo contrário, é um esforço bem grande, planejado e calculado para que isto funcione. Mas, obviamente, tem suas limitações.
Nativo vs Híbrido
Chegamos então ao cerne da questão: vamos de híbrido ou de nativo. A escolha não é simples e no final das contas têm a mesma resposta de quase tudo na vida: depende.
Aplicativos nativos rodam mais rápido e estão em total harmonia com as diretivas de design da plataforma para onde foram feitos. Um usuário de iOS rapidamente reconhece um aplicativo nativo: ele tem o botão de voltar na barra superior, quando há abas elas ficam embaixo, etc. Pode parecer pouco, mas isto influi, e muito, na curva de aprendizado do usuário.
Simplesmente ele já conhece como as coisas funcionam e realmente só precisa aprender aquilo que seu aplicativo faz “a mais”, o básico ele já sabe. Não consigo dizer com certeza se no Android é o mesmo caso (nunca tive um celular Android) mas é lógico pensar que sim.
Do outro lado temos o alicerce da civilização capitalista ocidental: dinheiro.
Simplesmente é mais barato fazer um aplicativo híbrido porque no mundo de hoje não dá para atender só iOS ou só Android e fazer para os dois custa o dobro (ou mais).
Ao mesmo tempo, o aplicativo híbrido será um pouco mais lento (ou muito, dependo do nosso cuidado). E, o principal, mesmo com acesso a recursos nativos de câmera, GPS, etc., simplesmente não é possível extrair todo o poder que o celular poderia te dar usando uma abstração genérica. É como tentar ler um poema japonês traduzido para inglês. Simplesmente ele não carrega toda a beleza e significado que o texto na língua original, ou seja, sempre se perde algo.
Eu seria preguiçoso se terminasse este artigo aqui e eu não vou fazer isso.
Vou então dizer o que eu faço para decidir nesta situação:
- Só precisamos permitir que o usuário acesse seu sistema de qualquer lugar (leia-se dispositivo): simples, utilizamos um framework de desenvolvimento web responsiva e sejamos felizes. Assim o que precisamos fazer é apenas um “site” que funciona bem também em celulares (ou tabletes). Simples, econômico e, principalmente, resolve o problema.
- Precisamos que o usuário acesse o nosso sistema de seu dispositivo móvel e queremos dar algumas capacidades a mais ele como utilizar a localização do GPS, por exemplo, ou um acesso simples à câmera: um aplicativo híbrido vai atender muito bem. Vamos conseguir dar mais poder ao usuário e ao mesmo tempo que não precisaremos manter várias versões diferentes do aplicativo. Não tão simples, não tão barato, mas também resolve o problema.
- Por fim, precisamos fazer um aplicativo móvel de uso intensivo com coleta de dados, realidade aumentada, escaneamento em tempo real da câmera, uso do microfone avançado, localização em tempo real do GPS, etc.: A resposta não pode ser outra, precisamos de um aplicativo nativo. Aliás, precisamos de vários: iOS e Android são o mínimo, mas pode ser que precise também para Windows Phone (embora, particularmente, eu ache mais provável encontrar um panda selvagem na rua do que alguém com um celular rodando Windows). Mesmo no mundo do Android, pode ser que precisemos de aplicativos especializados para fabricantes diferentes (Samsung, Motorola, Asus, etc.) ou mesmo modelos diferentes de um mesmo fabricante. Vamos ter que nos preparar para enfiar a mão no bolso, isso vai ser bem mais caro. Mas, ao mesmo tempo são aplicativos que trazem muito valor de uso e extraem do dispositivo tudo que ele pode oferecer.
Espero ter ajudado vocês a entenderem um pouco mais sobre este tema e
ajudado a iluminar o caminho para as decisões que vocês precisem tomar.