Casos de rejeição na App Store / Google Play e um checklist prático para passar na revisão

Você está prestes a publicar o app e a revisão o devolve. Essa é uma barreira pela qual muitos desenvolvedores passam pelo menos uma vez.

E as razões para uma revisão travar não se limitam a crashes ou builds com defeito. Explicações de permissões, política de privacidade, fluxo de pagamento, metadados da store ou notas de revisão insuficientes também podem ser a causa. Não é raro que questões operacionais fora da implementação em si provoquem a rejeição.

Neste artigo, organizo por categoria os casos de rejeição mais comuns na App Store e no Google Play e resumo, de um ponto de vista prático, o que vale a pena verificar antes da submissão.

Público-alvo

• Pessoas que vão submeter um app à App Store / Google Play pela primeira vez
• Pessoas que já receberam rejeição antes e querem organizar a causa
• Pessoas que desenvolvem com stacks cross-platform como React Native ou Flutter
• Times que querem formalizar um checklist antes do lançamento

Termos que vale fixar primeiro

Antes de seguir, vale organizar rapidamente os termos que aparecem ao longo do artigo. Se você tiver isso claro desde o início, os casos de rejeição da segunda metade ficam bem mais fáceis de entender.

• reviewer: A pessoa da Apple ou do Google que revisa o app. Ela não verifica só o binário, mas também a descrição da store, capturas de tela, informações declaradas e notas de revisão.
• IAP (In-App Purchase): O mecanismo de compra dentro do app da Apple para vender conteúdo digital ou funcionalidades internas.
• ATT (App Tracking Transparency): O mecanismo do iOS que pede permissão ao usuário antes de fazer tracking entre apps ou sites de outras empresas.
• IDFA: Identificador usado para medição de anúncios. Se sua configuração usa isso, normalmente será preciso revisar ATT e App Privacy.
• Data safety / App Privacy: Formulários de autodeclaração de coleta de dados no Google Play / App Store. Se você adiciona um SDK e não atualiza a declaração, surge uma inconsistência.
• target SDK: Valor que indica para qual API level do Android o app foi projetado. minSdkVersion representa o OS mínimo suportado, então não é a mesma coisa.
• metadados da store: O conjunto de informações exibidas ou enviadas na store, como capturas, texto descritivo, subtítulo, categoria, classificação etária e campos declarativos.
• WebView: Componente que mostra uma página web dentro do app. É útil, mas se a maior parte da tela depende dele, o valor nativo tende a parecer fraco.
• UGC (User Generated Content): Conteúdo gerado por usuários, como comentários, envio de imagens, perfis ou avaliações.
• restore purchases: O fluxo para restaurar compras anteriores. É importante para conferir assinaturas e compras únicas.
• entitlement: Configuração de permissão ligada a uma capability da Apple ou a uma funcionalidade específica. Muitas servem para apps comuns, mas alguns entitlements especiais exigem aprovação da Apple ou condições extras.

Primeiro entenda a perspectiva da revisão

Para reduzir rejeições, ler apenas as guidelines não basta. É mais útil entender o que o reviewer verifica em pouco tempo, porque isso ajuda a definir prioridades.

Os estados que mais costumam travar são estes:

• A implementação existe, mas a explicação é insuficiente
• O app pede uma permissão, mas a relação dela com a função não está clara
• Existe cobrança, mas o preço ou o caminho de cancelamento é ambíguo
• As capturas ou o texto não combinam com o app real
• O reviewer não consegue fazer login e não chega às funções principais

Antes da beleza visual, a revisão observa principalmente segurança, consistência e completude.

Organize primeiro as diferenças entre App Store e Google Play

As duas plataformas procuram um app seguro, não enganoso e não inacabado, mas os pontos em que cada uma mais bloqueia variam um pouco.

Em termos gerais, a App Store costuma travar mais na rigidez da experiência, dos pagamentos e das explicações de privacidade, enquanto o Google Play costuma travar mais nos requisitos técnicos e na consistência da autodeclaração.

Por isso, mesmo para o mesmo app, a ordem de preparação muda um pouco.

• App Store: acertar primeiro o comportamento em dispositivo real, a tela de pagamento, os textos de permissão e as notas de revisão
• Google Play: acertar primeiro target SDK, permissions, Data safety e declaração de anúncios

