Guideline 4.8 Login Services: login com Apple é obrigatório?

A guideline 4.8 se aplica assim que o seu app usa Google, Facebook ou outro login de terceiros para criar a conta principal. Nesse caso, ela exige outra opção de login, equivalente, que limite os dados ao nome e ao e-mail, permita esconder o e-mail e não rastreie o usuário para publicidade sem consentimento. Desde janeiro de 2024, essa opção não precisa mais ser o "Sign in with Apple", mas é a que a própria Apple cita nas mensagens de rejeição.

Nos meus apps, Solys e Nolera oferecem Apple, Google e e-mail. Este guia parte do texto atual da Apple, depois mostra como eu adiciono o login com Apple num app Expo conectado ao Supabase, e o que isso muda na exclusão de conta. Para a visão geral dos motivos de rejeição, leia por que a Apple rejeita um app.

O que diz a guideline 4.8 Login Services?

A 4.8 fica na seção 4, "Design", das App Review Guidelines. Ela vale para apps que usam "a third-party or social login service" para criar ou autenticar a conta principal: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon ou WeChat. Esses apps também precisam oferecer, "as an equivalent option", outro serviço de login que cumpra três condições.

Condição da Apple	Em resumo
Dados limitados	Nome e e-mail, nada mais
E-mail privado possível	O usuário pode escondê-lo
Sem publicidade sem consentimento	Nenhum rastreamento publicitário sem consentimento

O texto também define a conta principal: aquela que a pessoa cria no seu app para se identificar, fazer login e acessar suas funções. Por essa definição, um botão do Google que só serve para importar um arquivo não cria conta principal. A 4.8 mira a tela por onde se entra no seu app.

O que mudou em janeiro de 2024

Antes de 2024, a regra exigia o "Sign in with Apple" nos apps que usavam login de terceiros para a conta principal. Em 25 de janeiro de 2024, a Apple flexibilizou esse ponto: você pode oferecer o login com Apple ou um serviço equivalente que proteja a privacidade. Muita página ainda diz o contrário. A documentação do Expo ainda escreve que um app com login de terceiros precisa oferecer Apple.

Na prática, a mensagem de rejeição 4.8 publicada nos fóruns de desenvolvedores da Apple termina assim: "Note that Sign in with Apple meets the requirements specified in guideline 4.8". A Apple não cita nenhum outro serviço compatível. Para não ficar tentando adivinhar o que o revisor quer, eu adiciono o login com Apple.

As cinco exceções previstas no texto

A Apple lista cinco casos em que nenhum outro login é exigido:

1. Seu app usa só o seu próprio sistema de conta, por exemplo e-mail com senha ou um código enviado por e-mail.
2. Seu app é uma loja de apps alternativa, ou é distribuído por uma delas, com um login próprio dessa loja.
3. Seu app é educacional, corporativo ou profissional, e exige uma conta de escola ou empresa já existente.
4. Seu app usa um sistema de identidade eletrônica apoiado por um governo ou por um setor.
5. Seu app é cliente de um serviço de terceiros específico: a pessoa entra no e-mail ou na rede social dela para acessar o próprio conteúdo.

Antes mesmo dessas exceções, faça uma pergunta: seu app precisa de conta? Se não precisar, a guideline 5.1.1(v) pede que ele possa ser usado sem login, como explico no guia da guideline 5.1.1.

Sua tela de login	A 4.8 se aplica?
Nenhuma conta	Não
Só e-mail ou código	Não
Só Google	Sim
Google e e-mail	Sim, a princípio
Google e Apple	Sim, e em conformidade
Conta de escola já existente	Não
Google para importar	Não, não há conta

Adicionar o "Sign in with Apple" num app Expo

1. Instalar o módulo e declarar a capability

npx expo install expo-apple-authentication

A documentação do Expo pede, em seguida, para ativar a capability na configuração do app:

{
  "expo": {
    "ios": {
      "usesAppleSignIn": true,
      "infoPlist": { "CFBundleAllowMixedLocalizations": true }
    }
  }
}

A segunda linha mostra o botão no idioma do iPhone. Com o EAS Build, a capability é ativada no identificador do seu app na hora do build. É uma configuração nativa: ela vai com um build novo, nunca com uma atualização remota.

