¿Qué necesita una aplicación de iOS para emular una tarjeta?

Las autorizaciones van primero

CardSession, desde iOS 17.4, es la clase que emula una tarjeta, y la documentación de Apple enumera lo que cubre en el Espacio Económico Europeo: pagos en tienda, llaves de coche, transporte de sistema cerrado, credenciales de empresa, llaves de hotel, fidelización y entradas de eventos.

La gobiernan tres autorizaciones. com.apple.developer.nfc.hce permite la API en sí, y sin ella crear una sesión provoca un error fatal. La autorización de los prefijos de identificador enumera aquello a lo que responde la aplicación: identificadores de aplicación completos, identificadores de proveedor registrados, o prefijos al menos tan largos como el identificador de proveedor. La autorización de aplicación sin contacto por defecto permite elegir la aplicación en los ajustes como la del sin contacto por defecto.

Cada una de las tres páginas remite al mismo sitio, un formulario de solicitud para las transacciones sin contacto basadas en la emulación de tarjeta por el host, destinado a las aplicaciones bancarias y de cartera del Espacio Económico Europeo. El lado comercial lo cubre la página de la emulación en el iPhone; la consecuencia técnica es que el código de abajo solo se ejecuta allí donde Apple ha dicho que sí.

Dos comprobaciones antes de que aparezca nada

Apple pide tres valores antes de crear una sesión: NFCReaderSession.readingAvailable, CardSession.isSupported para el aparato, y CardSession.isEligible para el entorno del momento, que es asíncrona. La referencia dice con todas las letras por qué importa cada una: crear una sesión en un aparato no admitido provoca un error fatal, y uno que no sea elegible mostraría para nada la interfaz de sesión de tarjeta del sistema.

Así que la comprobación va antes del botón, no después. Una aplicación que se ofrece a presentar una tarjeta y luego falla la comprobación de elegibilidad ya ha prometido algo que el sistema no va a entregar.

La sesión, evento a evento

Una sesión de tarjeta es un flujo y no un delegado. La aplicación la crea, recorre eventStream, y recibe sessionStarted en cuanto tiene el recurso NFC, y luego readerDetected cuando el aparato nota el campo de un lector.

La emulación arranca cuando la aplicación llama a startEmulation(), que presenta la interfaz modal del sistema, con alertMessage puesto de antemano. A partir de ahí cada evento lleva una APDU que tratar y a la que responder con respond(response:), y Apple avisa de que ante una respuesta tardía un lector puede dar el tiempo por agotado. readerDeselected llega cuando el lector se va, stopEmulation(status:) apaga la interfaz de radio con un estado final que se muestra, e invalidate() libera la sesión.

startEmulation() lanza donde la plataforma se niega: el sistema no está disponible, no se ha aceptado el acceso, ha fallado la elegibilidad, o la radio está desactivada. Esos cuatro casos merecen mensajes distintos, ya que solo uno de ellos es un problema que quien usa el teléfono pueda arreglar.

A qué aplicación llega un toque

La aplicación sin contacto por defecto responde a un toque, salvo que otra aplicación pida el campo. NFCPresentmentIntentAssertion es esa petición: adquirida desde el primer plano, impide que la aplicación del sistema por defecto se lance en respuesta a un gesto o al campo de un lector, y Apple la ata a una persona que elige activamente una credencial en tu aplicación.

No dura. La aserción expira cuando el objeto se desinicializa, cuando la aplicación pasa a segundo plano, o al cabo de quince segundos, y solo se puede adquirir otra tras un plazo de quince segundos. Tampoco es obligatoria antes de presentar la hoja.

Android organiza la misma cuestión de otra manera, con un papel de cartera y una preferencia de primer plano que puede emplear cualquier aplicación; la página del encaminamiento lo cubre. Las dos plataformas coinciden en un punto: quien decide qué aplicación habla es quien usa el teléfono, no el lector.