Estudos de caso com base em mensagens reais de bloqueio e rejeição

Aqui eu cito mensagens típicas de revisão da App Store e de bloqueio de publicação do Google Play para organizar o que cada frase realmente quer dizer e o que deve ser corrigido primeiro. As categorias da segunda metade funcionam bem como explicação detalhada desses casos.

Case 1: crash logo após o lançamento na App Store

"Descobrimos um ou mais bugs no seu app durante a revisão em um iPhone com iOS 17.0 em Wi-Fi. Especificamente, o app crashou imediatamente após o lançamento."

Isso não é tratado como uma falha temporária, mas como um defeito grave reproduzível no dispositivo de revisão. A primeira coisa a fazer é verificar a reprodução em modo avião, com instalação limpa, com conta vazia e em rede lenta, e listar tudo o que roda logo após o lançamento.

Case 2: falta de Privacy Policy na App Store

"Seu app coleta dados do usuário ou de uso, mas não possui uma privacy policy URL."

Isso significa que o app manipula algum tipo de dado por meio de SDKs ou APIs próprias, mas falta a explicação pública visível para o usuário. A primeira coisa a fazer é publicar uma URL pública explicando os dados coletados, a finalidade, o eventual compartilhamento com terceiros e o contato, e depois alinhar App Store Connect com App Privacy.

Case 3: cobrança digital sem IAP na App Store

"Seu app inclui a capacidade de comprar conteúdo digital, mas o mecanismo de compra não usa in-app purchase."

Isso não é um problema de como o preço é exibido. O aviso aponta que o método de cobrança não combina com a natureza do que está sendo vendido. A primeira coisa a fazer é quebrar exatamente o que está sendo vendido e mover para um desenho baseado em IAP tudo o que for valor digital consumido dentro do app.

Case 4: Google Play não atende ao requisito de target API

"Quando você publica um novo app, precisa direcioná-lo para Android 15 (API level 35) ou superior."

O Google Play não trabalha apenas com rejection mails clássicos. Ele também pode bloquear a publicação antes do envio por meio de requisitos na Console. Quando esse texto aparece, o problema ainda não é a qualidade do app, e sim um requisito de publicação não atendido. A primeira coisa a fazer é preparar um plano de atualização que cubra não só targetSdkVersion, mas também bibliotecas dependentes, diferenças de permissões, notificações e comportamento em segundo plano.

Case 5: uma nova personal account do Google Play não consegue avançar para production

"Você precisa executar um closed test para seu app com no mínimo 12 testers que tenham permanecido opted-in continuamente nos últimos 14 dias."

Em uma primeira publicação, você pode ficar travado por um production gate ligado ao tipo de account, mesmo que a qualidade do app esteja boa. Uma nova personal account não consegue publicar enquanto não cumprir as condições de closed test e production access. Além disso, pode ser exigido que o account owner conclua a device verification em um Android real.

A primeira coisa a fazer é confirmar se a conta alvo é de fato uma nova personal account e concluir o quanto antes o closed test de 12 pessoas / 14 dias, o opt-in contínuo dos testers e a device verification usando a Play Console mobile app.

Na App Store, esses pontos costumam voltar como comentários de revisão; no Google Play, costumam travar via requisitos da Console ou diferenças nas declarações. Mas, no fundo, a maioria dos casos cai em uma destas categorias: app inacabado, explicação insuficiente, declaração inconsistente ou requisito de publicação não atendido.

Categoria 1: Completude do app

1. O app falha logo após o lançamento

Erros de API no primeiro início, falha ao inicializar DB local ou acesso a nil estão entre os motivos mais típicos de devolução. Aqui, acesso a nil significa que o app tenta ler um objeto antes de ele ter um valor válido. Como o ambiente do reviewer nunca é igual ao seu, vale superproteger a fase de arranque.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    setupApp()
                }
        }
    }

    private func setupApp() {
        do {
            try initializeDatabase()
        } catch {
            print("DB init failed: \(error)")
        }
    }
}

Pontos para verificar:

• O app não falha no primeiro início mesmo sem conta existente
• O app consegue ao menos abrir sem rede
• Se a obtenção de dados obrigatórios falhar, ainda existe uma tela de fallback

Uma solução eficaz é separar o processamento de arranque em dois tipos:

