Parcours techniques
Sommaire
Réponse courte
Non, Sign in with Apple n'est pas obligatoire en soi. Ce qui est obligatoire, c'est la règle 4.8 des App Store Review Guidelines :
- si ton app utilise un service de connexion tiers (Google, Facebook, X, LinkedIn, Amazon, WeChat…) pour créer ou ouvrir le compte principal de l'utilisateur,
- elle doit aussi proposer, en option équivalente, un autre service de connexion qui :
- limite la collecte au nom et à l'adresse e-mail ;
- permet à l'utilisateur de garder son adresse e-mail privée en créant son compte ;
- ne collecte pas les interactions avec ton app à des fins publicitaires sans consentement.
Sign in with Apple coche ces trois cases, c'est pourquoi c'est la solution la plus courante. Mais si ton app n'a pas de connexion Google ou Facebook, ou si elle n'a pas de compte du tout, la règle 4.8 ne te concerne pas.
Si tu proposes Sign in with Apple et que l'utilisateur supprime son compte, Apple demande aussi de révoquer ses jetons de connexion (règle 5.1.1(v)).
Qui est concerné, et les exceptions
Concerné : la connexion tiers pour le compte principal
Apple définit le compte principal comme celui que l'utilisateur crée dans ton app pour s'identifier, se connecter et accéder à tes fonctions. Un bouton « Continuer avec Google » qui crée ce compte déclenche la règle.
Les cinq exceptions prévues par Apple
Un autre service de connexion n'est pas exigé si :
- ton app utilise uniquement ton propre système de création de compte et de connexion (e-mail et mot de passe gérés par toi, par exemple) ;
- ton app est une boutique d'apps alternative, ou est distribuée par l'une d'elles, avec une connexion propre à cette boutique ;
- c'est une app d'éducation, d'entreprise ou professionnelle qui demande de se connecter avec un compte d'école ou d'entreprise existant ;
- ton app utilise un système d'identité officiel (identité numérique publique ou soutenue par un secteur) ;
- ton app est le client d'un service tiers précis et l'utilisateur doit se connecter à son compte (messagerie, réseau social…) pour accéder à son propre contenu.
Pas concerné : l'app sans compte
Si ton app fonctionne sans compte, la question ne se pose pas. Et la règle 5.1.1(v) rappelle qu'il ne faut pas forcer la connexion quand elle n'est pas nécessaire au fonctionnement de l'app.
Pourquoi Sign in with Apple remplit la règle 4.8
D'après les recommandations de design d'Apple, Sign in with Apple permet de se connecter avec le compte Apple qu'on a déjà, sans formulaire ni mot de passe. Quand l'app demande le nom et l'e-mail, l'utilisateur peut partager une adresse e-mail aléatoire et unique qui lui transfère automatiquement les messages : c'est l'e-mail masqué. L'authentification se fait avec Face ID ou Touch ID, avec la double authentification intégrée, et Apple indique ne pas utiliser Sign in with Apple pour profiler les gens ni leur activité dans les apps.
Tu peux aussi utiliser un autre service qui respecte les trois critères : la règle ne cite pas de marque.
Comment afficher le bouton ?
Apple demande d'afficher le bouton Sign in with Apple en évidence : pas plus petit que les autres boutons de connexion, et sans obliger à faire défiler l'écran pour le voir. Apple recommande ses boutons officiels, qui ont la bonne apparence et se traduisent automatiquement dans la langue de l'appareil.
Apple conseille aussi de retarder la connexion le plus possible : laisser découvrir l'app avant de demander un compte, et expliquer en une phrase ce que la connexion apporte.
Que faire à la suppression du compte ?
Si ton app permet de créer un compte, elle doit permettre de le supprimer depuis l'app (règle 5.1.1(v)) : option facile à trouver, vraie suppression du compte et des données personnelles, lien direct si la suppression se termine sur un site web, et information sur les délais. Le détail est dans Suppression de compte obligatoire.
Pour Sign in with Apple, Apple ajoute un point précis : les apps doivent utiliser la Sign in with Apple REST API pour révoquer les jetons de l'utilisateur. Un jeton, c'est l'autorisation que ton app a reçue d'Apple pour cet utilisateur ; la révocation l'annule, et l'utilisateur n'est plus relié à ton app. Apple recommande aussi de recevoir ses notifications serveur à serveur sur les changements de comptes (par exemple quand quelqu'un arrête d'utiliser Sign in with Apple avec ton app).
Concrètement, cette révocation se fait depuis un serveur : il faut un service en ligne qui appelle l'adresse de révocation d'Apple. Une app sans serveur ne peut pas le faire seule.
Procédure pas à pas
Les étapes ci-dessous partent d'un projet Expo, la technologie des apps créées avec Briksell.
Étape 1 : installer la bibliothèque
Expo fournit la bibliothèque expo-apple-authentication. On l'installe avec npx expo install expo-apple-authentication. Elle fonctionne sur iOS et tvOS uniquement : Expo précise qu'elle ne gère pas encore Android ni le web.
Étape 2 : activer la fonction dans app.json
Ajoute "usesAppleSignIn": true dans la partie ios de app.json, ou le plugin expo-apple-authentication dans plugins. C'est ce réglage qui permet à EAS Build d'activer la fonction « Sign in with Apple » pour l'identifiant de ton app. Sans EAS Build, il faut activer cette fonction à la main dans ton compte Apple Developer.
Étape 3 : afficher le bouton seulement s'il est disponible
Expo recommande de n'afficher le bouton que si la fonction isAvailableAsync() répond « oui », c'est-à-dire si le système de l'appareil gère la connexion Apple.
Étape 4 : enregistrer le nom et l'e-mail dès la première fois
Point piège : Expo prévient que tu ne reçois le nom et l'e-mail qu'à la première connexion. Aux suivantes, ils peuvent être vides. Garde-les dès le premier passage. L'identifiant user renvoyé, lui, reste stable et sert à reconnaître l'utilisateur.
Étape 5 : vérifier côté serveur
La réponse contient un jeton signé (identityToken). Expo indique qu'on peut vérifier sa signature avec la clé publique d'Apple. C'est là encore le travail d'un serveur.
Étape 6 : tester
Expo indique qu'on peut tester cette bibliothèque dans Expo Go sur iOS. Pour la version publiée, l'app est construite avec EAS Build, qui applique le réglage de l'étape 2. Pour les tests avant publication, vois TestFlight : tester son app.
Et avec Briksell ?
Soyons francs sur ce que Briksell fait aujourd'hui :
- Pas de serveur de comptes fourni. Les apps créées gardent leurs données sur le téléphone : pas de comptes en ligne, pas de synchronisation. Dans ce cas, la règle 4.8 ne s'applique pas, puisqu'il n'y a pas de connexion.
- L'aperçu s'ouvre dans le navigateur du téléphone. Or expo-apple-authentication ne gère pas le web : le bouton n'y fonctionne pas. Le test dans Expo Go depuis Briksell arrive bientôt.
- Pour aller plus loin, tu peux exporter le code et y brancher un service de comptes et un serveur, qui s'occupera aussi de la révocation des jetons.
Si tu prévois des comptes dès le départ, pense à tout le parcours avant d'écrire le premier écran : connexion, suppression, politique de confidentialité. La liste complète des points techniques est dans Préparer techniquement une app iOS avant App Review.
Erreurs fréquentes
Proposer uniquement « Continuer avec Google »
C'est le cas exact visé par la règle 4.8. Ajoute une option équivalente qui respecte les trois critères.
Cacher le bouton Apple
Un bouton plus petit, en bas de l'écran, après défilement : Apple demande qu'il ne soit pas plus petit que les autres et visible sans défiler.
Demander plus que le nom et l'e-mail via cette option
L'option équivalente doit limiter la collecte au nom et à l'e-mail. Si tu demandes d'autres informations, explique pourquoi elles sont utiles à l'app.
Perdre le nom de l'utilisateur
Si tu ne l'enregistres pas à la première connexion, tu ne le récupéreras pas ensuite.
Supprimer le compte sans révoquer les jetons
La suppression doit être complète : compte, données et autorisation Sign in with Apple.
Forcer la connexion pour une app qui n'en a pas besoin
Une app de recettes ou de méditation peut très bien fonctionner sans compte (règle 5.1.1(v)).
Vérification
Coche chaque point avant d'envoyer ton app. La liste est enregistrée seulement dans ton navigateur.
Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.
Sources Apple et date de vérification
Vérifié le 22 octobre 2026 sur les pages officielles d'Apple et d'Expo :
- App Store Review Guidelines : texte complet de la règle 4.8 (trois critères, définition du compte principal, cinq exceptions) et règle 5.1.1(v).
- 5.1.1(v) Offering account deletion : exigences de suppression et révocation des jetons Sign in with Apple via la REST API.
- Token revocation : appel de révocation des jetons et autorisations.
- HIG Sign in with Apple : e-mail masqué, double authentification, pas de profilage, taille et place du bouton, connexion retardée.
- AppleAuthentication (Expo) : installation, usesAppleSignIn, iOS et tvOS seulement, nom et e-mail à la première connexion, test dans Expo Go sur iOS.
FAQ
Mon app n'a que l'e-mail et le mot de passe. Dois-je ajouter Sign in with Apple ?
Non. La règle 4.8 prévoit une exception pour les apps qui utilisent uniquement leur propre système de compte.
Sign in with Apple marche-t-il sur Android ?
Apple indique qu'on peut le proposer sur toutes les plateformes, y compris non Apple. Mais la bibliothèque Expo expo-apple-authentication ne gère que iOS et tvOS. Pour une app sur les deux systèmes, lis Créer une application Android et iOS.
Et si l'utilisateur choisit de masquer son e-mail ?
Tu reçois une adresse relais unique. Les messages envoyés à cette adresse arrivent dans sa vraie boîte. Traite-la comme une adresse normale.
Une app sans compte peut-elle être refusée pour la règle 4.8 ?
La règle porte sur les services de connexion. Sans connexion, elle ne s'applique pas. Pour les autres causes de refus, vois Pourquoi Apple refuse une application.
Passer à l'action
Commence par une app qui marche sans compte : c'est plus simple pour tes utilisateurs et pour la revue. Décris ton idée à Briksell, teste-la sur ton téléphone, et ajoute les comptes quand ton app en aura vraiment besoin. Créer mon app.
