Sempre que me perguntam sobre o uso do Flutter, React Native, Xamarin e Native Script para o desenvolvimento de aplicativos, eu sempre respondo mostrando como elas funcionam.
O meu desafio aqui é conseguir explicar como todo o universo mobile funciona e também cada uma dessas ferramentas em um pequeno post sem entrar em termos técnicos (me ajuda Jesus).
A principal coisa que você precisa entender sobre essas ferramentas é que elas não sobrevivem sozinhas e que são DEPENDENTES das plataformas nativas da Apple e do Google. Na prática, o que você tem no final é um pacote que vai embarcado numa aplicação padrão gerada na hora que você cria o projeto com essas ferramentas.
Vou usar o Flutter como exemplo, pois já fiz alguns cursos e tenho dois aplicativos reais feitos com ele (Avinu e iMinerator).
O Flutter nada mais é que um framework open source do Google que cria um projeto para Android e iOS onde ao compilar seu código Dart ele o embarca no projeto nativo criado para o Android Studio e Xcode, como se fosse um projeto normal. O Flutter usa um loop infinito onde ele fica desenhando os componentes visuais imitando o visual e o comportamento da plataforma em que está rodando, então dependendo da plataforma ele vai assumir uma aparência ou outra.
Se você abrir o projeto criado pelo Flutter do Android Studio ou Xcode, vai ver que ele criou um projeto de uma tela única, onde dentro dessa tela ele fica desenhando todos os componentes conforme você desenvolveu em Dart. Diferente de outras plataformas, o Flutter não usa os componentes de cada plataforma, mas os imita, desenhando eles manualmente com o framework de desenho que o Google já utiliza, chamado Skia.
Porém, o código Dart (no caso do Flutter) ou Javascript (no caso do React Native) não tem acesso a NADA do que a Apple desenvolveu para o iOS ou do que o Google desenvolveu para o Android. A única forma que existe é convertendo os dados de uma linguagem para a outra (Dart para Kotlin ou Javascript para Swift etc).
Eu sempre uso o exemplo da API de bateria do smartphone, pois é mais simples de explicar. O código Dart não consegue acessar essa informação do iOS ou do Android diretamente, ela precisa de um código por trás que faça isso em Kotlin ou Swift e devolva ao Dart em tipos de dados que ele conheça e que sejam montados e organizados no Dart. Isso é assim em qualquer plataforma ou linguagem, e é assim que o Java/Kotlin se comunica com as funções nativas através da JNI ou como o Swift fala com os frameworks da Apple em Objective-C/C++.
Já dá para imaginar que teremos que ter plugin para todas essas ferramentas e recursos que a Apple e o Google desenvolvem fazendo o caminho de ida e volta, convertendo e trocando dados do Kotlin/Swift para Dart e vise-versa, o que é muito custoso e a pessoa que desenvolve o plugin precisa ficar atualizando e mantendo, ou seja, sempre você vai depender de alguém manter todo esse maquinário funcionando ou ficar fazendo fork com os seus ajustes.
Além disso, você não consegue usar nada da IDE nativa (Xcode ou Android Studio) nesses framewors e ferramentas. Você consegue usar o Xcode para ver suas telas com o SwiftUI ou o Android Studio para ver as telas com Jetpack Compose, pois é tudo nativo da empresa que desenvolveu, fora isso nada funcionará com o Flutter, que até possui plugins para as IDEs para facilitar o desenvolvimento, mas não consegue usar os recursos totalmente pois são universos diferentes.
Outra questão é o poder e o direcionamento dessas ferramentas que atendem ao interesse da empresa que a desenvolve, sendo o Google no caso do Flutter e o Facebook/Meta no caso do React Native. Então, o dia que essas empresas abandonarem o projeto, o que acontecerá com o seu produto? Terá que ser refeito provavelmente.
Eu conheço ambas as plataformas (iOS e Android) e quando fiz meus aplicativos com Flutter, tive que bater cabeça mexendo nos projetos do Android Studio e Xcode, pois vários plugins (ex: Firebase, Push, InApp e outros que usam .so nativas) precisavam de ajustes nos projetos do Android Studio e Xcode para funcionarem, uma vez que esses frameworks não fazem nada além de usar o que já existe. Agora imagina um desenvolvedor Flutter que só entende de Dart e não conhece as plataformas em si. Não funciona para mim na minha opinião.
Torno a dizer que essas ferramentas são úteis e muito boas, pois eu mesmo as utilizo, mas eu entendendo o seu papel no mercado. Eu mesmo já vi e entrevistei pessoas que trabalhavam com essas ferramentas e depois migraram para o desenvolvimento nativo e os motivos são sempre os mesmos, muitos problemas com as ferramentas, o produto deixou de ser um protótipo ou limitação das próprias pessoas.
A ideia do Flutter está na home do site da ferramenta (flutter.dev), ser um framework para "single codebase".
A melhor abordagem para "single codebase" para mim é a forma como tenho feito em alguns projetos, inclusive na Ubook, que é usar a linguagem C++ para esta parte compartilhável do código, pois já é suportada por todas as plataformas nativamente, sem ferramentas extras e sem esforço.
Fazer assim me possibilita usar todo o potencial nativo de tudo o que a Apple e o Google desenvolvem (ferramentas, IDE, componentes, recursos da plataforma etc) durante o ano e o que não é específico ou visual eu faço em C++ e fica disponível para todas as plataformas sem muito trabalho (regras de negócio, chamadas HTTP, banco de dados, parser de json etc).
O engraçado é que quando comecei no universo mobile, eu comprei um iPhone3GS e comecei a criar aplicações com Adobe AIR para ele, exatamente como essas novas ferramentas funcionam, ainda que utilizando as abordagens da época para empacotar a aplicação.
Até que essa abordagem foi descontinuada e desmotivada pelo próprio Steve Jobs, até a tecnologia cair em desuso. Pois a ideia da Apple é justamente fazer os desenvolvedores entenderem que voc6e precisa usar aquilo que a Apple te fornece.
Portanto, quero finalizar este "pequeno post" compartilhando esse artigo de 2011 do Steve Jobs falando sobre não suportar mais o Flash em seus aparelhos e considerando o uso do HTML5 como um substituto, pois é nisso que eles investiam.
Destaco portanto este trecho traduzido do artigo que dispensa explicações:
Nossa motivação é simples - queremos fornecer a plataforma mais avançada e inovadora para nossos desenvolvedores, e queremos que eles se apoiem diretamente nessa plataforma e criem os melhores aplicativos que o mundo já viu. Queremos aprimorar continuamente a plataforma para que os desenvolvedores possam criar aplicativos ainda mais incríveis, poderosos, divertidos e úteis.