• O que precisa necessariamente dar certo antes de mostrar qualquer coisa
• O que pode falhar e ser tentado novamente mais tarde

Por exemplo, não há necessidade de bloquear o app inteiro para carregar remote config ou pré-carregar recomendações. Se você mostrar primeiro a home ou pelo menos uma estrutura mínima, e só depois reexecutar o que falhou, o app tende a quebrar muito menos em diferenças de ambiente de revisão.

Na prática, costuma ser mais rápido corrigir nessa ordem:

• Coletar o crash log
• Listar toda a inicialização que acontece no arranque
• Reduzir o código síncrono que necessariamente precisa dar certo
• Testar em dispositivo real com modo avião, instalação limpa e dados vazios

2. Há funções não implementadas ou placeholders ainda visíveis

Telas que mostram apenas "Coming Soon", botões que não fazem nada e links quebrados passam facilmente a sensação de app inacabado.

Logo antes da submissão, costuma ser mais seguro priorizar o seguinte em vez de adicionar novas funções:

• Remover funções não implementadas que já têm entrada na navegação
• Apagar textos de teste e cópia provisória
• Levar telas de erro e estados vazios a um nível mínimo aceitável

3. Sem login não dá para verificar nada

Mesmo em apps com login obrigatório, a rejeição é mais provável se o reviewer não consegue chegar às funções principais.

O que você precisa não é apenas uma conta, mas o caminho de verificação mais curto possível.

• Preparar uma demo account
• Se 2FA for necessário, escrever os passos
• Se houver funções visíveis apenas para um papel específico, explicar isso
• Se forem necessárias sandbox data, explicar o estado inicial

A ideia básica é criar uma situação em que a pessoa de revisão consiga confirmar o valor do app pelo caminho mais curto. O ideal é oferecer uma conta de revisão read-only que permita ver as telas principais sem cadastro nem contato com suporte.

Aqui, sandbox data significa dados fictícios para revisão e verificação que não afetam usuários reais. Histórico de pedidos, posts, status de assinatura ou dados de lojas no mapa ficam muito mais fáceis de revisar quando não estão vazios.

Se o app depende de verificação por SMS ou de um sistema por convite, é mais seguro não deixar esse problema cru para o reviewer.

• Emitir uma conta de revisão com longa validade
• Se 2FA for obrigatório, anexar um código de backup ou um procedimento alternativo
• Se um estado inicial vazio esconder o valor do app, pré-carregar dados de teste
• Usar o modelo mostrado mais adiante para descrever também o caminho até a função

Categoria 2: Privacidade e permissões

4. Não existe uma URL de política de privacidade

Se o app trata dados de usuário ou de uso e não tem uma Privacy Policy URL, o risco é alto. Isso é menos um problema do binário e mais uma falha no conjunto de informações da submissão.

No mínimo, a política de privacidade deveria deixar claros estes pontos:

• Quais tipos de dados são coletados
• Para que eles são usados
• Se há compartilhamento com terceiros
• Por quanto tempo ficam armazenados
• Como o usuário pode pedir exclusão ou correção

O que costuma confundir aqui é que Privacy Policy e App Privacy / Data safety não são a mesma coisa.

• Privacy Policy: Documento público que o usuário pode ler
• App Privacy / Data safety: Autodeclaração enviada para a store

Ter apenas um dos dois não basta. O conteúdo também precisa ser coerente entre ambos.

O caminho mais curto geralmente é publicar primeiro uma página pública explicando o que você coleta, para que usa e como entrar em contato. Depois, compare isso com seu inventário de SDKs e atualize as declarações em App Store Connect / Play Console.

5. O app pede permissões que não usa

Permissões como localização, contatos, microfone ou câmera geram desconfiança se não estiverem claramente ligadas a uma função. Em muitos casos, uma biblioteca acaba introduzindo permissões desnecessárias como efeito colateral.

import { Alert } from 'react-native'
import * as Location from 'expo-location'

async function requestLocationForMap() {
  const { status } = await Location.requestForegroundPermissionsAsync()
  if (status !== 'granted') {
    Alert.alert('É necessária permissão de localização para mostrar lojas próximas no mapa')
    return
  }

  // Fluxo de exibição do mapa
}

A ideia central é solicitar apenas as permissões realmente usadas, e exatamente no momento em que elas forem necessárias.

