Guideline 4.8 Login Services: serve Sign in with Apple?

La guideline 4.8 si applica non appena la tua app usa Google, Facebook o un altro login di terze parti per creare l'account principale. In quel caso impone un'altra opzione di accesso, equivalente, che limita i dati a nome ed email, permette di nascondere la propria email e non traccia l'utente a fini pubblicitari senza il suo consenso. Da gennaio 2024 questa opzione non deve più essere per forza "Sign in with Apple", ma è quella che Apple stessa cita nei suoi messaggi di rifiuto.

Tra le mie app, Solys e Nolera offrono Apple, Google ed email. Questa guida parte dal testo attuale di Apple, poi ti mostra come aggiungo il login con Apple in un'app Expo collegata a Supabase, e cosa cambia per l'eliminazione dell'account. Per una panoramica dei motivi di rifiuto, leggi invece perché Apple rifiuta un'app.

Cosa dice la guideline 4.8 Login Services?

La 4.8 si trova nella sezione 4, "Design", delle App Review Guidelines. Riguarda le app che usano "a third-party or social login service" per creare o autenticare l'account principale: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon o WeChat. Queste app devono anche offrire, "as an equivalent option", un altro servizio di login che rispetti tre condizioni.

Condizione di Apple	In parole semplici
Dati limitati	Nome ed email, niente di più
Email privata possibile	L'utente può nasconderla
Niente pubblicità senza consenso	Nessun tracciamento pubblicitario senza consenso

Il testo definisce anche l'account principale: quello che la persona crea nella tua app per identificarsi, accedere e usare le tue funzioni. Secondo questa definizione, un pulsante Google che serve solo a importare un file non crea un account principale. La 4.8 riguarda la schermata da cui si entra nella tua app.

Cosa è cambiato a gennaio 2024

Prima del 2024, la regola imponeva "Sign in with Apple" alle app che usavano un login di terze parti per l'account principale. Il 25 gennaio 2024 Apple ha ammorbidito questo punto: puoi offrire il login con Apple, oppure un servizio equivalente che protegge la privacy. Molte pagine dicono ancora il contrario. La documentazione di Expo scrive ancora che un'app con login di terze parti deve offrire Apple.

In pratica, il messaggio di rifiuto 4.8 pubblicato sui forum per sviluppatori di Apple si chiude così: "Note that Sign in with Apple meets the requirements specified in guideline 4.8". Apple non nomina nessun altro servizio conforme. Per non giocare agli indovinelli con il reviewer, io aggiungo il login con Apple.

Le cinque eccezioni previste dal testo

Apple elenca cinque casi in cui non serve nessun altro login:

1. La tua app usa solo il tuo sistema di account, per esempio email e password o un codice inviato via email.
2. La tua app è un app store alternativo, o è distribuita da uno di questi, con un login specifico di quello store.
3. La tua app è educativa, aziendale o professionale, e richiede un account scolastico o aziendale già esistente.
4. La tua app usa un sistema di identità elettronica sostenuto da uno Stato o da un settore.
5. La tua app è il client di un servizio di terze parti preciso: la persona accede alla sua email o al suo social network per vedere i propri contenuti.

Prima ancora di queste eccezioni, chiediti: la tua app ha bisogno di un account? Se non ne ha bisogno, la guideline 5.1.1(v) chiede di lasciarla utilizzabile senza login, come spiego nella guida alla guideline 5.1.1.

La tua schermata di login	Si applica la 4.8?
Nessun account	No
Solo email o codice	No
Solo Google	Sì
Google ed email	Sì, in linea di massima
Google e Apple	Sì, e conforme
Account scolastico esistente	No
Google per un import	No, nessun account

Aggiungere "Sign in with Apple" in un'app Expo

1. Installare il modulo e dichiarare la capability

npx expo install expo-apple-authentication

La documentazione di Expo chiede poi di attivare la capability nella configurazione dell'app:

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

La seconda riga mostra il pulsante nella lingua dell'iPhone. Con EAS Build, la capability viene attivata sul tuo identificativo dell'app al momento della build. È un'impostazione nativa: arriva con una nuova build, mai con un aggiornamento remoto.

Una trappola che ho trovato rileggendo il codice di partenza dei miei kit: questa capability richiede una firma, anche solo per avviare l'app sul simulatore. Su un Mac senza certificato "Apple Development", la compilazione locale falliva con "No code signing certificates are available to use". La soluzione: attivare il login con Apple solo quando il server di autenticazione è configurato.

2. Mostrare il pulsante ufficiale, visibile quanto Google

Le linee guida di design di Apple sono chiare: il pulsante Apple non deve essere più piccolo degli altri pulsanti di login, e non si deve scorrere la schermata per vederlo. Il componente di Expo disegna il pulsante ufficiale, con un titolo autorizzato da 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: niente login con Apple, niente pulsante.
  if (!disponible) return null;

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

Expo precisa che il pulsante non compare senza larghezza e altezza. Il colore e l'arrotondamento passano da buttonStyle e cornerRadius, non dallo style.

3. Aprire la sessione in 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 Apple mancante");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // Il nome arriva solo alla prima autorizzazione: lo salviamo subito.
    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;
  }
}

Contano quattro dettagli, presi dalla documentazione di Supabase, da quella di Expo e dalle linee guida di design di Apple:

