Desenvolvimento Mobile Híbrido

Sabes aquela conversa clássica quando alguém aparece do nada e diz «tive uma ideia para uma aplicação»? Pois é, para além de tentarmos fugir desse problemão que muitas vezes acaba por ser ideias um bocado não ortodoxas, também temos de pensar que tecnologias usar no desenvolvimento móvel. E hoje o mundo híbrido está muito mais interessante do que costumava ser.

O panorama atual: React Native, Flutter e Expo na linha da frente

Quando olhamos para o mercado atual, três nomes dominam completamente o cenário do desenvolvimento híbrido. O React Native continua muito forte, especialmente em mercados como Portugal, onde a maioria dos projetos híbridos que se vê por aí ainda aposta nesta tecnologia. E não é por acaso - se tens uma equipa que já domina JavaScript, faz todo o sentido aproveitar esse conhecimento.

O Flutter também está a ganhar muito terreno, principalmente entre developers que vêm de backgrounds mais variados. Para quem tem experiência em C#, Kotlin ou Java, a linguagem Dart acaba por ter uma curva de aprendizagem mais suave. E a verdade é que se vê cada vez mais vagas para Flutter, incluindo para júniores, o que era uma novidade até há pouco tempo.

Mas uma das grandes surpresas tem sido o Expo. Lembras-te quando toda a gente dizia que o Expo ia morrer lá por 2019? Pois bem, não só não morreu como a própria documentação oficial do React Native agora recomenda começar projetos novos com Expo. É como se fosse uma camada que tira muito da complexidade do React Native tradicional.

A revolução da performance: Bridgeless e Impeller

Uma das coisas que mais me impressiona é como a questão da performance, que era o calcanhar de Aquiles do desenvolvimento híbrido, está muito mais resolvida. Lembras-te dos tempos do PhoneGap e Cordova? Era uma diferença brutal entre híbrido e nativo. Hoje em dia, essa diferença está muito mais pequena.

No React Native, a grande mudança foi a nova arquitetura sem bridge. Antes, sempre que precisavas comunicar com algo nativo, tinha de passar por uma ponte que fazia a tradução de uma coisa para outra, e isso era síncrono. Agora, o código JavaScript vai lá e fala diretamente com o nativo. A diferença de performance já não é assim tão grande comparada com o nativo.

Do lado do Flutter, tiveram uma evolução interessante com o motor de renderização. Começaram com o Skia, depois mudaram para o Impeller para conseguir animações mais fluidas. O Flutter consegue entregar 60 frames por segundo no máximo, o que traz animações muito mais próximas da experiência nativa.

O desafio da fragmentação de dispositivos

Agora, não vamos fingir que é tudo um mar de rosas. Uma das coisas que mais afasta malta do mundo móvel é a fragmentação de dispositivos. Se pegarmos num iPhone, é um sistema operacional só, tudo bem, mas temos vários iPhones, cada um com o seu desempenho. No Android, a situação amplia-se muito mais - não só temos muitas versões diferentes do Android como também muitos sabores de sistemas personalizados pelas fabricantes.

Já tive experiências bem complicadas com isso. Uma vez tive um bug num determinado cliente que usava um LG não sei das quantas, e o teclado não funcionava da mesma maneira que nos outros dispositivos. Para fazer debug, deu um bocado de trabalho porque não há emulador específico para LG.

A Xiaomi, por exemplo, passou muito tempo com um bug em que quando tiravas uma screenshot, a tela escurecia porque a gravação da tela acontecia uns microssegundos depois, quando a animação estava a escurecer. Então as screenshots saíam sempre um pouco mais escuras.

Felizmente, hoje temos ferramentas como o BrowserStack, que é pago e online. Podes carregar o teu APK ou IPA e ele dá-te uma gama de dispositivos reais que consegues testar online. Ajuda bastante quando trabalhas em projetos que são usados tanto em tablets como em dispositivos variados.

Design Systems: iOS vs Android