A dica prática é não procurar apenas chamadas de permissão no código, mas revisar também as declarações introduzidas por dependências. No Android isso significa AndroidManifest.xml; no iOS, Info.plist junto com os SDKs instalados. Caso contrário, permissões involuntárias permanecem com facilidade.

6. O texto da permissão é abstrato demais

Frases como "para melhorar a experiência" não explicam para que a permissão realmente serve. O texto precisa estar ligado a uma função concreta.

Bons exemplos:

• Para mostrar lojas próximas no mapa
• Para tirar uma foto de perfil
• Para usar a câmera para escanear códigos de barras

Exemplos fracos:

• Para melhorar a experiência
• Para aumentar a conveniência
• Para melhorar a qualidade do serviço

<key>NSLocationWhenInUseUsageDescription</key>
<string>Usado para mostrar lojas próximas no mapa</string>

<key>NSCameraUsageDescription</key>
<string>Usado para tirar uma foto de perfil</string>

7. App Tracking Transparency não está bem resolvido

Se o app usa IDFA, é preciso coerência entre o diálogo ATT e a declaração App Privacy. Além disso, o app deve ser desenhado para funcionar mesmo se o usuário negar a permissão de tracking.

Aqui, ATT é o mecanismo que pede autorização antes do acesso a IDFA, muito usado em medição publicitária e attribution. Na prática, basta entender assim: se você adicionou um SDK de anúncios, se um SDK de analytics lê IDFA ou se acompanha o usuário por meio de dados de terceiros, essa área receberá mais atenção na revisão.

import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            break
        case .denied, .restricted, .notDetermined:
            break
        @unknown default:
            break
        }
    }
}

Na prática, a ordem razoável de correção é esta:

• Inventariar quais SDKs usam IDFA ou tracking
• Reavaliar se o tracking é realmente necessário
• Se não for, remover a configuração ou a dependência correspondente para tornar ATT desnecessário
• Se for, alinhar o diálogo ATT, App Privacy e a explicação dentro do app
• Confirmar que as funções principais funcionam mesmo sem autorização

Categoria 3: Pagamentos e modelo de negócio

8. O conteúdo digital é direcionado para pagamento externo

Se o app vende bens digitais ou desbloqueios de funcionalidade dentro do app, a App Store espera em princípio o uso de IAP. Direcionar o usuário para pagamento web ou compra em site externo tem alta chance de bloqueio.

A organização importante aqui é esta:

• Produtos físicos e serviços presenciais normalmente podem usar pagamento externo
• Conteúdo digital e funcionalidades premium devem usar IAP em princípio
• Se uma Reader App mostra links para criação ou gestão de conta em um site externo, ela precisa de External Link Account Entitlement
• Mesmo quando a exceção Reader App existe, as categorias e condições de implementação são bastante limitadas

Se você está em dúvida sobre usar IAP, ajuda pensar se o que está sendo vendido é valor digital consumido dentro do app.

• Exemplos mais próximos de IAP: remoção de anúncios, funcionalidades premium, moeda de jogo, leitura ilimitada de artigos, acesso ilimitado a vídeos
• Exemplos que normalmente permitem pagamento externo: produtos físicos, ride hailing, aulas presenciais, delivery de comida, reservas de hotel

Se o app já direcionava para cobrança externa e isso foi o que travou a revisão, normalmente é preciso ir em uma destas direções:

• Redesenhar a cobrança em torno de IAP
• Confirmar com rigor se o app realmente se enquadra nas condições de Reader App
• Separar bens digitais e serviços físicos e reorganizar o fluxo dentro do app

9. A explicação da assinatura é fraca

Em assinaturas, preço, ciclo de renovação, auto-renew ou caminho de cancelamento mal explicados deixam a interface frágil do ponto de vista de proteção do usuário.

No mínimo, a paywall ou a descrição da store deve deixar claros estes pontos:

• Nome do plano, duração e o que ele inclui
• O valor total cobrado aparece de forma clara; se for anual, o total anual deve ser o número mais evidente
• O ciclo de renovação e o fato de ser auto-renew ficam claros
• O preço normal após o trial gratuito fica claro
• Existem links para Terms of Service e Privacy Policy
• Existe um caminho de sign in ou restore purchases para assinantes existentes
• O método de cancelamento é compreensível

