Há um ticket na sua lista de pendências agora que diz algo como “explorar personalização em dispositivo”. Prioridade média. Ninguém chamou isso de risco arquitetônico. É um.

Há três anos, a maioria das organizações de engenharia fez uma escolha inteligente: escolher React Native ou Flutter, parar de re-litigar nativo vs. cross-platform toda vez que um novo projeto surgisse, enviar ambos os aplicativos para as lojas de aplicativos a partir de uma única base de código. Decisão boa. Ainda é, para a maioria do que as equipes móveis construem.

Apenas não foi projetado para sobreviver ao que aconteceu na WWDC este ano.

A Apple lançou uma nova arquitetura de IA em toda a iOS 27, processamento em dispositivo, Private Cloud Compute, Siri refeita em ambos. A Google respondeu com Gemini Nano 2.0 no Android. Mesma aposta das duas empresas: as funcionalidades de IA que as pessoas realmente confiarão são aquelas que nunca deixam o telefone.

Ninguém colocou o efeito colateral na apresentação. As APIs de IA em dispositivo são APIs de plataforma primeiro. Elas pousam em Swift e Kotlin, às vezes apenas lá. Os quadros de trabalho cross-platform chegam eventualmente, através de uma camada de ponte, e “eventualmente” sempre foi onde as promessas do cross-platform silenciosamente pararam de ser verdadeiras.

Aqui está a versão honesta da divisão:

Essa linha inferior é o problema real. A lacuna não está no que já foi construído. Está no que o produto está prestes a pedir.

Ninguém quer admitir por que a norma existe

Aqui está a parte que não é dita em voz alta nas reuniões de planejamento: “padronizamos Flutter” geralmente não era uma decisão futurista. Era uma maneira de parar uma discussão. A engenharia ficou cansada de reabrir nativo vs cross-platform a cada trimestre, então a liderança fechou isso. Um quadro de trabalho, um pipeline de contratação, um CI/CD setup. Tudo bem. Isso é boa gestão, não um erro.

O erro acontece depois disso. A norma se torna uma regra que ninguém é permitido quebrar sem lutar, e “o roadmap precisa de IA em dispositivo” não soa urgente o suficiente para escolher essa luta. Parece como um escopo desnecessário. Então a funcionalidade é dimensionada ao redor do que o quadro de trabalho pode fazer, não ao que o produto realmente precisa, e quando isso obviamente está errado, já foi enviado dessa maneira.

Vimos ambos os lados disso no trabalho real. No Ample, um aplicativo de serviços residenciais que construímos em ambas as plataformas, a plataforma cruzada foi a escolha certa para todo o produto, sem exceções necessárias. Em outros projetos, quando uma road map tocou em recursos intensivos em câmera ou sensores, essa conversa aconteceu na etapa de arquitetura, não seis sprints depois. Essa é realmente a única diferença entre equipes que são pegas de surpresa por isso e as que não são: se a exceção foi planejada antes de ser necessária. Caminhamos através dessa decisão item por item, incluindo onde traçamos a linha em Ample, no nosso guia de desenvolvimento de aplicativos móveis.

Um padrão sem cláusula de exceção não é um padrão

Toda organização madura tem um processo documentado de exceção para seu provedor de nuvem ou fornecedor de autenticação. Quase ninguém tem um para o quadro móvel, porque essa decisão foi feita uma vez, cedo e arquivada como "resolvido".

Vale a pena perguntar claramente neste trimestre: algo no próximo ano toca inferência em dispositivo ou IA de nível profundo do sistema operacional, e se sim, alguém realmente confirmou que a camada de ponte suporta isso, não "provavelmente há um pacote para isso"? A maioria das equipes não pode responder com sinceridade agora. Essa é a verdadeira descoberta aqui. Não que a plataforma cruzada seja ruim. Que quase ninguém verificou.

A Apple e a Google não quebraram nada. Elas construíram o que os usuários pediram, recursos que funcionam sem enviar dados pessoais fora do dispositivo. O risco sempre esteve quietamente dentro de cada organização que parou de perguntar se o padrão ainda cabia, porque por um tempo ele deixou de precisar ser perguntado.

Precisa ser perguntado novamente. Não a cada trimestre em pânico, apenas em um cronograma, antes que a data limite já esteja estabelecida.

O verdadeiro sinal de maturidade da plataforma cruzada em 2026 não é qual quadro uma equipe escolheu. É se eles podem dizer, agora mesmo, exatamente onde esse quadro para de funcionar.

Para o quadro completo que usamos para fazer decisões de plataforma e pilha em builds reais de clientes, veja a abordagem da Hooman Studio para o processo de desenvolvimento de aplicativos móveis.