Uma armadilha que encontrei relendo o código inicial dos meus kits: essa capability exige assinatura, mesmo para rodar o app no simulador. Num Mac sem certificado "Apple Development", a compilação local falhava com "No code signing certificates are available to use". A correção: só ativar o login com Apple quando o servidor de autenticação estiver configurado.

2. Mostrar o botão oficial, tão visível quanto o do Google

As regras de design da Apple são claras: o botão da Apple não pode ser menor que os outros botões de login, e não pode ser preciso rolar a tela para vê-lo. O componente do Expo desenha o botão oficial, com um título autorizado pela Apple.

import * as AppleAuthentication from "expo-apple-authentication";
import { useEffect, useState } from "react";

export function BoutonApple({ onPress }: { onPress: () => void }) {
  const [disponible, setDisponible] = useState(false);

  useEffect(() => {
    AppleAuthentication.isAvailableAsync().then(setDisponible);
  }, []);

  // Android e web: sem login com Apple, sem botão.
  if (!disponible) return null;

  return (
    <AppleAuthentication.AppleAuthenticationButton
      buttonType={AppleAuthentication.AppleAuthenticationButtonType.CONTINUE}
      buttonStyle={AppleAuthentication.AppleAuthenticationButtonStyle.BLACK}
      cornerRadius={12}
      style={{ width: "100%", height: 50 }}
      onPress={onPress}
    />
  );
}

O Expo avisa que o botão não aparece sem largura e altura. A cor e o arredondamento passam por buttonStyle e cornerRadius, não pelo style.

3. Abrir a sessão no Supabase

import * as AppleAuthentication from "expo-apple-authentication";
import { supabase } from "./supabase";

export async function connexionApple(): Promise<"ok" | "annule"> {
  try {
    const credential = await AppleAuthentication.signInAsync({
      requestedScopes: [
        AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
        AppleAuthentication.AppleAuthenticationScope.EMAIL,
      ],
    });
    if (!credential.identityToken) throw new Error("Token da Apple ausente");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // O primeiro nome só chega na primeira autorização: guardamos na hora.
    const prenom = credential.fullName?.givenName;
    if (prenom) await supabase.auth.updateUser({ data: { prenom } });
    return "ok";
  } catch (e) {
    if ((e as { code?: string }).code === "ERR_REQUEST_CANCELED")
      return "annule";
    throw e;
  }
}

Quatro detalhes importam, tirados da documentação do Supabase, da do Expo e das regras de design da Apple:

• No Supabase, declare o seu bundle identifier nos Client IDs do provedor Apple. Um app só nativo não precisa de chave secreta para fazer login. Adicione host.exp.Exponent se você testa no Expo Go.
• O nome e o e-mail só chegam uma vez. A Apple não os envia mais nos logins seguintes: salve logo no primeiro retorno.
• O e-mail pode ser um endereço de retransmissão. A Apple recomenda não pedir um endereço pessoal depois.
• Um cancelamento não é um erro. No Nolera, fechar a janela da Apple não dispara nenhuma mensagem vermelha: é um gesto voluntário.

Um caso real no Solys, em agosto de 2026: os botões Apple e Google estavam no app, mas nenhum dos dois provedores estava ativado no Supabase. O código estava certo, a correção foi feita no servidor, sem build novo. Um botão da Apple que falha na frente do revisor é uma rejeição 2.1 no lugar de uma rejeição 4.8. O detalhe está no guia da guideline 2.1.

4. Testar num iPhone de verdade

O Expo avisa que o simulador só permite um teste limitado, e que as credenciais recebidas no Expo Go são diferentes das do app publicado. Teste o login, o logout e um novo login num iPhone de verdade, com um build do TestFlight.

Login com Apple e exclusão de conta

A guideline 5.1.1(v) exige que uma conta criada no app possa ser excluída pelo app. Com o login com Apple, a página da Apple sobre exclusão de conta acrescenta uma etapa: usar a API REST do Sign in with Apple para revogar os tokens da pessoa.

Essa revogação exige duas coisas: um token da pessoa, obtido validando um código de autorização, e um segredo assinado com a sua chave privada do Sign in with Apple. Mesmo que o login nativo dispense chave secreta, a revogação exige uma, e ela fica no seu servidor. O porquê está em chave de API secreta num app Expo.