Um erro comum é destacar em letras grandes o equivalente mensal e tornar difícil de entender o valor real cobrado e as condições de renovação. Para um plano anual, é mais seguro mostrar primeiro o total anual e deixar o valor mensal apenas como informação complementar.

Para revisar uma tela de assinatura, costuma ajudar esta estrutura:

• Nome do plano
• Momento da cobrança
• Valor total cobrado
• Preço normal após o trial
• Caminho de restauração
• Termos do serviço e política de privacidade
• Tela de gestão ou caminho de cancelamento

Por exemplo, uma frase como "7 dias grátis e depois renovação automática por JPY 7.200 ao ano" reduz mal-entendidos na revisão porque deixa claro em uma única frase o que acontece depois do período gratuito.

Para tornar a tela de compra mais robusta na revisão, também ajuda responder diretamente nela às perguntas em que o usuário mais costuma se confundir:

• Qual plano está selecionado agora
• Quanto será cobrado neste momento
• Quanto custará quando o período grátis terminar
• Até quando é preciso cancelar para evitar a próxima cobrança
• Onde um assinante existente pode restaurar a compra

// O React Native sozinho não consegue abrir diretamente a system-provided UI do StoreKit,
// então este é um exemplo de fallback quando não é possível fazer bridge com uma implementação nativa de iOS.
import { Linking, Text, TouchableOpacity } from 'react-native'

function SubscriptionSettings() {
  return (
    <TouchableOpacity
      onPress={() => Linking.openURL('https://apps.apple.com/account/subscriptions')}
    >
      <Text>Gerenciar assinatura</Text>
    </TouchableOpacity>
  )
}

Se for possível implementar a parte nativa de iOS, é mais natural abrir a system-provided management UI usando showManageSubscriptions(in:), como a Apple recomenda.

10. A exceção Reader App é interpretada de forma ampla demais

A exceção Reader App parece conveniente, mas seu escopo é bastante limitado. A função principal precisa ser realmente revistas, jornais, livros, áudio, música ou vídeo, e o app deve servir para acessar conteúdos ou assinaturas comprados fora do aplicativo.

Além disso, exibir links de criação ou gestão de conta para um site externo exige External Link Account Entitlement. Apps que oferecem IAP em iOS / iPadOS / tvOS não são elegíveis para esse entitlement, então é incorreto presumir que, por ser Reader App, você pode direcionar livremente para pagamento externo.

Vídeo, música e livros são tratados de forma diferente de funcionalidades de app ou moeda de jogo. Se você envia o app sem esclarecer bem em que categoria ele se encaixa, a avaliação fica mais instável.

Se houver dúvida, é mais seguro organizar se você vende conteúdo ou funcionalidade, e onde está o fluxo de compra, e explicar isso também na ficha da store e nas notas de revisão.

Na prática, estas três perguntas Yes / No ajudam a decidir antes da submissão:

• A função principal é realmente oferecer revistas, jornais, livros, áudio, música ou vídeo?
• A estrutura é voltada para acessar conteúdo já comprado fora do app?
• A versão iOS evita oferecer IAP?

Se qualquer uma dessas três respostas ficar ambígua, é mais seguro não desenhar o app apoiando-se na exceção Reader App.

Categoria 4: Design e qualidade da experiência

11. A UI se afasta demais das expectativas da plataforma

Sistemas de navegação completamente próprios, ausência de um caminho de volta ou contrastes difíceis de ler reduzem a percepção de usabilidade. Em revisão, costuma ser melhor priorizar uma interação alinhada à plataforma do que forçar originalidade visual.

12. Parece que o app só empacota um WebView

Um app que na prática apenas mostra um site pode ser visto como uma experiência nativa com pouco valor.

Padrões de risco:

• Quase toda a tela é um WebView
• Não existem funções genuinamente nativas
• Nada funciona offline
• Não há valor específico de app, como integração com o device ou notificações

Para evitar parecer apenas um wrapper, vale deixar claro o valor da integração com o device via compartilhamento, notificações, câmera, armazenamento local, UX offline e afins.

WebView em si não é o problema. O problema é submeter um app nativo cujo conteúdo parece quase igual ao site. Se você usa WebView, convém oferecer valor nativo em pelo menos um destes pontos:

