Nativo é piso, não teto: por que ignorar os componentes do sistema ficou mais caro com a IA

Com a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → gerando telas polidas em segundos, a aparência deixou de ser diferencial. O que sobrou como vantagem real é o que só o sistema operacional entrega: comportamento, acessibilidade↳Acessibilidade11 conteúdosO que é Acessibilidade Web e como tornar seu site mais acessívelDev (Back & Front) · mar 2019Design para veteranos digitais: acessibilidade para nós mesmosProduto & UX · jan 2020Dicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Ver tudo em Produto & UX → e atualização automática.

Por anos, desenhar os próprios controles em vez de usar os do sistema foi uma troca racional: você perdia a atualização automática do visual, mas ganhava uma marca que nenhum concorrente conseguia copiar fácil. O designer Mathieu Poli argumenta, num ensaio publicado na UX Collective em 6 de novembro, que essa conta virou outra. Quando qualquer modelo de IA generativa produz uma tela "bonita" num prompt, a aparência deixou de ser o que separa um produto do outro. Sobra o que uma imagem não mostra: o comportamento do sistema.

O caso que ele usa para provar o ponto é o Liquid Glass, o material visual que a Apple introduziu no iOS↳iOS38 conteúdosO X do Xamarin Forms – O guia das funcionalidades nativas – Parte 01: iOSDev (Back & Front) · abr 2019Desenvolvedores: Apple libera terceiro beta do iOS 12.4Dev (Back & Front) · mai 201910 bibliotecas que todo desenvolvedor iOS deve substituir ainda em 2024Dev (Back & Front) · out 2024Ver tudo em Dev (Back & Front) → 26 em junho de 2025, na WWDC. Na sessão técnica sobre UIKit, a mensagem da empresa para quem usa os componentes nativos foi direta:

Seus apps ganham essa nova aparência assim que você recompila com o novo SDK.

Apple, sessão de UIKit na WWDC 2025Your apps get this new appearance as soon as you recompile with the new SDK.

O preço de desenhar os próprios controles

Quando o iOS 26 foi lançado em 15 de setembro de 2025, barras de abas, sheets, popovers e controles de apps que usavam os frameworks nativos mudaram de uma hora para outra, sem que nenhum designer mexesse em nada. Apps que desenhavam seus próprios controles, como fazem os construídos com Flutter, não ganharam nada disso.

A documentação da própria Flutter apresenta esse desenho próprio como vantagem, não defeito: um app Flutter "tem a mesma aparência e o mesmo comportamento em todas as versões do sistema operacional, mesmo que o SO tenha mudado as implementações dos seus controles".

Tem a mesma aparência e o mesmo comportamento em todas as versões do sistema operacional, mesmo que o SO tenha mudado as implementações dos seus controles.

Documentação oficial da FlutterLooks and feels the same on all versions of the OS, even if the OS changed the implementations of its controls.

Essa estabilidade prometida virou atraso visível. No GitHub, a equipe da Flutter respondeu que não estava desenvolvendo o novo visual da Apple na biblioteca Cupertino, a que imita o iOS, por enquanto. A equipe já moveu essas bibliotecas para fora do núcleo do framework para acelerar o trabalho e diz que o Liquid Glass está em andamento, mas, até 5 de novembro de 2026, a issue segue aberta.

O que a IA copia, e o que ela não vê

Poli testou vários modelos de IA pedindo telas de app para um estudo que pretende publicar. A conclusão: eles imitam o sistema, mas só o que pode ser visto, e só sob certas condições.

Pedir "um app mobile" sem dizer qual sistema gera uma tela genérica. Escrever "iPhone" já traz switches com a forma de switches do iOS. Mas, mesmo um ano depois do lançamento do iOS 26, o iOS que esses modelos desenham por padrão ainda é majoritariamente o antigo: a barra de abas flutuante e as sheets destacadas das bordas, marcas do iOS 26, só aparecem quando o prompt pede explicitamente para seguir "as convenções atuais da plataforma", e mesmo assim raramente. No teste de Poli com o Claude Opus 5.5, pedir um app de creche com esse detalhe extra foi o que fez a barra flutuante aparecer.