Uma coisa interessante é como a Apple tem aquela obsessão histórica com consistência. Tudo tem de ter «cara de Apple». E vês uma evolução nos design systems dos dois sistemas operacionais que chegou a um nível de maturidade onde, de maneira geral, as aplicações Android que rodas têm cara de Android, e as aplicações iOS têm cara de iOS.

A diferença está na abordagem. O React Native compila os componentes React em componentes nativos de facto. Ou seja, se está a puxar o componente nativo, quando há um update do iOS ou Android, continua a puxar do nativo. Ganhas esse «look and feel» mais próximo do sistema operacional.

Já o Flutter tem uma premissa diferente porque trabalha com Canvas - desenha os componentes na tela em vez de puxar o componente nativo. Quando sai um update do sistema operacional, tens de ficar atento à documentação do Flutter para saber quando vai estar disponível a nova versão do Material Design para Android e do Cupertino para iOS.

São premissas diferentes. Se queres estar sempre na última versão do design do sistema operacional, o React Native não sofre disso. Mas se queres criar uma identidade própria da empresa, menos do sistema operacional, o Flutter pode ajudar-te bastante nessa direção.

O Expo: De patinho feio a recomendação oficial

Uma das coisas mais giras de acompanhar é a evolução do Expo. Houve uma altura em que, se querias fazer algo mais complexo, tinhas de fazer «eject» do Expo porque ele não dava conta. Agora já não é assim. Provavelmente vais conseguir mantê-lo por muito tempo sem precisar de ejetar.

O Expo abstraiu muito da complexidade de coisas muito úteis. Antes, se querias colocar uma fonte no React Native, tinhas de fazer vários passos para instalar uma simples fonte, que é uma coisa que em todo o projeto vais ter. O Expo abstrai isso de uma forma linda. Hoje tem muitas bibliotecas prontas para usar Firebase, Stripe, autenticação com Apple e Google, câmeras, giroscópio, Bluetooth...

E uma coisa que muita gente não sabe: a própria documentação do React Native agora diz que se queres iniciar um projeto, deves começar com Expo. Parece que querem mesmo substituir o CLI tradicional.

Mercado de trabalho: Diferentes realidades

Quando olhamos para o mercado de trabalho, vemos realidades bem diferentes dependendo da região. Em Portugal, por exemplo, há uma proximidade muito maior com o React Native. Veem-se bastantes vagas de React Native, e para a malta que vem da web, faz sentido - já sabem JavaScript.

Já no Brasil, por exemplo, há um crescimento interessante do Flutter. A galera que tem background em backend, que vem de C#, Java ou Kotlin, acha a curva de aprendizagem do Dart mais acessível.

Uma coisa interessante é que se veem cada vez mais vagas para Flutter júnior, o que era uma novidade. Antigamente, as empresas queriam sempre alguém com experiência, mas agora já há espaço para quem está a começar.

Lojas alternativas: Uma nova realidade

Uma coisa que está a mexer com o ecossistema são as lojas de aplicações não exclusivas. No iOS, isso já é uma realidade na Europa por causa do Digital Markets Act. No Android sempre existiram várias lojas, mas agora no iOS também começamos a ver alternativas.

Para quem desenvolve e submete para as lojas, em termos de código não muda nada porque no final vais gerar um pacote (IPA, APK) e o sistema operacional sabe lidar com isso. Mas onde pode haver implicações é no ciclo de desenvolvimento e distribuição.

A Apple sempre foi mais restritiva - aquela procissão toda para submeter uma app, vai e volta, é rejeitada, volta a ser submetida... Mas isso também garante que alguém está a olhar para ter certeza de que o que vai ser publicado não tem nada malicioso.

O ecossistema Dart: Mais que apenas Flutter

Uma coisa interessante é ver como o ecossistema do Dart está a crescer para além do Flutter. Há iniciativas como o Shelf, que é uma biblioteca para fazer web services, e o Serverpod, que é um backend feito em Dart voltado principalmente para Flutter.

