Guideline 4.2 Minimum Functionality: app rejeitado

A guideline 4.2, "Minimum Functionality", rejeita um app que não oferece nada além de um site, ou que oferece pouco demais para alguém querer mantê-lo. A solução não é empilhar recursos nativos: é colocar um no centro do uso e depois dizer ao revisor onde encontrá-lo. A correção quase sempre exige um novo build.

Eu publico meus próprios apps iOS: Solys, TradaZen e Nolera estão na App Store. Este guia se baseia no texto oficial da Apple, lido em 15 de outubro de 2026, e em rejeições 4.2 publicadas por desenvolvedores nos fóruns da Apple. Os apps rejeitados citados abaixo são exemplos. Para a visão geral de todos os motivos, leia por que a Apple rejeita um app.

O que diz a guideline 4.2?

A 4.2 está na seção 4, "Design", das App Review Guidelines. A primeira frase define o critério: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Ou seja, seu app precisa oferecer recursos, conteúdo e uma interface que o coloquem acima de um site reembalado.

O texto acrescenta duas ideias. Um app que não é realmente útil, único ou "app-like" não tem lugar na App Store. E um app que não oferece nem entretenimento duradouro nem utilidade suficiente pode ser rejeitado. A 4.2 avalia, portanto, duas coisas: a diferença em relação à web e a quantidade de valor.

As sub-regras que a mensagem pode citar

Sub-regra	O que a Apple pede	A rejeição típica
4.2	Ir além de um site	Site exibido em uma WebView
4.2.1	Uma experiência real de realidade aumentada	Um modelo 3D colocado na visão AR
4.2.2	Não ser só marketing ou links	App vitrine, agregador, links
4.2.3	Um app independente, downloads claros	App que exige outro app
4.2.6	Nada de app criado a partir de template comercial	Template enviado por um prestador

Três observações. A 4.2.2 abre uma exceção para catálogos: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Um catálogo de produtos pode passar, então. Um folheto publicitário, não.

A 4.2.3 tem dois itens. O (i) pede que o app funcione sozinho, sem instalar outro app. O (ii) pede, se o app precisar baixar recursos na primeira abertura, que informe o tamanho do download e peça permissão antes.

A 4.2.6, sobre templates comerciais e serviços de geração de apps, está detalhada no guia da guideline 4.3, porque anda junto com a regra antispam.

As duas mensagens 4.2 mais comuns

A mensagem da Apple começa com o título "Guideline 4.2 - Design - Minimum Functionality". O resto diz qual dos dois problemas o revisor viu. Aqui vão duas formulações publicadas por desenvolvedores nos fóruns da Apple. Elas têm alguns anos: o texto exato pode ter mudado, as duas famílias não.

O app parece um site. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Essa mensagem, publicada nos fóruns da Apple, traz uma frase decisiva: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

O app é magro demais. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Essa segunda mensagem pede para repensar o conceito e reconhece que nenhuma regra numérica define o que é útil ou divertido.

Adicionar notificações, localização e um botão de compartilhar a um site empacotado não basta: a Apple escreveu isso nas próprias rejeições.

Quatro casos típicos de rejeição 4.2

Os quatro casos abaixo são exemplos criados para ilustrar a regra, não apps reais.

O site empacotado

Exemplo: uma academia exibe o site mobile em uma WebView, com uma barra de abas nativa por cima. A agenda, a reserva e a conta são páginas web. O revisor encontra ali o que o Safari mostraria. A Apple diz isso na sua página de App Review: um site servido dentro de um app iOS, conteúdo web não adaptado ao iOS ou interações web limitadas não fazem um app de qualidade.

O que eu faria: reconstruir em nativo as telas da ação principal, aqui a agenda e a reserva. Depois, adicionar o que o site não consegue fazer: um lembrete antes da aula, a agenda disponível sem internet, a próxima aula em um widget.

O app simples demais