Um estudo acadêmico publicado neste ano reforça o achado. Pesquisadores pediram a três ferramentas de IA de design que gerassem 138 telas de app, sem mencionar iOS ou Android. Os modelos aprenderam o que os autores chamam de "sintaxe visual das interfaces móveis contemporâneas": convenções de navegação quase sempre aparecem. Mas esse sucesso, segundo eles, é "guiado por padrão, não por princípio", e há uma lacuna relevante entre usabilidade visual e funcional: ajuda, prevenção de erro e recuperação de erro costumam faltar.

O que uma captura de tela não mostra

Imitar a aparência já é bastante trabalho. Mas o piso de que fala Poli é sobretudo comportamento, não imagem:

• O gesto de voltar, que funciona do mesmo jeito em qualquer app nativo
• A folha de compartilhamento que todo usuário reconhece de cor
• A confirmação que, no iOS 26, cresce a partir do próprio botão que a abriu
• O texto que escala de tamanho quando o usuário muda a configuração de acessibilidade
• O layout que inverte sozinho para árabe ou hebraico

Um controle redesenhado à mão precisa reconstruir tudo isso, e nada garante que vai conseguir. Kate Owens, da consultoria de acessibilidade Deque, documentou um slider customizado em SwiftUI que o VoiceOver simplesmente "pulava por inteiro e nunca focava". Em 1998, os pesquisadores John Satzinger e Lorne Olfman já tinham mostrado, com software de desktop, que comandos que mudam de um aplicativo para outro fazem o usuário realizar mais ações, enquanto uma aparência visual diferente tende a deixá-lo mais preciso. O que importa não é a cara da interface: é a forma como você age dentro dela se manter constante.

Onde o teto fica aberto

O piso não fecha a questão da identidade. Em 2023, o Apple Design Award premiou o Flighty, um app de acompanhamento de voos, na categoria Interação, justamente por se encaixar "perfeitamente na plataforma". No mesmo ano, premiou o Duolingo, com uma interface fortemente estilizada e cheia de personagens, elogiando seu design "de primeira linha". Os dois seguem o piso de componentes nativos; só o Duolingo gasta um orçamento de marca muito maior em cima dele.

O ex-designer de ícones da Apple Louie Mantia resumiu o risco oposto, o de confundir imitação com qualidade, numa crítica ao próprio Liquid Glass publicada em 2025:

Todo mundo pode parecer decente sem realmente ser decente.

Louie Mantia, ex-designer de ícones da AppleEveryone can look decent without actually being decent.

O contra-argumento que merece ser levado a sério

A promessa da Flutter de uma aparência estável entre versões do sistema não é irracional: para times pequenos, ou para produtos que vivem em várias plataformas ao mesmo tempo, recompilar a cada mudança de SDK tem custo real, e nem toda equipe tem braço para isso. Um estudo com quase 12 mil apps Android, de Ivano Malavolta, mostra que apps nativos e híbridos (apps web dentro de uma casca nativa) performam igual em avaliação de usuários. Ou seja: o piso nativo não garante nota melhor na loja de aplicativos.

Mesmo assim, o único experimento controlado que encontrei comparando as duas abordagens frente a frente, de Esteban Angulo e Xavier Ferré, em 2014, mostra diferença perceptível no iPhone especificamente: entre 14 pessoas testando duas versões do mesmo app, 86% escolheram a versão nativa como mais parecida com "um app para o meu telefone", contra 7% para a versão cross-platform. No Android, a diferença foi bem menor (52% a 39%). A lição não é que cross-platform é sempre pior: é que, no ecossistema Apple, a distância entre imitar e ser nativo aparece mais rápido para quem usa.

O que fazer com isso no seu produto

A divisão prática que Poli propõe, e que considero a parte mais útil do argumento: o que vem do sistema (navegação, voltar, compartilhar, confirmações, sheets, controles, tamanho de texto) você não redesenha por padrão, porque o risco de redesenhar mal é maior que o ganho de parecer único. O que vem da marca (conteúdo, tipografia de títulos, ilustração, tom da escrita, os poucos momentos em que o app surpreende) é onde vale gastar o orçamento de diferenciação.

Quando o mockup sai de uma IA, a pergunta que vale fazer no seu processo de descoberta não é "ficou bonito?". É: o que, nessa tela gerada, parece um controle do sistema mas na verdade não se comporta como um? Nomear o dispositivo e pedir "as convenções atuais da plataforma" no prompt ajuda a reduzir a lacuna, mas não fecha. A revisão humana que falta é justamente verificar se o que parece nativo é nativo de verdade, ou só a imagem dele.

Fonte: UX Collective