Uma análise técnica e estratégica sobre o próximo ciclo do mobile, o peso da IA no sistema operacional e o futuro de Swift, Kotlin, Flutter, React Native e Kotlin Multiplatform
Curated resources to complement your reading

Mobile Engineer
Engenheiro mobile especializado em experiências nativas de alta performance. Conecta design técnico com impacto real no dia a dia dos usuários. Também mentoro desenvolvedores e criadores em programas ao vivo, podcasts e iniciativas de comunidade focadas em tecnologia inclusiva.
47-point checklist to catch bugs, security risks, and performance issues before launch.
Continue exploring similar topics

Andrej Karpathy propõe um padrão onde LLMs constroem e mantêm um wiki persistente — em vez de redescobrir conhecimento do zero a cada consulta. Uma mudança fundamental na forma como usamos IA para gerenciar informação.

Layoffs, rumores de substituição total e hype sobre IA estão corroendo a clareza de muitos desenvolvedores. Este guia separa rumor de dado, mostra o que o mercado realmente sinaliza e propõe um protocolo prático para gerir ansiedade, carreira e aprendizado em 2026.

Toda vez que você abre uma sessão no Claude Code, ele carrega automaticamente os arquivos de contexto do projeto: `CLAUDE.md`, `AGENTS.md`, hooks, skills. O que pouca gente percebe é que **esses arquivos consomem tokens antes mesmo de você digitar a primeira mensagem**.
Production-tested templates trusted by developers. Save weeks of setup on your next project.
Modular packages for founders and engineering leads. Every engagement includes diagnosis, documentation, and direct access.
2 advisory slots for Q2