Exemplo: um app que mostra uma frase por dia, e mais nada. Em dez segundos você já viu tudo. A 4.2 fala em "lasting entertainment value or adequate utility": um valor que dura, ou uma utilidade suficiente. Para corrigir, dê profundidade à ação principal, não acrescente telas em volta. Aqui: um histórico, favoritos, um lembrete no horário escolhido, um widget na tela inicial.

O app gerado por IA, sem nada nativo

Exemplo: um campo de texto, um botão, uma resposta de IA exibida em texto puro. A Apple não julga a ferramenta, e sim o que aparece na tela do revisor. Se a experiência cabe em uma página web, a 4.2 tem boas chances de cair.

Eu detalho o que a IA faz bem e o que ela erra em criar um app com IA. O formato gerado por cada ferramenta, aplicação web ou projeto mobile, é comparado em Lovable, Rork ou FlutterFlow.

A casca esperando conteúdo

Exemplo: um marketplace sem anúncios, um diretório vazio, um feed que mostra "Em breve". O revisor abre um app que não tem nada para mostrar. Esse caso também esbarra na 2.1, que rejeita conteúdo provisório: veja o guia da guideline 2.1. Envie o app quando ele tiver conteúdo real, ou forneça uma conta de demonstração já preenchida.

O teste que eu faço: "E no Safari?"

Antes de enviar, eu me pergunto se um site poderia oferecer a mesma função principal. Se sim, o app está exposto à 4.2. Esta é a minha tabela para avaliar um recurso nativo. Um recurso conta quando serve à ação principal, não quando é enfeite.

Recurso	Ele conta quando...	Ele não basta quando...
Notificações	Trazem uma informação esperada	Só divulgam seus artigos
Offline	O conteúdo principal continua utilizável	Só aparece uma tela de erro
Widget	Mostra um dado próprio da pessoa	Mostra o seu logo
Compartilhamento	A pessoa envia conteúdo para o seu app	Só compartilha um link
Câmera, sensores	Fazem parte da ação principal	Abrem o seu site
Dados locais	O app calcula, organiza e lembra	Tudo vive em uma página web

As recomendações da Apple vão na mesma direção. Um widget mostra um conteúdo atual, legível de relance. Uma notificação traz uma informação útil, em poucas palavras, e não serve para empurrar a pessoa para uma tarefa no app.

O que meus apps fazem que um site não faz

Eu crio cada app em torno de uma função principal que não existe em um navegador, ou de um valor que faz a pessoa voltar.

• Solys é um despertador. O alarme passa pelo AlarmKit, o serviço de alarme do iOS 26: ele toca mesmo no modo silencioso, como o despertador da Apple. Para desligar, é preciso vencer um minijogo, e os apps escolhidos continuam pausados depois do despertar. Nenhuma página web faz um iPhone tocar no silencioso.
• TradaZen é um simulador de trading: um gráfico real em uma data real, uma decisão, candles que vão sendo revelados, duelos ranqueados e um nível que sobe. Aqui, não é um recurso nativo que sustenta o app. É o valor de entretenimento duradouro de que a 4.2 fala.
• Nolera é um guarda-roupa: você fotografa suas roupas, o app recorta o fundo e organiza tudo, depois sugere um look toda manhã. A câmera faz parte da ação principal. Ela não é um bônus.

A 4.2 não exige uma lista de recursos nativos: exige um motivo para instalar o app em vez de abrir um site.

Corrigir uma rejeição 4.2, passo a passo