• In Supabase, dichiara il tuo bundle identifier nei Client IDs del provider Apple. Un'app solo nativa non ha bisogno di una chiave segreta per il login. Aggiungi host.exp.Exponent se fai i test in Expo Go.
• Nome ed email arrivano una sola volta. Apple non li rimanda più agli accessi successivi: salvali al primo ritorno.
• L'email può essere un indirizzo relay. Apple consiglia di non chiedere poi un indirizzo personale.
• Un annullamento non è un errore. Su Nolera, chiudere il foglio di Apple non fa comparire nessun messaggio rosso: è un gesto voluto.

Un caso reale su Solys, ad agosto 2026: i pulsanti Apple e Google erano nell'app, ma nessuno dei due provider era attivato in Supabase. Il codice era corretto, la correzione è stata fatta lato server, senza nuova build. Un pulsante Apple che fallisce davanti al reviewer è un rifiuto 2.1 al posto di un rifiuto 4.8. I dettagli sono nella guida alla guideline 2.1.

4. Testare su un iPhone vero

Expo avverte che il simulatore permette solo un test limitato, e che gli identificativi ricevuti in Expo Go sono diversi da quelli dell'app pubblicata. Testa login, logout e un nuovo login su un iPhone vero, con una build TestFlight.

Login con Apple ed eliminazione dell'account

La guideline 5.1.1(v) chiede che un account creato nell'app si possa eliminare dall'app. Con il login con Apple, la pagina di Apple sull'eliminazione dell'account aggiunge un passaggio: usare la REST API di Sign in with Apple per revocare i token della persona.

Questa revoca richiede due cose: un token della persona, che si ottiene validando un authorization code, e un secret firmato con la tua chiave privata Sign in with Apple. Anche se il login nativo non ha bisogno di una chiave segreta, la revoca la richiede, e deve restare sul tuo server. Il perché è in chiave API segreta in un'app Expo.

Su Nolera, al momento di eliminare l'account, l'app richiede un nuovo login con Apple per ottenere un authorization code fresco. Lo invia a una funzione server, che lo scambia con Apple e poi revoca il token. Se la persona annulla, un messaggio chiaro lo dice e non viene eliminato nulla. Il resto del percorso, dati, abbonamento e test compresi, è in eliminazione dell'account iOS.

Cosa rispondere ad Apple dopo un rifiuto 4.8

Il messaggio di Apple propone due vie d'uscita. O aggiungi un'opzione equivalente. O la tua app ne ha già una: rispondi in App Store Connect, dici quale e perché rispetta le tre condizioni. Apple suggerisce anche di aggiornare gli screenshot che mostrano la schermata di login. La procedura per rispondere ad App Review è la stessa delle altre regole.

Ecco un modello in inglese, da adattare (sostituisci il numero di 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,

La checklist 4.8 prima dell'invio

• Sai se la tua app ha bisogno di un account. Altrimenti, si usa senza login.
• Se Google, Facebook o X creano l'account, il login con Apple è sulla stessa schermata.
• Il pulsante Apple è quello ufficiale, grande quanto gli altri, visibile senza scorrere.
• Il provider Apple è attivato lato server, con il tuo bundle identifier.
• Un annullamento riporta alla schermata di login, senza messaggio di errore.
• Nome ed email vengono salvati al primo accesso.
• L'eliminazione dell'account revoca il token Apple, dal tuo server.
• Tutto è testato su un iPhone vero, con un account Apple che non ha mai fatto accesso all'app.
• I tuoi screenshot mostrano la schermata di login così com'è nella build inviata.

Correggere il rifiuto prima di inviare di nuovo l'app

Se la tua app è appena stata rifiutata per la 4.8, l'Apple Review Kit raccoglie quello che controllo prima di ogni invio, con due skill che rileggono il tuo progetto in Claude Code e preparano la tua risposta se Apple rifiuta. Se vuoi un occhio umano, prenota un'ora con me: leggiamo insieme il messaggio e guardiamo la tua schermata di login. Il percorso completo dopo un rifiuto è nella pagina app rifiutata da Apple.

Se stai preparando la tua prima uscita, fai la tua diagnosi gratuita: ti dice da quale passaggio partire e ti invia la mia checklist anti-rifiuto Apple.

Nessuno può garantire che Apple accetterà la tua app. Aggiungere il login con Apple nel posto giusto toglie almeno questo motivo dalla lista.

Domande frequenti

Il login con Apple è obbligatorio su iOS?

No, non in tutti i casi. È richiesto solo se la tua app offre un login di terze parti, come Google o Facebook, per creare l'account principale. Da gennaio 2024 può sostituirlo un altro servizio equivalente, ma Apple cita come conforme solo il login con Apple.

Cosa vuol dire "Guideline 4.8 - Design - Login Services"?

È il titolo del rifiuto nel messaggio di Apple. Significa che la tua app offre un login di terze parti senza un'opzione equivalente che limiti i dati a nome ed email, permetta di nascondere l'email e non serva alla pubblicità senza consenso.

La mia registrazione via email basta accanto a Google?

Non è garantito. Il testo chiede un servizio che permetta di tenere privata la propria email, mentre un modulo classico la chiede. Apple non ha pubblicato una posizione su questo caso, e il suo messaggio di rifiuto cita solo il login con Apple. Io non correrei il rischio.

Devo offrire il login con Apple su Android?

No. La 4.8 è una regola dell'App Store, e il modulo di Expo funziona solo su iOS. Su Android, isAvailableAsync() restituisce false: il pulsante Apple non compare, e Google può restare da solo.

Serve una nuova build dopo un rifiuto 4.8?

Sì, nella maggior parte dei casi. Il login con Apple richiede una capability nativa, attivata al momento della build. Un aggiornamento remoto non può aggiungerla. Unica eccezione: la tua app aveva già un'opzione conforme, e basta spiegarlo ad Apple nella tua risposta.