Módulo 2 · 5 de 9
Nativo, híbrido, web ou PWA?
Leitura: ~4 min
Agora que você entende HTML, CSS e JavaScript, existe outra distinção que vai afetar diretamente as suas decisões de design: o tipo de aplicação que o time está construindo. Porque projetar para um app nativo é diferente de projetar para um web app. Os componentes mudam, as interações mudam, as limitações mudam. E se você não pergunta isso logo no começo do projeto, pode acabar desenhando algo que o time não consegue (ou não deveria) construir.
Os quatro tipos que você precisa conhecer
Apps nativos: feitos sob medida para a plataforma
São aplicativos construídos especificamente para uma plataforma, iOS ou Android. Usam as linguagens e ferramentas próprias de cada sistema: Swift para iOS, Kotlin para Android. A grande vantagem é a performance e o acesso total aos recursos do dispositivo: câmera, GPS, notificações push, biometria.
O trade-off? Você precisa de dois times (ou dois conjuntos de componentes), adaptando o design para as convenções de cada plataforma: Material Design no Android e Human Interface Guidelines no iOS.
Apps híbridos e cross-platform: um código, duas plataformas
Ferramentas como React Native (o React, aquela base de código pronta, levado para apps de celular) e Flutter permitem escrever um único código que roda em iOS e Android. Para empresas, isso reduz custo e tempo de desenvolvimento significativamente.
Exemplos que você provavelmente usa:
- Nubank : construído com Flutter. Mesma base de código para iOS e Android, com ajustes de plataforma.
- Discord : versão mobile usa React Native.
- Shopify : app para lojistas construído com React Native.
E a escolha pode variar dentro da mesma empresa: no iFood, o app do consumidor é nativo (Kotlin no Android, Swift no iOS), enquanto o app dos restaurantes parceiros foi construído com Flutter, depois de o time testar e descartar React Native.
Para o designer, o ponto-chave é: híbrido não significa "uma interface só". Cada plataforma tem convenções de interação diferentes, o gesto de voltar, o posicionamento do menu, o estilo dos modais. Ignorar essas convenções afeta a experiência do usuário, mesmo que o código funcione nas duas plataformas. Um bom designer de produto pergunta: "estamos adaptando para cada plataforma ou unificando? E quais compromissos isso traz?"
Web apps: sem instalação, direto no navegador
São aplicações completas que rodam direto no navegador, sem instalação. Construídas com HTML, CSS e JavaScript, funcionam em qualquer dispositivo com um browser.
Exemplos que talvez surpreendam:
- Figma : sim, o Figma é um web app. Roda inteiramente no navegador. Todo o seu trabalho de design acontece em uma aplicação web.
- Google Docs : edição de documentos em tempo real, no browser.
- Notion : gestão de projetos e documentação, sem instalar nada.
- Canva : design gráfico completo rodando no navegador.
Para o designer, web apps significam pensar em responsividade (a mesma aplicação precisa funcionar em telas de 360px e de 1920px) e em cross-browser (funcionar em Chrome, Firefox, Safari). As limitações de acesso a hardware são maiores, câmera e notificações têm suporte mais restrito que em apps nativos.
PWAs (Progressive Web Apps): o melhor dos dois mundos?
As PWAs são web apps com superpoderes. Podem ser "instaladas" no celular (ícone na tela inicial), funcionar offline, enviar notificações push, e carregar de forma quase instantânea. Combinam a acessibilidade da web com alguns recursos de apps nativos.
Exemplos reais:
- X (antigo Twitter) : o site x.com é uma PWA instalável. Lançada em 2017 como Twitter Lite, reduzia o consumo de dados em até 70% (com o modo de economia de dados ativado) e ocupava menos de 3% do armazenamento do app nativo Android; em 2019 virou a experiência web padrão da plataforma.
- Starbucks : PWA que permite fazer pedidos mesmo com conexão instável.
- Pinterest : migrou para PWA em mercados emergentes e viu aumento significativo em engajamento.
Importante saber: PWAs ainda têm limitações em dispositivos Apple, mas menos do que se imagina. Desde o iOS 16.4 (2023), notificações push e acesso offline já funcionam em PWAs no iPhone, desde que o app seja adicionado à tela inicial, e alguns recursos de hardware seguem restritos. Então, antes de projetar funcionalidades mais avançadas, vale alinhar com o time técnico o que é viável em cada plataforma.
E o que muda para você?
Como designer, saber qual tipo de aplicação o time está construindo muda tudo: os componentes que você vai usar, as interações que são possíveis, os breakpoints que precisa considerar, e até a biblioteca de componentes que faz sentido como base.
Pergunte isso logo na primeira reunião do projeto. É uma das perguntas mais estratégicas que um designer pode fazer, e mostra que você entende o contexto técnico do que está projetando.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
Um colega descreve uma ferramenta assim: "roda inteira no navegador, sem instalar nada, e funciona em qualquer computador com Chrome ou Safari". Que tipo de aplicação é essa?
É um web app. A pista é rodar direto no navegador, sem instalação, construído com HTML, CSS e JavaScript. O Figma e o Google Docs são exemplos: todo o trabalho acontece em uma aplicação web. O trade-off é acesso mais restrito a hardware, como câmera e notificações, comparado a um app nativo.
O time decide transformar o produto em PWA para enviar notificações push e funcionar offline. Antes de projetar essas telas, o que você precisa perguntar?
Pergunte como isso se comporta no iOS. As PWAs ainda têm limitações em dispositivos Apple, embora, desde o iOS 16.4 (2023), push e acesso offline já funcionem quando o usuário adiciona o app à tela inicial. Vale alinhar com o time técnico o que é viável em cada plataforma antes de desenhar esses fluxos, para não projetar algo que só funciona para parte dos usuários.