1. Identifique a família. Navegação web: é o site empacotado. Conteúdo ou recursos mínimos: é o app magro demais. A 4.2.3: dependência de outro app ou download não avisado.
2. Mude o produto, não o texto. Uma resposta que argumenta sem mudar nada não tem por que convencer. Reconstrua em nativo as telas da ação principal, ou acrescente a profundidade que falta.
3. Planeje um novo build. A causa está no app: uma atualização remota não basta. Cada envio volta para a fila, veja o prazo de aprovação da App Store.
4. Escreva notas de revisão que guiem. A Apple pede, na página sobre as informações para uma revisão completa, que você descreva o conceito, os recursos e o público. Para uma atualização: o que mudou e onde encontrar.
5. Recorra só se o revisor deixou passar algo. Se o seu recurso nativo já existia mas não foi visto, responda no App Store Connect com um vídeo curto. O recurso ao App Review Board se justifica quando seu app foi mal compreendido, não quando ele é magro.

O modelo de notas que eu usaria, em inglês, para adaptar:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Escreva só o que existe no build enviado. Um recurso anunciado e impossível de encontrar renderia uma nova rejeição, desta vez pela 2.1.

O checklist 4.2 antes do envio

• Você consegue dizer em uma frase o que seu app faz que um site não faz.
• As telas da ação principal são nativas, não páginas web.
• Cada recurso nativo serve à ação principal, e o revisor esbarra nele em menos de dois minutos.
• O app tem conteúdo real desde a primeira abertura, ou uma conta de demonstração preenchida.
• O app funciona sozinho, sem outro app para instalar.
• Um download grande na primeira abertura informa o tamanho e pede permissão.
• As notas de revisão descrevem o conceito, o público e onde está cada recurso.
• Se a sua ideia beira o limite, você a testou antes de programar, com um MVP de app iOS bem delimitado.

Passar na 4.2 já no próximo envio

Se o seu app acabou de ser rejeitado pela 4.2, o Apple Review Kit ajuda você a encontrar a regra citada e o que ela pede, com os modelos de notas para o revisor. Se você ainda está construindo, o percurso do iOS Kit parte da função principal antes da primeira linha de código. Para um olhar humano, reserve uma hora comigo. O passo a passo completo está na página app rejeitado pela Apple.

Se você está preparando seu primeiro lançamento, faça seu diagnóstico gratuito: ele coloca as etapas em ordem e envia meu checklist antirrejeição da Apple. A página inicial mostra como criar um app mobile pensado para a revisão desde o início.

Ninguém pode garantir que a Apple vai aceitar seu app. Eu posso ajudar você a dar a ele um motivo para existir na App Store.

Perguntas frequentes

O que significa "Guideline 4.2 - Design - Minimum Functionality"?

É o título da rejeição por funcionalidade mínima. A Apple considera que seu app se parece demais com um site, ou que oferece pouco conteúdo ou poucos recursos. O mesmo título pode apontar uma sub-regra: "Guideline 4.2.2" para um app vitrine ou uma lista de links, 4.2.3 para um app que depende de outro app.

Um app em WebView é sempre rejeitado?

Não. A regra mira o site colocado dentro de um app, não a tecnologia. O revisor avalia a experiência principal: se as telas são páginas web que fazem o mesmo que o Safari, o risco é alto. Uma página de ajuda aberta no navegador não é o problema.

Adicionar notificações push basta para passar na 4.2?

Não. Em uma mensagem de rejeição publicada nos seus fóruns, a Apple escreve que notificações, localização e compartilhamento não bastam para tornar a experiência rica o suficiente. Uma notificação conta quando serve à função principal, como um alarme ou um lembrete escolhido pela pessoa.

Qual a diferença entre a guideline 4.2 e a 4.3?

A 4.2 avalia seu app sozinho: ele entrega o bastante em comparação com um site? A 4.3 o compara com os outros: ele é uma cópia, uma variação ou mais um app em uma categoria saturada? Um mesmo app pode levar as duas, mas elas não se corrigem do mesmo jeito.

É preciso um novo build depois de uma rejeição 4.2?

Quase sempre, já que a causa está no próprio app. A única exceção: o revisor não encontrou um recurso que já existia. Nesse caso, responda no App Store Connect com notas precisas e um vídeo curto, sem mudar o build.