Devoria
Guideline 4.0 Design: app rejeitado pela interface
Por Mehdi Azizi
Publicado em , 9 min
Guideline 4.0 Design: a Apple rejeita uma interface difícil de usar, muitas vezes no iPad. Teste cada tela no iPhone SE e no iPad, corrija e depois responda.
"Guideline 4.0 - Design" não é uma regra numerada como as outras: é a introdução da seção Design das regras da Apple, citada quando a sua interface parece abaixo do nível esperado. As rejeições publicadas são parecidas: telas apertadas no iPad, texto difícil de ler, login mandado para o Safari, Sign in with Apple mal integrado. A correção quase sempre começa no aparelho citado na mensagem, tela por tela.
Eu publico meus próprios apps iOS com Expo: Solys, TradaZen e Nolera estão configurados só para iPhone, e mesmo assim o revisor testou Solys e Nolera no iPad. Este guia se baseia no texto da Apple, em rejeições 4.0 publicadas por outros desenvolvedores e no checklist visual que aplico antes de cada envio. Para a visão geral dos motivos, leia por que a Apple rejeita um app.
O que a guideline 4.0 Design cobre?
A seção 4 das App Review Guidelines começa com um parágrafo sem número: "Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store." Ele acrescenta que o design é seu, mas que o restante define "minimum standards for approval". Também avisa que um app que piora depois de aprovado pode ser removido.
Resumindo: a Apple espera um app simples, caprichado e fácil de usar, e a 4.0 entra em cena quando o problema não se encaixa em nenhuma sub-regra específica. O texto não traz critérios numéricos. A referência prática são as Human Interface Guidelines, as regras de design da Apple.
As rejeições 4.0 mais frequentes
Estes são os quatro casos que encontrei em mensagens publicadas nos fóruns da Apple, com a frase citada.
| Caso | Frase da Apple | Correção |
|---|---|---|
| Telas apertadas no iPad | "crowded" | Layout fluido |
| Texto ilegível | "hard to read type" | Tamanhos das HIG |
| Login no Safari | "taken to Safari" | Login dentro do app |
| Sign in with Apple | Nome pedido de novo | Nome já fornecido |
Telas apertadas ou cortadas no iPad
A mensagem típica, publicada em setembro de 2025: "Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0." O restante explicava que o app usava só uma parte da tela (tópico do fórum).
A causa está na regra 2.4.1: "iPhone apps should run on iPad whenever possible." No Expo, a opção ios.supportsTablet é false por padrão, segundo a configuração de app do Expo. Seu app de iPhone então roda no iPad em modo de compatibilidade, numa janela no formato de iPhone. Configurar o app só para iPhone não o protege de um teste no iPad. Foi num iPad Air que a demo do Solys ficou impossível de vencer, um caso detalhado no guia da guideline 2.1.
Duas saídas. Ou você dá suporte de verdade ao iPad, com um layout que se adapta ao espaço disponível. As regras de design da Apple pedem que o layout seja decidido pelas classes de tamanho, não pelo modelo do aparelho. Ou você fica no iPhone, e cada tela precisa caber na janela de compatibilidade.
Texto difícil de ler
A mensagem, publicada em janeiro de 2025: "Your app included hard to read type or typography." A Apple lembra ali que os usuários esperam apps "simple, refined, and easy to use" (tópico do fórum).
As regras de tipografia da Apple dão referências para iOS: 17 pontos por padrão, 11 pontos no mínimo. As regras de acessibilidade pedem um contraste de pelo menos 4,5 para 1 em textos de até 17 pontos, e áreas de toque de 44 por 44 pontos por padrão.
Uma armadilha se você reduz as fontes nas telas pequenas, como eu faço para manter as mesmas quebras de linha em todo lugar: confira se o seu menor texto, reduzido no iPhone SE, continua com pelo menos 11 pontos.
Login mandado para o Safari
A mensagem, publicada no fórum da Apple: "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." A Apple pede que o cadastro e o login aconteçam dentro do app, e recomenda uma visualização Safari integrada.
No Expo, o expo-web-browser atende às duas necessidades sem sair do app: openAuthSessionAsync abre uma sessão de autenticação numa janela modal, e openBrowserAsync mostra uma página numa visualização Safari integrada. Já abrir o login com Linking.openURL manda o usuário para o app Safari. A escolha de quais formas de login oferecer é assunto de outra regra, a 4.8.
Sign in with Apple mal integrado
A mensagem, publicada em maio de 2024: "Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework." (tópico do fórum).
A documentação do expo-apple-authentication explica a armadilha: o nome e o e-mail só são fornecidos no primeiro login. Salve esses dados na hora, senão você vai ficar tentado a pedi-los de novo. Use também o botão fornecido pela biblioteca: a cor dele é definida com buttonStyle e os cantos com cornerRadius, nunca por style.
4.0, 4.2, 4.3: três rejeições de design para não confundir
| Regra | O que é avaliado | Correção |
|---|---|---|
| 4.0 | A interface | Corrigir as telas |
| 4.2 | A utilidade do app | Adicionar conteúdo nativo |
| 4.3 | A semelhança | Mudar de conceito |
A 4.2, Minimum Functionality, exige funções, conteúdo e uma interface que levem o app "beyond a repackaged website". A fronteira com a 4.0 é tênue: um site embalado num app pode levar as duas. Se falta substância no seu app, retocar as telas não vai bastar.
A 4.3 mira cópias e categorias saturadas: detalhei os dois parágrafos dela no guia da guideline 4.3 Design Spam. Uma interface caprichada não salva um app que parece com mil outros.
O checklist visual antes do envio
É o que eu acrescento em cada envio. Nos meus apps, cada tela é desenhada para o maior iPhone e depois reduzida numa única escala nos menores: mesmas proporções, mesmas quebras de linha. Depois comparo as renderizações lado a lado: iPhone SE, iPhone padrão, maior iPhone e um iPad para o modo de compatibilidade.
| Verificação | Aparelho | O que precisa funcionar |
|---|---|---|
| Primeira abertura | iPhone SE | Nada cortado |
| Onboarding completo | iPad | Todos os botões acessíveis |
| Teclado aberto | iPhone SE | Campo e botão visíveis |
| Texto ampliado | iPhone padrão | Nenhum texto truncado |
| Modo escuro | Todos | Texto legível em todo lugar |
| Áreas seguras | Maior | Nada embaixo da Dynamic Island |
| Paywall | iPhone SE | Preços e links visíveis |
| Login | iPad | Continua dentro do app |
Três observações:
- Texto ampliado. As regras de tipografia da Apple sugerem um teste simples: ativar os maiores tamanhos de texto em Settings, Accessibility, Display & Text Size, e conferir se tudo continua legível.
- Modo escuro. As regras da Apple sobre o modo escuro pedem que o app continue legível nas duas aparências. O Expo aplica
lightpor padrão se você não definiruserInterfaceStyle. O Solys segue a configuração do celular, o TradaZen fica no escuro e o Nolera no claro: nos três casos, testo a aparência exibida. - Áreas seguras. O conteúdo não passa embaixo da Dynamic Island nem do indicador de início. O Expo detalha o método no guia de áreas seguras.
No Mac, o simulador pode ser configurado pela linha de comando, o que torna o checklist rápido de repetir:
xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png
Num celular de verdade, faço a mesma rodada com um build do TestFlight. Metodologia: esse checklist é meu, construído a partir das rejeições que meus apps levaram, não uma lista fornecida pela Apple. Ele reduz as surpresas, mas não garante a aprovação.
Como responder a uma rejeição 4.0?
- Identifique o aparelho e a versão citados na mensagem e abra o mesmo modelo no simulador.
- Corrija todas as ocorrências. A mensagem típica pede para "address all instances" do problema, não só a tela da captura.
- Envie um novo build: o revisor testa o código embarcado.
- Responda com capturas feitas no mesmo aparelho, respondendo à mensagem do App Review.
- Só recorra se tiver certeza: a Apple permite acionar o App Review Board, com um único recurso por envio rejeitado.
O modelo que eu usaria, para adaptar:
Hello,
Thank you for your feedback regarding Guideline 4.0.
We reproduced the issue on [device] running [OS version].
Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].
We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.
Attached: screenshots of the updated screens on [device].
Best regards,
Prepare seu envio sem rejeição de design
O Review Kit reúne meu checklist antes do envio, que cobre entre outras coisas a regra 2.4.1 sobre o iPad, e skills do Claude Code que revisam o seu projeto. Para um olhar humano, reserve uma hora comigo: abrimos suas telas em vários tamanhos, por videochamada. O passo a passo completo depois de uma rejeição está na página app rejeitado pela Apple.
Está preparando seu primeiro lançamento? Faça seu diagnóstico gratuito: ele coloca as etapas em ordem e te envia meu checklist anti-rejeição da Apple.
Perguntas frequentes
O que significa "Guideline 4.0 - Design" numa mensagem de rejeição?
A Apple considera sua interface abaixo do nível esperado, sem apontar uma sub-regra específica: telas apertadas, texto difícil de ler, fluxo de login considerado ruim. A mensagem geralmente cita o aparelho usado e muitas vezes inclui uma captura.
Meu app está configurado só para iPhone: por que a Apple testa no iPad?
Porque a regra 2.4.1 quer que apps de iPhone rodem no iPad sempre que possível. Seu app abre lá em modo de compatibilidade, numa janela no formato de iPhone, e cada tela precisa continuar utilizável.
Preciso de um novo build depois de uma rejeição 4.0?
Sim, na maioria dos casos. O revisor testa o código embarcado na primeira abertura, e uma correção entregue remotamente pode passar despercebida. É o que explico no guia da guideline 2.1.
O modo escuro é obrigatório para ser aprovado?
O texto das regras de revisão não exige. As regras de design lembram que os usuários esperam que os apps sigam a configuração deles. Se você força o claro ou o escuro, como o Expo permite, teste essa aparência. Se você segue a configuração do celular, teste as duas.
Dá para recorrer de uma rejeição 4.0?
Sim, junto ao App Review Board, se você acha que seu app cumpre as regras. A Apple pede motivos precisos, um único recurso por envio rejeitado, e que você responda primeiro aos pedidos de informação.
