De quoi une application iOS a-t-elle besoin pour émuler une carte ?
De trois choses qu'Apple contrôle : l'habilitation de session de carte, accordée sur demande sous accord commercial ; un appareil et un environnement que le système juge éligibles ; et du code qui répond aux APDU venus du flux d'événements de la session. Core NFC offre CardSession depuis iOS 17.4, derrière une feuille système.
Les habilitations viennent d'abord
CardSession, depuis iOS 17.4, est la classe qui émule une carte, et la documentation d'Apple liste ce qu'elle couvre dans l'Espace économique européen : paiements en magasin, clés de voiture, transport en boucle fermée, badges d'entreprise, clés d'hôtel, fidélité et billets d'événement.
Trois habilitations la gouvernent. com.apple.developer.nfc.hce autorise l'API elle-même, et sans elle créer une session lève une erreur fatale. L'habilitation des préfixes d'identifiant liste ce à quoi l'application répond : identifiants d'application complets, identifiants de fournisseur enregistrés, ou préfixes au moins aussi longs que l'identifiant de fournisseur. L'habilitation d'application sans contact par défaut permet à une personne de choisir l'application dans les réglages comme celle du sans contact par défaut.
Chacune des trois pages renvoie au même endroit, un formulaire de demande pour les transactions sans contact fondées sur l'émulation de carte par l'hôte, destiné aux applications bancaires et de portefeuille dans l'Espace économique européen. Le côté commercial est couvert par la page de l'émulation sur iPhone ; la conséquence technique est que le code ci-dessous ne s'exécute que là où Apple a dit oui.
Deux vérifications avant que rien ne paraisse
Apple demande trois valeurs avant qu'une session soit créée : NFCReaderSession.readingAvailable, CardSession.isSupported pour l'appareil, et CardSession.isEligible pour l'environnement courant, qui est asynchrone. La référence dit explicitement pourquoi chacune compte : créer une session sur un appareil non pris en charge lève une erreur fatale, et une session non éligible afficherait pour rien l'interface système de session de carte.
La vérification appartient donc à l'avant du bouton, pas à l'après. Une application qui propose de présenter une carte puis échoue au test d'éligibilité a déjà promis quelque chose que le système ne délivrera pas.
La session, événement par événement
Une session de carte est un flux plutôt qu'un délégué. L'application la crée, parcourt eventStream, et reçoit sessionStarted une fois qu'elle détient la ressource NFC, puis readerDetected quand l'appareil sent le champ d'un lecteur.
L'émulation commence quand l'application appelle startEmulation(), qui présente l'interface modale du système, alertMessage ayant été posé avant. À partir de là chaque événement porte un APDU à traiter et à auquel répondre par respond(response:), et Apple avertit qu'un lecteur peut traiter une réponse tardive comme une expiration. readerDeselected arrive quand le lecteur s'en va, stopEmulation(status:) ferme l'interface radio avec un statut final montré à l'utilisateur, et invalidate() libère la session.
startEmulation() lève une erreur là où la plateforme refuse : le système n'est pas disponible, l'accès n'a pas été accepté, l'éligibilité a échoué, ou la radio est désactivée. Ces quatre cas méritent des messages distincts, un seul d'entre eux étant un problème que l'utilisateur peut régler.
Quelle application un contact atteint
L'application sans contact par défaut répond à un contact, sauf si une autre application demande le champ. NFCPresentmentIntentAssertion est cette demande : acquise depuis le premier plan, elle empêche l'application système par défaut de se lancer en réponse à un geste ou au champ d'un lecteur, et Apple la lie à une personne qui choisit activement un justificatif dans votre application.
Elle ne dure pas. L'assertion expire quand l'objet est désinitialisé, quand l'application passe en arrière plan, ou au bout de quinze secondes, et une nouvelle ne peut être acquise qu'après un délai de quinze secondes. Elle n'est pas non plus exigée avant de présenter la feuille.
Android organise la même question autrement, avec un rôle de portefeuille et une préférence de premier plan que toute application peut employer ; la page de l'acheminement la couvre. Les deux plateformes s'accordent sur un point : c'est l'utilisateur, et non le lecteur, qui décide quelle application parle.
Questions fréquentes
N'importe quelle application iOS peut-elle émuler une carte ?
Non. L'habilitation de session de carte est accordée sur demande sous accord avec Apple, et créer une session sans elle lève une erreur fatale.
Quelles transactions Apple liste-t-elle ?
Paiements en magasin, clés de voiture, transport en boucle fermée, badges d'entreprise, clés d'hôtel, fidélité et billets d'événement, dans l'Espace économique européen.
L'utilisateur voit-il quelque chose pendant l'émulation ?
Oui. Démarrer l'émulation présente une interface modale du système, et le texte qui s'y trouve est le message d'alerte que l'application a posé avant.
Combien de temps dure une assertion d'intention de présentation ?
Quinze secondes, ou jusqu'à ce que l'application quitte le premier plan ou que l'objet soit désinitialisé, et une nouvelle attend un délai de quinze secondes.