• Navegação ou tela de ajustes nativos
• Funções do device, como compartilhamento, notificações, câmera ou salvamento de arquivos
• Explicações offline ou visualização em cache
• Interação própria do app que não exista na versão web

13. Os anúncios ou o fluxo de pagamento são agressivos demais

Se a publicidade chama mais atenção que o conteúdo, se o layout provoca taps acidentais ou se há excesso de interstitials difíceis de fechar, isso prejudica tanto a revisão quanto as avaliações. A monetização pode existir, mas é preciso verificar em dispositivo real que ela não destrói a experiência.

Categoria 5: Metadados da store e informações declaradas

A revisão não olha apenas o app em si, mas também a descrição da store e as declarações. Se isso estiver desalinhado da realidade, o app pode ser bloqueado mesmo quando a implementação está correta.

Itens que vale revisar:

• Capturas de tela
• Descrição do app
• Subtítulo
• Classificação etária
• App Privacy / Data safety
• Declaração sobre presença de anúncios

O padrão especialmente perigoso é descrever funcionalidades que ainda não estão implementadas. Também é mais seguro evitar anunciar funcionalidades planejadas para o futuro.

Categoria 6: UGC e categorias de alto risco

14. Existe UGC, mas não há fluxo de moderação

Se o app lida com conteúdo gerado por usuários, não basta ter uma função de publicação. No mínimo, é recomendável oferecer estes caminhos:

• Função de denúncia
• Função de bloqueio
• Termos de uso
• Canal de contato
• Política de tratamento de conteúdo infrator

Se existe UGC mas não há mecanismos visíveis de defesa, a revisão tende a se preocupar com o risco operacional.

15. Falta responsabilidade explicativa em saúde, finanças ou infantil

Apps médicas ou de saúde, de finanças ou investimento, voltadas para crianças ou com uso contínuo de localização são revisadas com mais rigor do que categorias gerais. É melhor assumir um nível mais alto de exigência em precisão, conformidade legal, clareza sem ambiguidades e visibilidade de contato.

Especialmente nessas categorias, um texto que parece útil em marketing pode jogar contra você. Expressões sobre saúde ou investimento precisam evitar garantia de resultado, engano ou criação de expectativa excessiva.

Na prática, ajuda revisar estes ângulos:

• Saúde ou medicina: você evita afirmar de forma categórica um diagnóstico ou tratamento?
• Finanças: você evita prometer lucro ou alimentar expectativa excessiva?
• Infantil: links externos, anúncios ou fluxos de pagamento não estão agressivos demais?
• Localização contínua: a coleta permanente é realmente necessária ou existe alternativa?

Nessa categoria, importa mais verificar se você não está exagerando e se cumpre seu dever de explicação do que adicionar novas funcionalidades.

Como ler as frases de rejeição mais comuns

As mensagens de revisão costumam ser curtas e abstratas, então lê-las literalmente nem sempre deixa claro o que precisa ser corrigido. Na prática, fica mais acionável reinterpretá-las desta forma.

A chave aqui é ler o texto de revisão como se fosse uma especificação. Embora pareça abstrato, a maioria dos casos se encaixa em app inacabado, explicação insuficiente ou declaração inconsistente.

Pontos fáceis de deixar passar no Google Play

Requisitos de primeiro lançamento para uma nova personal account

Se você vai publicar no Google Play pela primeira vez, esse ponto é especialmente importante. Uma personal developer account recém-criada tem requisitos no nível da conta para poder avançar para production, independentemente do conteúdo do app.

Dois dos exemplos mais representativos são estes:

• Pelo menos 12 testers precisam participar continuamente do closed test
• A device verification no Android usando a Play Console mobile app precisa estar concluída

Isso funciona menos como um e-mail clássico de rejeição e mais como um bloqueio dentro da Play Console que impede o avanço para production. Em outras palavras, mesmo que o app esteja pronto, ele não poderá ser publicado se as condições do lado da conta não forem atendidas.

Pontos em que o primeiro lançamento mais costuma emperrar:

• Há testers suficientes, mas não se cumpre o opt-in contínuo por 14 dias
• Os testers entraram, mas o uso real ou o feedback são fracos
• O account owner ainda não concluiu a device verification
• Supõe-se que internal test seja suficiente e o requisito de closed test passa despercebido

