Guideline 4.8 Login Services : faut-il la connexion Apple ?
Par Mehdi Azizi
Publié le , 9 min
Guideline 4.8 : si ton app propose Google ou Facebook, ajoute une connexion qui protège l'e-mail, comme Apple. Exceptions, code Expo et suppression de compte.
La guideline 4.8 s'applique dès que ton app utilise Google, Facebook ou une autre connexion tierce pour créer le compte principal. Elle impose alors une autre option de connexion, équivalente, qui limite les données au nom et à l'e-mail, permet de cacher son e-mail et ne suit pas l'utilisateur pour la publicité sans son accord. Depuis janvier 2024, cette option n'est plus forcément « Se connecter avec Apple », mais c'est celle qu'Apple cite lui‑même dans ses messages de refus.
Sur mes apps, Solys et Nolera proposent Apple, Google et l'e-mail. Ce guide part du texte actuel d'Apple, puis montre comment j'ajoute la connexion Apple dans une app Expo reliée à Supabase, et ce qu'elle change pour la suppression de compte. Pour la vue d'ensemble des motifs de refus, lis plutôt pourquoi Apple refuse une app.
Que dit la guideline 4.8 Login Services ?
La 4.8 se trouve dans la section 4, « Design », des App Review Guidelines. Elle vise les apps qui utilisent « a third-party or social login service » pour créer ou authentifier le compte principal : Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon ou WeChat. Ces apps doivent aussi proposer, « as an equivalent option », un autre service de connexion qui remplit trois conditions.
| Condition d'Apple | En clair |
|---|---|
| Données limitées | Nom et e-mail, rien de plus |
| E-mail privé possible | L'utilisateur peut le cacher |
| Pas de pub sans accord | Aucun suivi publicitaire sans accord |
Le texte définit aussi le compte principal : celui que la personne crée dans ton app pour s'identifier, se connecter et accéder à tes fonctions. D'après cette définition, un bouton Google qui sert seulement à importer un fichier ne crée pas de compte principal. La 4.8 vise l'écran où l'on entre dans ton app.
Ce qui a changé en janvier 2024
Avant 2024, la règle imposait « Se connecter avec Apple » aux apps qui utilisaient une connexion tierce pour le compte principal. Le 25 janvier 2024, Apple a assoupli ce point : tu peux proposer la connexion Apple, ou un service équivalent qui protège la vie privée. Beaucoup de pages disent encore le contraire. La documentation d'Expo écrit toujours qu'une app avec une connexion tierce doit proposer Apple.
En pratique, le message de refus 4.8 publié sur les forums développeurs d'Apple se termine ainsi : « Note that Sign in with Apple meets the requirements specified in guideline 4.8 ». Apple ne nomme aucun autre service conforme. Pour ne pas jouer aux devinettes avec le reviewer, j'ajoute la connexion Apple.
Les cinq exceptions prévues par le texte
Apple liste cinq cas où aucune autre connexion n'est exigée :
- Ton app n'utilise que ton propre système de compte, par exemple un e-mail avec mot de passe ou un code envoyé par e-mail.
- Ton app est une boutique d'apps alternative, ou distribuée par l'une d'elles, avec une connexion propre à cette boutique.
- Ton app est éducative, d'entreprise ou professionnelle, et exige un compte d'école ou d'entreprise existant.
- Ton app utilise un système d'identité électronique soutenu par un État ou un secteur.
- Ton app est le client d'un service tiers précis : la personne se connecte à sa messagerie ou à son réseau social pour accéder à son propre contenu.
Avant même ces exceptions, pose-toi une question : ton app a-t-elle besoin d'un compte ? Si ce n'est pas le cas, la guideline 5.1.1(v) demande de la laisser utilisable sans connexion, comme je l'explique dans le guide de la guideline 5.1.1.
| Ton écran de connexion | La 4.8 s'applique ? |
|---|---|
| Aucun compte | Non |
| E-mail ou code seulement | Non |
| Google seul | Oui |
| Google et e-mail | Oui, a priori |
| Google et Apple | Oui, et conforme |
| Compte d'école existant | Non |
| Google pour un import | Non, pas de compte |
Ajouter « Se connecter avec Apple » dans une app Expo
1. Installer le module et déclarer la capacité
npx expo install expo-apple-authentication
La documentation d'Expo demande ensuite d'activer la capacité dans la configuration de l'app :
{
"expo": {
"ios": {
"usesAppleSignIn": true,
"infoPlist": { "CFBundleAllowMixedLocalizations": true }
}
}
}
La seconde ligne affiche le bouton dans la langue de l'iPhone. Avec EAS Build, la capacité est activée sur ton identifiant d'app au moment du build. C'est un réglage natif : il part avec un nouveau build, jamais avec une mise à jour à distance.
Un piège que j'ai trouvé en relisant le code de départ de mes kits : cette capacité impose une signature, même pour lancer l'app sur le simulateur. Sur un Mac sans certificat « Apple Development », la compilation locale échouait avec « No code signing certificates are available to use ». La correction : n'activer la connexion Apple que lorsque le serveur d'authentification est configuré.
2. Afficher le bouton officiel, aussi visible que Google
Les règles de design d'Apple sont nettes : le bouton Apple ne doit pas être plus petit que les autres boutons de connexion, et on ne doit pas avoir à faire défiler l'écran pour le voir. Le composant d'Expo dessine le bouton officiel, avec un titre autorisé par 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 et web : pas de connexion Apple, pas de bouton.
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 précise que le bouton n'apparaît pas sans largeur ni hauteur. La couleur et l'arrondi passent par buttonStyle et cornerRadius, pas par le style.
3. Ouvrir la session dans 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("Jeton Apple absent");
const { error } = await supabase.auth.signInWithIdToken({
provider: "apple",
token: credential.identityToken,
});
if (error) throw error;
// Le prénom n'arrive qu'à la première autorisation : on le garde tout de suite.
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;
}
}
Quatre détails comptent, tirés de la documentation Supabase, de celle d'Expo et des règles de design d'Apple :
- Dans Supabase, déclare ton identifiant de bundle dans les Client IDs du fournisseur Apple. Une app uniquement native n'a pas besoin de clé secrète pour se connecter. Ajoute
host.exp.Exponentsi tu testes dans Expo Go. - Le prénom et l'e-mail n'arrivent qu'une fois. Apple ne les renvoie plus aux connexions suivantes : enregistre-les dès le premier retour.
- L'e-mail peut être une adresse relais. Apple recommande de ne pas redemander une adresse personnelle ensuite.
- Une annulation n'est pas une erreur. Sur Nolera, fermer la feuille Apple ne déclenche aucun message rouge : c'est un geste volontaire.
Un cas vécu sur Solys, en août 2026 : les boutons Apple et Google étaient dans l'app, mais aucun des deux fournisseurs n'était activé dans Supabase. Le code était bon, la correction s'est faite côté serveur, sans nouveau build. Un bouton Apple qui échoue devant le reviewer, c'est un refus 2.1 à la place d'un refus 4.8. Le détail est dans le guide de la guideline 2.1.
4. Tester sur un vrai iPhone
Expo prévient que le simulateur ne permet qu'un test limité, et que les identifiants reçus dans Expo Go diffèrent de ceux de l'app publiée. Teste la connexion, la déconnexion puis une reconnexion sur un vrai iPhone, avec une build TestFlight.
Connexion Apple et suppression de compte
La guideline 5.1.1(v) demande qu'un compte créé dans l'app puisse être supprimé depuis l'app. Avec la connexion Apple, la page d'Apple sur la suppression de compte ajoute une étape : utiliser l'API REST de Sign in with Apple pour révoquer les jetons de la personne.
Cette révocation demande deux choses : un jeton de la personne, que l'on obtient en validant un code d'autorisation, et un secret signé avec ta clé privée Sign in with Apple. Même si la connexion native se passe de clé secrète, la révocation en exige une, et elle reste sur ton serveur. Le pourquoi est dans clé API secrète dans une app Expo.
Sur Nolera, au moment de supprimer le compte, l'app redemande une connexion Apple pour obtenir un code d'autorisation frais. Elle l'envoie à une fonction serveur, qui l'échange auprès d'Apple puis révoque le jeton. Si la personne annule, un message clair le dit et rien n'est supprimé. Le reste du parcours, données, abonnement et tests compris, est dans suppression de compte iOS.
Que répondre à Apple après un refus 4.8
Le message d'Apple propose deux sorties. Soit tu ajoutes une option équivalente. Soit ton app en a déjà une : tu réponds dans App Store Connect, tu dis laquelle et pourquoi elle remplit les trois conditions. Apple suggère aussi de mettre à jour les captures qui montrent l'écran de connexion. La procédure pour répondre à App Review est la même que pour les autres règles.
Voici un modèle en anglais, à adapter (remplace le numéro de 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 check-list 4.8 avant l'envoi
- Tu sais si ton app a besoin d'un compte. Sinon, elle s'utilise sans connexion.
- Si Google, Facebook ou X créent le compte, la connexion Apple est sur le même écran.
- Le bouton Apple est le bouton officiel, aussi grand que les autres, visible sans défiler.
- Le fournisseur Apple est activé côté serveur, avec ton identifiant de bundle.
- Une annulation ramène à l'écran de connexion, sans message d'erreur.
- Le prénom et l'e-mail sont enregistrés dès la première connexion.
- La suppression de compte révoque le jeton Apple, depuis ton serveur.
- Tout est testé sur un vrai iPhone, avec un compte Apple qui ne s'est jamais connecté à l'app.
- Tes captures montrent l'écran de connexion tel qu'il est dans la build envoyée.
Corriger ton refus avant de renvoyer l'app
Si ton app vient d'être refusée en 4.8, le Kit Review Apple rassemble ce que je vérifie avant chaque envoi, avec deux skills qui relisent ton projet dans Claude Code et préparent ta réponse si Apple refuse. Pour un regard humain, réserve une heure avec moi : on lit le message ensemble et on regarde ton écran de connexion. La démarche complète après un refus est sur la page application refusée par Apple.
Si tu prépares ta première sortie, fais ton diagnostic gratuit : il te dit quelle étape attaquer d'abord et t'envoie ma checklist anti-refus Apple.
Personne ne peut garantir qu'Apple acceptera ton app. Ajouter la connexion Apple au bon endroit retire au moins ce motif de la liste.
Questions fréquentes
La connexion avec Apple est-elle obligatoire sur iOS ?
Non, pas dans tous les cas. Elle n'est exigée que si ton app propose une connexion tierce, comme Google ou Facebook, pour créer le compte principal. Depuis janvier 2024, un autre service équivalent peut la remplacer, mais Apple ne cite que la connexion Apple comme conforme.
Que veut dire « Guideline 4.8 - Design - Login Services » ?
C'est l'intitulé du refus dans le message d'Apple. Il signifie que ton app propose une connexion tierce sans offrir d'option équivalente qui limite les données au nom et à l'e-mail, permet de cacher l'e-mail et ne sert pas à la publicité sans accord.
Mon inscription par e-mail suffit-elle à côté de Google ?
Ce n'est pas garanti. Le texte demande un service qui permet de garder son e-mail privé, alors qu'un formulaire classique le demande. Apple n'a pas publié de position sur ce cas, et son message de refus ne cite que la connexion Apple. Je ne prendrais pas ce risque.
Faut-il proposer la connexion Apple sur Android ?
Non. La 4.8 est une règle de l'App Store, et le module d'Expo ne fonctionne que sur iOS. Sur Android, isAvailableAsync() renvoie faux : le bouton Apple ne s'affiche pas, et Google peut rester seul.
Faut-il un nouveau build après un refus 4.8 ?
Oui, dans la plupart des cas. La connexion Apple demande une capacité native, activée au moment du build. Une mise à jour à distance ne peut pas l'ajouter. Seule exception : ton app avait déjà une option conforme, et il suffit de l'expliquer à Apple dans ta réponse.