Diretriz 4.2 da Apple: A Apple rejeitará um aplicativo de site? Como passar na revisão

A Apple pode rejeitar um aplicativo baseado em site, e “funcionalidade mínima” é o motivo mais comum. A Diretriz 4.2 é a regra por trás disso. Um aplicativo de site não é recusado automaticamente, mas um aplicativo que não adiciona nada além de um site em um frame corre um risco real.

Este guia explica o que diz a diretriz, o que os revisores tendem a procurar e como preparar uma submissão. Ninguém fora da Apple pode prometer aprovação, e este artigo não o faz. O que você pode fazer é remover os motivos evitáveis ​​de rejeição.

O que a Diretriz 4.2 realmente diz

As Diretrizes de Revisão de Aplicativos declaram em 4.2, Funcionalidade Mínima:

Seu aplicativo deve incluir recursos, conteúdo e interface de usuário que o elevem além de um site reembalado. Se o seu aplicativo não for particularmente útil, exclusivo ou “semelhante a um aplicativo”, ele não pertence à App Store.

As palavras que importam são “site reformulado”. A regra não proíbe aplicativos criados em torno de conteúdo da web. Ele proíbe aplicativos que não oferecem nada que um site já não ofereça.

Diretrizes relacionadas também aparecem em análises de aplicativos de sites:

• 4.2.2: Além dos catálogos, os aplicativos não devem ser principalmente materiais de marketing, anúncios, recortes da web, agregadores de conteúdo ou uma coleção de links.
• 4.2.3: O aplicativo deve funcionar sozinho, sem exigir a instalação de outro aplicativo, e deve divulgar e solicitar qualquer download grande necessário na primeira inicialização.
• 2.1 (Completude do aplicativo): Os envios devem ser versões finais com URLs funcionais, sem conteúdo de espaço reservado e detalhes da conta demo se o aplicativo tiver um login.
• 4.2.6: Os aplicativos criados a partir de um modelo comercializado ou de um serviço de geração de aplicativos são rejeitados, a menos que sejam enviados diretamente pelo fornecedor do conteúdo do aplicativo.

Sempre leia você mesmo o texto atual, pois a Apple atualiza as diretrizes. A fonte oficial é o Diretrizes de revisão da App Store.

A Apple rejeitará um aplicativo de site?

Depende do que o aplicativo enviado faz. Na prática, os revisores reagem a alguns padrões:

• O aplicativo abre um único URL e parece idêntico ao site móvel, incluindo navegação no estilo web.
• Ele mostra apenas um mural de login sem conteúdo navegável, para que o revisor não possa ver o que o aplicativo faz.
• Ele quebra ou mostra erros sem conexão.
• Seus links saltam constantemente para o navegador.
• Parece um folheto de marketing para uma empresa sem função própria.

Um aplicativo que envolve um serviço real, como uma loja, um sistema de reservas, uma área para membros ou uma biblioteca de conteúdo, e o apresenta com uma navegação semelhante à de um aplicativo, está em uma posição diferente. Você ainda pode ser rejeitado, já que a revisão é um julgamento, mas você tem algo a apontar.

Por que um aplicativo gerado por serviço precisa de sua própria conta

A diretriz 4.2.6 diz que os aplicativos feitos com um serviço de geração de aplicativos são rejeitados, a menos que sejam enviados diretamente pelo fornecedor do conteúdo do aplicativo. Para o proprietário de um site, a leitura prática é esta: publique com sua própria conta de desenvolvedor Apple, em seu próprio nome ou da sua empresa, e certifique-se de que o aplicativo represente seu próprio conteúdo.

É também assim que o SiteTo.App funciona. As compilações são assinadas com a conta de desenvolvedor da Apple que você conecta e a compilação é entregue ao TestFlight em sua conta do App Store Connect. Você é o proprietário da listagem e a envia. Veja o Guia da conta do desenvolvedor Apple para a configuração. Não entregue seu conteúdo a um fornecedor que envia o mesmo shell para muitos clientes por conta própria.

O que faz um aplicativo de site parecer um aplicativo

O objetivo não é adicionar recursos só por adicionar. É para melhorar o uso do celular. Adições fortes e honestas incluem:

• Navegação nativa. Uma barra de guias ou menu que corresponde à forma como as pessoas navegam em seu site em um telefone, em vez de um cabeçalho de desktop espremido em uma tela pequena.
• Notificações push. Mensagens que os usuários aceitam, como atualizações de pedidos, lembretes de reservas ou novos conteúdos. No SiteTo.App eles são configurados através do Firebase; veja o Guia do Firebase.
• Links profundos. Links de notificações ou e-mail que abrem a tela direita do aplicativo.
• Uma experiência de lançamento projetada. Um ícone, uma tela inicial e um estado claro de carregamento e erro.
• Transferências nativas. Compartilhamento, upload de arquivos, acesso à câmera ou downloads que funcionam corretamente no dispositivo.