Durante anos, boa parte do mercado mobile operou com uma convicção quase automática: se der para compartilhar mais código entre iOS e Android, o futuro será melhor.
Essa convicção não nasceu do nada. Ela vinha de um problema real. Manter dois times, duas bases de código e duas superfícies de produto sempre foi caro. Frameworks multiplataforma prometeram, com razão, reduzir esse custo. Em muitos casos, entregaram exatamente isso.
Só que a próxima fase do mobile não está sendo definida apenas por interface, navegação, lista, formulário e animação. Ela está sendo definida por outra pergunta: em que camada do produto a IA realmente acontece?
Se a resposta for "na borda do sistema operacional, perto de câmera, voz, contexto, privacidade, inferência local, automações e superfícies do sistema", então o debate muda. Bastante.
Essa é a tese que vou validar neste artigo:
nos próximos anos, Swift para iOS e Kotlin para Android podem ganhar espaço estratégico porque a IA está aproximando valor de produto das camadas mais nativas da plataforma.
Mas existe uma segunda tese, igualmente importante:
a versão simplista dessa ideia está errada. Isso não significa a morte de Flutter, React Native ou Kotlin Multiplatform. Significa uma reprecificação do que vale a pena compartilhar e do que precisa ficar perto do sistema operacional.
Em 11 de abril de 2026, olhando para a documentação oficial de Apple, Google, React Native, Flutter e Kotlin Multiplatform, a leitura mais honesta não é "nativo vence tudo". A leitura mais honesta é bifurcação de mercado.
Algumas empresas vão voltar a valorizar o nativo. Outras vão continuar ganhando muito com multiplataforma. E, no meio do caminho, existe um candidato forte para crescer justamente por causa da IA: Kotlin Multiplatform.
Antes de avançar, vale separar três frases que parecem iguais, mas não são.
A primeira frase é plausível e, na minha leitura, bem sustentada pelos sinais atuais.
A segunda já é bem mais fraca. Principalmente no caso de Kotlin Multiplatform, que preserva acesso a APIs nativas e UI nativa. No caso de React Native, a New Architecture mudou bastante o jogo. No caso de Flutter, a história também não é de isolamento total; o framework continua se apoiando em plugins, platform channels e integração direta com APIs nativas.
A terceira, hoje, é ideológica demais para ser levada a sério.
O que faz sentido defender é algo mais específico:
Em outras palavras: o mobile da era da IA não elimina trade-offs; ele torna os trade-offs mais visíveis.
Quase todo debate sobre IA ainda começa no lugar errado.
As pessoas perguntam qual modelo é melhor, qual benchmark subiu, qual provedor está na frente. Isso importa, claro. Mas para produto mobile existe uma pergunta ainda mais decisiva:
quem controla a última milha entre a inteligência e a experiência?
Essa última milha inclui:
É aí que o argumento a favor do nativo fica forte.
Na documentação oficial da Apple, o Foundation Models framework dá aos desenvolvedores acesso direto ao modelo on-device que está no centro do Apple Intelligence. A WWDC25 descreve isso de forma ainda mais explícita: o framework oferece acesso direto ao modelo on-device com uma API conveniente em Swift, disponível em macOS, iPadOS, iOS e visionOS, e a proposta é justamente permitir recursos inteligentes com privacidade e sem depender de conectividade constante.
Ao mesmo tempo, o framework App Intents e a documentação sobre system experiences deixam claro que apps podem se conectar a Spotlight, Siri, Apple Intelligence, visual intelligence, Action button e outros pontos do sistema. Isso é um sinal estratégico. A Apple não está tratando IA como um widget opcional dentro do app. Está tratando IA como parte do tecido do sistema.
No Android, o movimento é semelhante, embora com forma diferente.
O pacote AppFunctions da Jetpack existe para expor funcionalidades do app para assistentes e agentes. A documentação oficial diz que o objetivo é simplificar a exposição da funcionalidade do app para o Assistant. O overview oficial também descreve o fluxo em que um agente descobre metadados e executa funções do aplicativo. Em paralelo, o Google AI Edge SDK e o AICore mostram a aposta do Android em inferência local com Gemini Nano. A própria documentação cita casos de uso reais em produção, como TalkBack, Pixel Voice Recorder e Gboard.
Isso não prova, sozinho, que todo app deveria virar nativo amanhã.
Mas prova algo importante: a plataforma está empurrando valor para áreas em que proximidade com o sistema operacional pesa mais do que antes.
Durante a era do app tradicional, boa parte da diferenciação vinha de negócio, design, distribuição e velocidade de feature delivery. Na era da IA, parte crescente da diferenciação começa a depender também de:
Isso muda quatro coisas.
Durante muito tempo, "adicionar IA" significava chamar uma API externa e renderizar resposta em uma tela.
Esse tipo de integração continua existindo. E para vários produtos isso ainda será suficiente. Mas quando IA começa a entrar em:
ela deixa de ser uma feature isolada e passa a influenciar a arquitetura do app.
Frameworks nativos tendem a absorver esse tipo de mudança mais perto da fonte.
Quando a plataforma lança uma nova superfície, um novo framework ou uma nova API de IA, quem está mais perto da pilha nativa tende a experimentar primeiro.
Esse detalhe parece pequeno, mas ele pesa em times que competem em produto.
Se a empresa depende de:
então Swift e Kotlin ganham atratividade.
Cloud continua dominante em muitos cenários, mas a IA no dispositivo ganhou um novo patamar de relevância. A Apple constrói seu discurso inteiro sobre privacidade e processamento local. O Android, via AICore e Gemini Nano, também mostra a importância dessa camada.
Quando a experiência exige:
o nativo tende a oferecer menos fricção.
Esse talvez seja o ponto mais subestimado.
A IA que muda produto mobile não vive apenas em uma aba "Ask AI". Ela vive em atalhos, intents, resultados do sistema, captura de câmera, descrição de imagem, busca contextual, snippets, sugestões, automações, recursos de acessibilidade, push inteligente, widgets e flows acionados sem abrir o app.
Quanto mais importante isso for para o produto, maior a chance de o app querer ficar perto do sistema.
Se eu precisasse defender a tese em poucas linhas para um CTO, eu resumiria assim:
a IA está tornando o sistema operacional mais produtizado e mais opinativo; times que operam mais perto dele ganham velocidade estratégica.
Vamos aos sinais concretos.
A Apple hoje oferece três sinais muito fortes.
O primeiro é o Foundation Models framework, posicionado oficialmente como acesso direto ao modelo on-device no centro do Apple Intelligence.
O segundo é o App Intents, que liga o app a experiências como Siri, Shortcuts, Spotlight, Apple Intelligence, visual intelligence e Action button.
O terceiro é a linguagem do próprio ecossistema Apple: privacidade, on-device, system experiences e integração profundamente alinhada ao design da plataforma.
Esse conjunto favorece quem está escrevendo Swift, modelando AppEntity, trabalhando com AppIntent, Transferable, IndexedEntity, snippets e fluxos do ecossistema Apple sem depender de uma abstração intermediária amadurecer primeiro.
No Android, o AppFunctions Jetpack library mostra a plataforma caminhando para um modelo em que agentes e assistentes conseguem descobrir e executar funcionalidades do app.
Além disso, a documentação do Google AI Edge SDK mostra a aposta em IA local com Gemini Nano por meio de AICore, com benefícios explícitos como distribuição do modelo pelo sistema e inferência acelerada pelo hardware do dispositivo.
Mais importante: a documentação traz exemplos reais em produção. TalkBack, Pixel Voice Recorder e Gboard já aparecem como casos de uso de Gemini Nano e AICore.
Isso importa porque sai do terreno conceitual. Não estamos mais falando só de promessas de roadmap. Estamos falando de experiências concretas já acontecendo dentro do ecossistema Android.
Se você está construindo um produto mobile em que IA é core, não lateral, você provavelmente vai fazer mais perguntas como estas:
Essas perguntas normalmente puxam a stack em direção ao nativo.
Se o artigo terminasse aqui, ele estaria incompleto.
Porque a hipótese de um "retorno do nativo" só é intelectualmente defensável se você também olhar para a evolução das ferramentas multiplataforma.
E essa evolução é real.
A New Architecture do React Native é uma resposta direta ao tipo de crítica que por anos foi feita ao framework.
Na documentação e no blog oficial, a equipe do React Native explica que a New Architecture remove dependência do bridge, cria comunicação direta entre JavaScript e código nativo via JSI, permite acesso síncrono ao runtime nativo, melhora layout síncrono, lazy loading e destrava recursos mais próximos do comportamento de apps nativos de alta qualidade.
Mais importante: a equipe oficial diz que essa arquitetura já está pronta para produção e usada em escala dentro da Meta. O post também cita uso em produtos da própria Meta e histórias de produção de parceiros. Em 8 de outubro de 2025, o React Native 0.82 foi lançado como a primeira versão que roda inteiramente na New Architecture.
Isso enfraquece a versão preguiçosa da tese anti-RN.
React Native não está ignorando a pressão da camada nativa. Está se reorganizando para chegar mais perto dela.
No caso do Flutter, a história também não é de isolamento.
A documentação oficial continua tratando platform channels como mecanismo de comunicação entre Dart e código específico de plataforma em Kotlin ou Swift. Há também documentação específica sobre como usar plugins equivalentes a frameworks da Apple e, quando necessário, escrever código específico ou acessar APIs nativas diretamente.
Além disso, o Firebase AI Logic oferece SDKs para Swift, Kotlin e também Dart for Flutter, com suporte a chat, multimodalidade, function calling, structured output, streaming e, em alguns cenários, inferência híbrida e on-device.
Ou seja: o Flutter não fica proibido de entrar na era da IA. Ele entra por uma combinação de:
E não faltam sinais de produção no ecossistema oficial do Flutter. A própria vitrine oficial mostra apps relevantes em produção, incluindo Google Pay, Google Earth, NotebookLM, Tonal, Caribou Coffee, ByteDance e outros. Isso não desaparece porque o sistema operacional ficou mais inteligente.
O ponto mais honesto é este:
Flutter e React Native continuam fortes quando a empresa quer mover rápido, manter paridade e aceitar uma camada extra entre o produto e o sistema operacional.
Se existe um framework que mais enfraquece a versão binária da tese pró-nativo, esse framework é Kotlin Multiplatform.
E vale falar isso com clareza.
A documentação oficial do KMP enfatiza justamente o que se tornou valioso na era da IA:
Na própria página oficial, o KMP é descrito como tecnologia que compartilha lógica, networking, modelos e outras camadas sem obrigar a substituir a interface nativa, a menos que você queira. A documentação também destaca acesso direto às APIs nativas, sem wrappers, e inclusive mostra exemplos expect/actual em que código Kotlin chama APIs de iOS diretamente.
Esse ponto é crucial.
Se a IA puxar a arquitetura para mais proximidade com plataforma, KMP pode se beneficiar porque ele preserva a superfície nativa enquanto reduz duplicação em domínio, dados, validação, autenticação, regras de negócio e integração.
É por isso que eu não compraria a narrativa "Swift e Kotlin vão ganhar espaço, logo KMP perde". Em muitos times, pode acontecer o oposto:
KMP cresce como forma de compartilhar o que realmente deve ser compartilhado;Isso não é teoria abstrata apenas.
O próprio site oficial do Kotlin Multiplatform destaca casos de produção e relatos de empresas como Duolingo, Google Workspace, McDonald's, Forbes e X, além de afirmar que a presença de KMP entre os top 10K apps dobrou ano a ano.
A resposta séria é: parcialmente verdadeira e parcialmente falsa.
Ela é verdadeira quando o produto depende fortemente de:
Ela é falsa quando alguém tenta transformá-la em regra universal.
Porque ainda existe um grupo enorme de produtos em que:
Nesses casos, Flutter e React Native continuam com argumentos muito fortes.
E existe um terceiro caso, talvez o mais estratégico:
quando a empresa quer preservar o poder do nativo, mas não quer duplicar toda a lógica. Aí Kotlin Multiplatform fica especialmente atraente.
Minha expectativa para os próximos anos é esta.
Apps em categorias como produtividade pessoal, saúde, finanças premium, creator tools, comunicação inteligente, bem-estar, educação adaptativa e experiências assistidas por voz ou câmera tendem a voltar a dar mais peso para Swift e Kotlin.
Não por nostalgia técnica. E sim porque a experiência vai depender mais do sistema operacional do que dependia no ciclo anterior.
Muito time ainda discute mobile como se precisasse escolher uma única fé para tudo.
O comportamento mais inteligente deve ser outro:
Se eu tivesse de apostar em um stack que pode ganhar respeito técnico nesse novo ciclo, eu apostaria em Kotlin Multiplatform.
Porque ele conversa bem com as duas forças do momento:
Essa talvez seja a conclusão mais importante para quem trabalha com multiplataforma.
O caminho de sobrevivência não parece ser "abstrair ainda mais o sistema operacional". O caminho parece ser:
É exatamente nessa direção que o React Native já está se movendo com a New Architecture. E é assim que o Flutter historicamente opera quando oferece plugins, platform channels e add-to-app.
Se eu fosse aconselhar uma empresa agora, eu usaria um filtro simples.
| Critério | Swift + Kotlin | Kotlin Multiplatform | React Native | Flutter |
|---|---|---|---|---|
| Proximidade com APIs do sistema | Máxima | Muito alta | Média para alta, dependendo da interop | Média para alta, dependendo de plugin/channel |
| UI com fidelidade de plataforma | Máxima | Máxima se UI for nativa | Boa, mas depende de integração e libraries | Boa, com linguagem visual mais controlada |
| Compartilhamento de lógica | Baixo por padrão | Alto | Alto | Alto |
| Compartilhamento de UI | Baixo | Opcional | Alto | Muito alto |
| Day-zero para novidades do SO | Melhor cenário | Muito bom | Pode depender de módulo ou integração | Pode depender de plugin ou integração |
| Ajuste para IA profundamente integrada ao sistema | Muito forte | Muito forte | Moderado a forte | Moderado a forte |
| Velocidade para times pequenos | Menor | Média | Alta | Alta |
| Melhor fit para apps IA-first premium | Forte | Muito forte | Caso a caso | Caso a caso |
Mais do que trocar framework, muitas empresas vão precisar trocar desenho de time.
O padrão que eu espero ver mais é este:
Em vez de uma discussão infantil de "um stack vence o outro", a empresa madura vai pensar assim:
Essa é a conversa certa.
Antes de escolher stack para os próximos anos, eu faria estas perguntas:
Se você não tiver respostas claras para essas perguntas, ainda não está escolhendo stack. Está escolhendo identidade.
E identidade técnica costuma ser uma forma cara de evitar análise.
Minha posição final é esta.
Sim, existe uma chance real de Swift e Kotlin ganharem espaço com a evolução da IA no mobile.
Mas não porque multiplataforma fracassou. E não porque Flutter e React Native deixaram de ser úteis. O motivo é mais interessante: a IA está puxando valor de produto para uma zona em que sistema operacional, hardware, privacidade, contexto local e experiência nativa voltam a importar mais.
Ao mesmo tempo, a conclusão responsável não é "voltem todos para o nativo".
A conclusão responsável é:
Kotlin Multiplatform pode crescer justamente por preservar UI nativa e APIs nativas;React Native e Flutter continuam fortes onde velocidade, custo e paridade ainda vencem;O próximo ciclo do mobile não vai premiar quem compartilha mais código a qualquer custo.
Vai premiar quem entende qual parte do produto pode ser compartilhada sem afastar a inteligência da plataforma que entrega a experiência.
Essa é a fronteira real.