No Nolera, na hora de excluir a conta, o app pede de novo o login com Apple para obter um código de autorização novo. Ele envia esse código para uma função no servidor, que o troca junto à Apple e depois revoga o token. Se a pessoa cancelar, uma mensagem clara avisa e nada é excluído. O resto do fluxo, incluindo dados, assinatura e testes, está em exclusão de conta no iOS.

O que responder à Apple depois de uma rejeição 4.8

A mensagem da Apple oferece duas saídas. Ou você adiciona uma opção equivalente. Ou o seu app já tem uma: você responde no App Store Connect, diz qual é e por que ela cumpre as três condições. A Apple também sugere atualizar as capturas de tela que mostram a tela de login. O procedimento para responder ao App Review é o mesmo das outras regras.

Aqui vai um modelo em inglês, para adaptar (troque o número do build):

Hello,

Thank you for your review.

Build X adds Sign in with Apple as an equivalent login option.
It appears on the same screen as Google Sign-In, with the same
size, and is visible without scrolling.

How to verify: launch the app, open the sign-in screen and
tap "Continue with Apple".

We also updated the screenshots that show the sign-in screen.

Best regards,

O checklist da 4.8 antes do envio

• Você sabe se o seu app precisa de conta. Se não precisar, ele funciona sem login.
• Se Google, Facebook ou X criam a conta, o login com Apple está na mesma tela.
• O botão da Apple é o oficial, do mesmo tamanho dos outros, visível sem rolar.
• O provedor Apple está ativado no servidor, com o seu bundle identifier.
• Um cancelamento volta para a tela de login, sem mensagem de erro.
• O nome e o e-mail são salvos já no primeiro login.
• A exclusão de conta revoga o token da Apple, a partir do seu servidor.
• Tudo foi testado num iPhone de verdade, com uma conta Apple que nunca fez login no app.
• Suas capturas de tela mostram a tela de login como ela está no build enviado.

Corrigir a rejeição antes de reenviar o app

Se o seu app acabou de ser rejeitado na 4.8, o Apple Review Kit reúne o que eu verifico antes de cada envio, com duas skills que revisam o seu projeto no Claude Code e preparam a sua resposta se a Apple rejeitar. Para um olhar humano, agende uma hora comigo: a gente lê a mensagem junto e olha a sua tela de login. O passo a passo completo depois de uma rejeição está na página app rejeitado pela Apple.

Se você está preparando o seu primeiro lançamento, faça o seu diagnóstico gratuito: ele diz qual etapa atacar primeiro e te envia o meu checklist anti-rejeição da Apple.

Ninguém pode garantir que a Apple vai aprovar o seu app. Colocar o login com Apple no lugar certo pelo menos tira esse motivo da lista.

Perguntas frequentes

O login com Apple é obrigatório no iOS?

Não em todos os casos. Ele só é exigido se o seu app oferece um login de terceiros, como Google ou Facebook, para criar a conta principal. Desde janeiro de 2024, outro serviço equivalente pode substituí-lo, mas a Apple só cita o login com Apple como compatível.

O que significa "Guideline 4.8 - Design - Login Services"?

É o título da rejeição na mensagem da Apple. Significa que o seu app oferece um login de terceiros sem uma opção equivalente que limite os dados ao nome e ao e-mail, permita esconder o e-mail e não seja usada para publicidade sem consentimento.

Meu cadastro por e-mail basta ao lado do Google?

Não é garantido. O texto pede um serviço que permita manter o e-mail privado, e um formulário comum pede o e-mail. A Apple não publicou posição sobre esse caso, e a mensagem de rejeição só cita o login com Apple. Eu não correria esse risco.

Preciso oferecer o login com Apple no Android?

Não. A 4.8 é uma regra da App Store, e o módulo do Expo só funciona no iOS. No Android, isAvailableAsync() retorna falso: o botão da Apple não aparece, e o Google pode ficar sozinho.

Preciso de um build novo depois de uma rejeição 4.8?

Sim, na maioria dos casos. O login com Apple exige uma capability nativa, ativada na hora do build. Uma atualização remota não consegue adicioná-la. Única exceção: o seu app já tinha uma opção compatível, e basta explicar isso à Apple na sua resposta.