Não adicione um artifício como um botão de lanterna. Ela não aborda a diretriz 4.2 e os revisores a observam.

Uma lista de verificação de pré-envio

Trabalhe com isso antes de fazer upload:

1. Teste toda a viagem em um iPhone real. Instale através do TestFlight, não apenas um simulador. Abra o aplicativo, faça login, navegue vários níveis de profundidade e use o gesto de voltar.
2. Teste sem conexão. Ative o modo avião e abra o aplicativo. Você deverá ver uma mensagem clara, não uma página em branco.
3. Verifique todos os links externos. Decida propositalmente quais links ficam dentro do aplicativo e quais abrem o navegador.
4. Corrija problemas de layout do site. Problemas de resposta, pequenos alvos de toque e pop-ups somente para desktop são óbvios em um aplicativo.
5. Remova o conteúdo do espaço reservado. A Diretriz 2.1 espera um produto final com suporte funcional e URLs de privacidade.
6. Forneça credenciais de demonstração. Se for necessário um login, inclua uma conta que continue funcionando durante a revisão.
7. Torne as respostas de privacidade precisas. Eles devem descrever toda a experiência, incluindo análises da web e ferramentas de pagamento carregadas no aplicativo.
8. Escreva capturas de tela honestas e uma descrição. Mostre o aplicativo real e não reivindique os recursos que faltam.
9. Use notas de revisão. Explique o que o aplicativo faz, onde estão os recursos nativos e quaisquer requisitos de região ou conta.

Você pode comparar seu site com muitos deles com o lista de verificação de preparação, e nosso guia de publicação cobre as etapas da loja ao redor.

Como escrever notas de revisão que ajudam

Os revisores veem muitos envios. Uma nota curta e específica os ajuda a encontrar o valor rapidamente. Cobrir:

• Para que serve o aplicativo, em uma ou duas frases.
• Como fazer login, com credenciais de demonstração funcionais.
• Onde encontrar os recursos nativos, por exemplo "As notificações podem ser ativadas na guia da conta".
• Qualquer coisa incomum, como um recurso que precisa de uma região ou hardware específico.

Mantenha-o factual. Evite discussões sobre as diretrizes na primeira submissão. Guarde isso para uma resposta se você for rejeitado.

Se a Apple rejeitar o aplicativo

Uma rejeição é uma conversa, não um veredicto final. A Apple explica a diretriz que aplicou no Centro de Resolução.

1. Leia a mensagem com atenção. Anote o número da diretriz e quaisquer telas ou comportamentos específicos mencionados.
2. Corrija o problema real. Se o motivo for funcionalidade mínima, melhore o que o aplicativo faz em vez de reformular a descrição.
3. Responda com precisão. Descreva o que mudou e onde o revisor pode ver.
4. Reenvie uma nova compilação, se necessário. Uma alteração no binário requer um novo upload.
5. Apelar apenas com um caso. Se você acredita que a rejeição é um erro, use o processo de apelação da App Review e cite os fatos.

Como um aplicativo baseado em site carrega seu site, muitas correções acontecem no próprio site e aparecem no aplicativo sem um novo lançamento na loja. As alterações na configuração nativa ainda precisam de uma nova compilação.

Perguntas comuns

Um aplicativo de site precisa funcionar offline?

Não como regra, mas deve falhar normalmente. Uma tela em branco sem conexão parece inacabada e isso afeta a forma como os revisores veem o aplicativo.

Um PWA é tratado de forma diferente de qualquer outro site?

Um PWA em um aplicativo iOS ainda é conteúdo da web dentro de um shell nativo, portanto, a mesma diretriz se aplica. Ver como publicar um PWA na App Store e no Google Play.

Posso enviar o mesmo aplicativo para várias marcas?

A Diretriz 4.2.6 restringe aplicativos criados a partir de um modelo ou serviço de geração e enviados em nome de clientes. Cada empresa deve publicar sob sua própria conta.

Preciso pagar por um conversor para ser aprovado?

Nenhuma ferramenta decide o resultado. A Apple avalia o aplicativo enviado. Pagar por uma construção não muda isso, portanto o preço é separado da aprovação. Ver preços.

Próximas etapas

Comece testando seu site como um aplicativo. Visualize seu site em SiteTo.App, experimente em seu telefone e observe o que parece ser um site em vez de um aplicativo. Corrija esses pontos e siga o criar e publicar guia.