A ideia é simples: se tens uma pessoa especialista em Flutter, porque não fazer backend também em Dart? É uma forma de reutilizar conhecimento. Da mesma forma que alguém que sabe JavaScript pode não querer aprender Dart só para usar no Flutter, quem já está no ecossistema Flutter pode preferir não ter de aprender uma linguagem nova para o backend.

Capacitor: O sucessor do Cordova

Outra mudança interessante é a transição do Cordova para o Capacitor. O Ionic, que antigamente usava o Cordova por debaixo dos panos, agora usa o Capacitor por padrão. A premissa do Capacitor é ser um «Cordova melhorado» - uma versão diferente que assume as responsabilidades de comunicação com o nativo, mas de forma mais eficiente.

Xamarin RIP, MAUI Hello

E já que estamos a falar de frameworks que morreram, não podemos esquecer do Xamarin. Alguns ficaram muito felizes e fizeram aquele velório viking, mas agora a Microsoft veio com o MAUI (Multi-platform App UI) para o substituir.

O MAUI é uma evolução natural do Xamarin. A principal mudança é na arquitetura - em vez de teres um projeto separado para cada plataforma, agora é um projeto só onde cada pasta tem o seu target específico. Debaixo do capô mudou muita coisa, e agora usa o .NET moderno para executar.

Animações: A obsessão do mobile

Uma coisa que qualquer pessoa que trabalha com mobile percebe rapidamente é a obsessão que este mundo tem com animações e transições. Se não tiveres animações fluidas, o utilizador vai sentir que a aplicação está menos responsive ou que está com problemas.

Tanto o React Native como o Flutter fizeram investimentos enormes nesta área. O React Native implementou engines de jogos para fazer animações mais fluidas, e o Flutter tem aquela perspectiva dos 60 frames por segundo para trazer animações mais condizentes com o uso nativo.

Linx: A inovação chinesa

Uma novidade interessante vem da China com o Linx, desenvolvido pela ByteDance (a empresa por trás do TikTok). Veio como uma «revolução» no universo do React Native, focado em converter developers da web para mobile e otimizado para o «instant first frame», ou seja, no momento em que clicas na aplicação, ela deve ser instantânea.

Considerações para escolha de framework

Quando se trata de escolher um framework, tudo depende do contexto. Se tens uma equipa que já sabe JavaScript, para que raio vais aprender Dart para gerar uma app? Normalmente, quando isso acontece, a app não é o produto principal - é para atender uma demanda específica do mercado.

Mas se estás a começar uma startup ou uma tecnologia nova, e alguém da equipa já conhece Flutter, pode ser uma escolha tão boa quanto qualquer outra. Tem os seus trade-offs, mas também tem as suas vantagens.

Dicas para diferentes perfis

Para quem ainda não entrou no mercado, o conselho é focar muito na base: lógica de programação, HTML/CSS (mesmo que não vás focar em web, vai servir-te muito), e a linguagem que escolheres - seja JavaScript, Dart, ou outra.

Para quem já desenvolve mas não tem experiência mobile, o caminho é pegar na linguagem que já dominas e ver se tem alguma opção para mobile. Se és developer C# ou Java, olha para o Flutter. Se vens da web com JavaScript, React Native faz sentido.

E para quem já está num ponto mais avançado da carreira? Só dizer «depende» e falar de trade-offs. É essa a realidade - não há uma solução perfeita para todos os casos.

O futuro do desenvolvimento híbrido

O desenvolvimento híbrido chegou a um ponto de maturidade impressionante. A diferença de performance com o nativo está cada vez menor, as ferramentas estão mais maduras, e o ecossistema está mais rico.

A escolha entre frameworks já não é tanto sobre qual é tecnicamente superior, mas sim sobre qual se adequa melhor ao contexto da equipa, do projeto e dos objetivos. E isso é uma coisa boa - significa que temos opções sólidas para praticamente qualquer cenário.

No final das contas, como diria qualquer developer experiente: depende. Mas pelo menos agora temos dependências de qualidade para escolher.