Se for sua primeira publicação, é mais seguro resolver esses pré-requisitos bem cedo em paralelo com as verificações de implementação.

Atraso no acompanhamento do target SDK

Os requisitos do Google Play para target API level mudam continuamente. Por isso, é necessário adotar uma prática operacional: conferir na Play Console o requisito válido no momento da submissão, e não o número que era atual quando este artigo foi escrito.

O que costuma causar confusão aqui é a diferença entre targetSdkVersion e minSdkVersion.

• targetSdkVersion: Até que ponto você assume suporte para comportamentos novos do Android
• minSdkVersion: Até quão antigas versões do Android continuam suportadas

Ou seja, mesmo sem aumentar minSdkVersion, o Google Play pode bloquear a submissão apenas porque targetSdkVersion está abaixo da exigência atual.

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    defaultConfig {
        targetSdkVersion rootProject.ext.targetSdkVersion
        minSdkVersion 24
    }
}

O ponto principal é não parar na troca do número. Elevar o target SDK pode alterar o modelo de permissões, restrições em background, comportamento de notificações, foreground services, acesso a arquivos e mais. Ao atualizar, vale revisar em conjunto:

• Compatibilidade de Android Gradle Plugin e dependências
• Diferenças de comportamento dos diálogos de permissões
• Restrições sobre notificações e trabalho em segundo plano
• Testes nos principais devices-alvo

Permissões perigosas ainda ficam no manifest

Se permissões perigosas não utilizadas permanecem no manifest, só isso já cria uma carga de explicação. Em especial, vale revisar com cuidado CONTACTS, CALL_LOG, SMS e READ_PHONE_STATE.

<!-- Não declare permissões que você não usa -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.READ_CALL_LOG" /> -->

Data safety não combina com a implementação

É mais comum do que parece adicionar um Analytics SDK ou um SDK de anúncios e deixar a declaração da Console desatualizada. Toda mudança de SDK deveria incluir Data safety como parte obrigatória da atualização.

Data safety é a seção do Google Play em que você declara quais dados o app coleta ou compartilha e para que eles são usados. App Privacy do lado da Apple segue uma lógica parecida, e qualquer desencontro com a implementação reduz a confiança.

A forma mais segura de resolver isso é não preencher de memória, mas fazer um inventário:

• Listar os SDKs presentes
• Confirmar que tipo de dado cada um manipula
• Listar também os dados enviados pelas suas próprias APIs
• Comparar tudo isso com o que foi declarado em Play Console / App Store Connect
• Se algo mudou, atualizar também a política de privacidade

Pedir permissões no momento em que elas são usadas

Um desenho que dispara vários diálogos de permissão logo após o lançamento costuma deixar uma impressão ruim tanto no usuário quanto no reviewer.

A melhor política é esta:

• Pedir a permissão quando o usuário chega à função
• Mostrar logo antes uma breve explicação pre-permission
• Preparar um caminho alternativo para o caso de deny

Isso ajuda não só na revisão, mas também a melhorar a taxa de aceitação.

O que escrever nas notas de revisão

O campo de notas de revisão costuma ser subestimado, mas é um espaço importante para reduzir a confusão do reviewer. Ele tem bastante efeito em apps com login obrigatório, em apps que usam permissões e em apps que dependem de devices externos.

Conteúdo útil para incluir:

• Dados da demo account
• Passos para chegar às funções principais
• Explicação de qual tela usa cada permissão
• Observações se 2FA ou um papel específico forem necessários
• Observações se houver dependência de servidor ou device externo

Exemplo curto de modelo:

Conta de revisão:
Email: reviewer-demo@example.com
Password: xxxxxxxx

Fluxo principal de teste:
1. Fazer login com a conta de revisão
2. Abrir a aba Map para testar a permissão de localização
3. Abrir Settings > Subscription para verificar a orientação de cancelamento

Diretriz de resposta após uma rejeição

Após uma rejeição, o mais importante não é responder de forma emocional, mas classificar corretamente o problema apontado.

A ordem básica de trabalho é esta:

1. Reler a mensagem exatamente como foi escrita
2. Confirmar as condições de reprodução
3. Classificá-la como defeito de implementação, explicação insuficiente ou erro de declaração
4. Acrescentar capturas ou vídeo se necessário

Mesmo quando a decisão parece errada, normalmente é mais rápido completar a explicação primeiro. Na prática, vale tratar um appeal como último recurso.

Na resposta em si, costuma ser mais eficaz escrever de forma breve e clara o que mudou do que produzir uma longa defesa.

Obrigado pela revisão.

Identificamos o problema como [implementation / metadata / clarification].
Fizemos as seguintes alterações:
1. Corrigimos [issue]
2. Atualizamos [metadata or review notes]
3. Adicionamos [account / explanation / screenshot]

Como verificar:
1. Fazer login com a conta de revisão
2. Abrir [screen name]
3. Tocar em [action]

Se necessário, podemos fornecer capturas adicionais ou uma gravação de tela.

Se você reduzir ao essencial, bastam três pontos: causa, o que foi alterado e como verificar. Quanto mais o ciclo de revisão se prolonga dentro de um time, mais esses três pontos tendem a se misturar e dificultar a comunicação.

O que fazer nas 48 horas antes da submissão

Perto do release, a tentação de colocar mais uma funcionalidade é grande. Mas, se o objetivo é melhorar a taxa de aprovação, normalmente é mais eficaz usar a reta final para verificar do que para implementar.

48 horas antes

• Revisar a descrição da store, as capturas de tela, a classificação etária e Data safety / App Privacy
• Inventariar os SDKs em uso e a lista de permissões
• Preparar a conta do reviewer e as notas de revisão

24 horas antes

• Verificar o arranque no último iPhone OS, em uma versão anterior de iOS e em vários devices Android
• Testar modo avião, rede lenta e estado de instalação limpa
• Percorrer ponta a ponta pagamentos, login, pedidos de permissão e fluxo de exclusão de conta

6 horas antes

• Fazer uma última conferência para ver se as capturas ainda correspondem ao app real
• Confirmar que não existe diferença entre as declarações da store e a configuração do SDK
• Completar as notas de revisão com o caminho até as funções principais e qualquer contexto necessário

Só repetir esse fluxo de 48 horas em cada release já costuma facilitar bastante a redução da taxa de rejeição.

Operação para evitar recorrência

Mesmo depois de uma aprovação, os mesmos problemas tendem a voltar quando novas funcionalidades entram ou quando os SDKs mudam. Tanto em desenvolvimento individual quanto em equipe, as práticas abaixo reduzem o risco:

• Se você adiciona um SDK, trate permissions, Data safety e App Privacy como um pacote único de atualização
• Limite a descrição da store às funcionalidades realmente implementadas
• Ao adicionar uma nova permissão, revise no PR a tela de uso e o texto explicativo juntos
• Transforme o checklist pré-release em issue ou modelo reutilizável
• Registre internamente o texto da rejeição e a resposta adotada para reaproveitar isso em futuras notas de revisão

O maior ganho de longo prazo é deixar de tratar a resposta à revisão como algo que precisa ser inventado do zero toda vez.

Checklist antes da submissão

Fica mais fácil encontrar lacunas quando o checklist é separado em formatos que possam ser usados diretamente para cada store. Até os pontos em comum aparecem incluídos em cada tabela.

Checklist antes da submissão à App Store

Checklist antes da submissão ao Google Play

Resumo

O que mais costuma travar a revisão de um app não são bugs simples, mas desalinhamentos entre implementação e explicação e falta de preparação operacional.

Os quatro pontos mais importantes são estes:

• O reviewer consegue verificar as funções principais sem se confundir
• As razões para permissões e coleta de dados são explicadas de forma concreta
• As regras de cobrança e as declarações da store estão corretamente alinhadas
• Os metadados da store correspondem à implementação real

Quanto mais perto do release, maior a tentação de colocar mais uma funcionalidade. Mas, se o objetivo é melhorar a taxa de aprovação, costuma ser mais eficaz gastar o último dia esgotando o checklist.

Links de referência

• App Store Review Guidelines
• Auto-renewable subscriptions
• Google Play Policy Center
• Human Interface Guidelines
• In-App Purchase (Human Interface Guidelines)
• Distributing reader apps with a link to your website
• App testing requirements for new personal developer accounts
• Device verification requirements for new developer accounts
• Target API level requirements for Google Play apps
• App Tracking Transparency