Novedades en StoreKit y compras dentro de la app

Hola, soy Rudy. Me entusiasma compartir las nuevas características de StoreKit y mostrar cómo puedes incorporar la biblioteca de App Store Server y las nuevas API de StoreKit 2 en tu flujo de trabajo de desarrollo. Primero, repasaremos las nuevas características de la estructura principal en StoreKit. Te mostraré cómo puedes firmar tus solicitudes de compra dentro de la app mediante la biblioteca de App Store Server.

Por último, veremos una nueva forma de comercializar suscripciones en tu app mediante SwiftUI y vistas StoreKit.

Para comenzar, analicemos las actualizaciones realizadas en tres tipos cruciales: AppTransaction, Transacción y RenewalInfo. Estos tipos te brindan información sobre la compra de tu app, te permiten ver el historial de compras y administrar estados de suscripción. AppTransaction proporciona información sobre la compra original de tu app. Puedes usar esto para conocer la fecha de compra original, la versión que el cliente la descargó y la fecha en que un cliente la reservó antes de que se lanzara en el App Store. Por ejemplo, podrías utilizar appVersion para solicitar a los clientes que actualicen tu app, para garantizar que estén ejecutando la última versión. Para obtener una AppTransaction, consulta la API AppTransaction.shared y usa un resultado verificado. StoreKit valida automáticamente la firma web JSON para la AppTransaction y devuelve un valor verificado en el resultado de la verificación. Una AppTransaction verificada significa que StoreKit pudo verificar que AppTransaction fue firmada por el App Store y que pertenece a tu app y al dispositivo del cliente. Queremos brindarte la mayor cantidad de información posible sobre suscripciones y ofertas a medida que desarrollas tu estrategia comercial. Este año, agregamos dos campos al tipo AppTransaction. A partir de iOS 18.4, el tipo AppTransaction incluye el campo appTransactionID, que se implementó nuevamente en iOS 15. appTransactionID es un valor único global para cada cuenta de Apple que descarga tu app. El appTransactionID es único para cada miembro del grupo familiar para las app compatibles con Compartir en familia. Con appTransactionID, puedes hacer cosas como asociar distintos ID de transacciones originales sin una llamada de servidor a servidor.

iOS 18.4 también introdujo el campo originalPlatform. originalPlatform es de un nuevo tipo, llamado AppStore.Platform. Este valor representa la plataforma en la que el cliente compró originalmente tu app, iOS, macOS, tvOS o visionOS. Estos valores coinciden con las plataformas de destino disponibles en App Store Connect. Las apps que la gente descarga en watchOS tienen originalPlatform configurado en iOS. Con el campo originalPlatform, puedes respaldar fácilmente cambios en el modelo de negocios, como pasar de una app de paga a una app gratuita dentro de compras dentro de la app. El campo originalPlatform puede ayudarte a otorgar derechos a los clientes de forma adecuada a medida que tu negocio evoluciona. A continuación, tenemos actualizaciones en el tipo de Transacción. Una transacción representa una compra dentro de la app exitosa y contiene información útil sobre la compra. La transacción incluye la fecha de compra, el productID de la compra y, en el caso de suscripciones con renovación automática, la fecha en que vence la suscripción. La transacción se utiliza principalmente para validar los derechos del cliente y desbloquear contenido. Tu app identifica el contenido que debe desbloquear mediante el campo productID. El sistema genera una Transacción, ya sea en línea después de que se completa exitosamente una compra o mediante una secuencia de Transacción, como Transaction.currentEntitlements. No importa cómo las recuperes, las transacciones siempre se incluyen en un resultado de verificación, de forma similar a AppTransactions. Es decir que no necesitas preocuparte por verificar manualmente la transacción, ya que StoreKit 2 lo maneja por ti. Hablando de derechos actuales, a partir de iOS 18.4, la API Transaction.currentEntitlement para productID está obsoleta y se reemplaza por la nueva API Transaction.currentEntitlements. Llama a esta nueva API pasando un productID. Esta API devuelve una secuencia asincrónica de transacciones que dan derecho al cliente a un producto determinado. Debido a que un cliente puede tener más de una transacción que le da derecho a un producto, por ejemplo, si posee una suscripción pero también tiene acceso a ella a través de Compartir en familia, se recomienda que adoptes esta API. Como novedad este año, el modelo Transacción tiene tres campos adicionales.

El campo appTransactionID, que se implementó nuevamente en iOS 15, es un identificador único de la transacción de descarga de la app. Este es el mismo valor que contiene el tipo AppTransaction, que analicé anteriormente. iOS 18.4 también introdujo el campo Período de oferta, que está contenido en el miembro de la oferta. El período de oferta es el período de suscripción asociado con una oferta de suscripción que un cliente canjea en el momento de la compra. El último campo nuevo introducido en iOS 18.4 es advancedCommerceInfo. AdvancedCommerceInfo solo se aplica a las apps que utilizan la API de comercio avanzado. Para las apps que no utilizan la API de comercio avanzado, este campo siempre es nulo. Esta API te permite admitir más fácilmente compras dentro de la app para grandes catálogos de contenido, experiencias de creadores y suscripciones con complementos opcionales. Para respaldar la API de comercio avanzado, StoreKit 2 proporciona nuevas API nativas, incluidas AdvancedCommerceProduct, disponible en iOS 18.4, y API existentes, como Transaction y SubscriptionStatus. Para obtener más información sobre la API de comercio avanzado, visita los recursos de la página web para esta sesión. Por último, revisemos nuestras actualizaciones del tipo RenewalInfo. El tipo RenewalInfo es específicamente para suscripciones con renovación automática. RenewalInfo contiene información como, por ejemplo, si se renovará automáticamente, la fecha de la próxima renovación, y, en el caso suscripciones que hayan expirado, el motivo por el cual expiró la suscripción. Un ejemplo de cómo podría utilizar el motivo de vencimiento de la suscripción es si recientemente aumentó el precio de su servicio y el motivo de vencimiento es didNotConsentToPriceIncrease. Es un buen momento para comercializar una oferta de recuperación y alentar al cliente a suscribirse de nuevo. StoreKit pone a disposición los valores de RenewalInfo como un miembro VerificationResult encapsulado en instancias de SubscriptionStatus. Puedes obtener un SubscriptionStatus de varias maneras, como a través de la API de actualizaciones de SubscriptionStatus o consultando a StoreKit los estados de suscripción mediante un ID de grupo de suscripción. Como recordatorio, cuando consultas a StoreKit sobre estados de suscripción usando un ID de grupo de suscripción, asegúrate de proporcionar acceso a tu servicio de apps en función del SubscriptionStatus que ofrezca el nivel de servicio más alto, como figura en tu modelo de negocios. Otra novedad de iOS 18.4 es la API SubscriptionStatus, que toma un ID de transacción. Ahora, puedes consultar a StoreKit sobre el estado de una suscripción usando el ID de transacción de cualquier transacción asociada con una suscripción. Este año, introdujimos cuatro campos adicionales al tipo RenewalInfo. El campo appTransactionID se implementó de nuevo en iOS 15 y Período de oferta y advancedCommerceInfo están disponibles a partir de iOS 18.4. También agregamos el campo appAccountToken, que asocia una suscripción con una cuenta de cliente en su servicio. Opcionalmente, puedes proporcionar un appAccountToken al momento de la compra con la opción de compra appAccountToken. App Store devuelve este mismo valor en el nuevo campo appAccountToken para el RenewalInfo asociado con la suscripción. Para acceder a estos nuevos campos, todo lo que necesitas hacer es crear tu app utilizando el Xcode más reciente. Creemos que estos nuevos campos harán que el desarrollo de tu app sea más fácil y te ayudarán a ofrecer una mejor experiencia al cliente. Ahora, me gustaría cambiar el enfoque y analizar los códigos de oferta. Se trata de códigos alfanuméricos que te permiten ofrecer suscripciones con descuento o de forma gratuita durante una duración específica. Los clientes pueden canjear códigos en el App Store con URL de canje único o en tu app, si implementas las API de canje de códigos de oferta de StoreKit. Quiero compartir que los códigos de oferta ahora están disponibles para consumibles, no consumibles y suscripciones no renovables. Los clientes pueden canjear códigos de oferta dentro de tu app a través de la API offerCodeRedemption. Si tu app utiliza UIKit, utiliza la API presentOfferCodeRedeemSheet. Canjear los códigos de oferta para consumibles, no consumibles y suscripciones no renovables estará de nuevo disponible en iOS 16.3. La transacción generada por un canje exitoso de código de oferta está disponible en cualquier versión del OS que utilice las API de StoreKit 2. Si tu app admite versiones del OS incluso anteriores, los clientes pueden canjear códigos de oferta por suscripciones con renovación automática hasta iOS 14.2. Para admitir el canje de códigos de oferta para tipos de productos distintos a las suscripciones con renovación automática, presentamos un nuevo modo de pago en el tipo Transaction.Offer.PaymentMode. Aquí se describe cómo se le cobra o no al cliente durante la oferta, dependiendo del tipo de oferta. Representa varios modos de pago, incluidos casos como el de freeTrial, donde no se requiere pago. Los otros métodos de pago incluyen payAsYouGo y payUpFront. Ahora en iOS, puedes esperar el modo de pago oneTime para los códigos de oferta de compras dentro de la app, que está disponible desde iOS 17.2. Si tu app es compatible con versiones del OS anteriores a la 17.2, puedes acceder a este nuevo modo de pago a través del miembro offerPaymentModeStringRepresentation en Transaction, que está disponible desde iOS 15. Si quieres profundizar en la configuración de códigos de oferta consulta la sesión de 2025, “¿Qué novedades hay en App Store Connect?”. A partir de iOS 18.2, StoreKit agregó métodos de compra que requieren un contexto de IU. Tu app debe especificar el contexto de la IU donde se origina una compra para que el sistema pueda mostrar la hoja de pago y el cuadro de diálogo de éxito en la región más intuitiva de la escena activa del dispositivo. Estos nuevos métodos están disponibles a partir de iOS 18.2 y versiones alineadas. El contexto de UI que proporcionas varía según la plataforma. En iOS, macCatalyst, tvOS y visionOS, el contexto de UI es un UIViewController. En macOS, es una NSWindow. Si estás desarrollando para watchOS, no proporcionas contexto de IU. Si realizas la compra desde una vista SwiftUI, no realizarás este cálculo por tu cuenta. En su lugar, lee el valor del entorno de compra para obtener una instancia de PurchaseAction. Cuando ya quieras realizar una compra, llama a la instancia PurchaseAction directamente, porque define un método callAsFunction que Swift llama cuando llamas a la instancia. Si utilizas vistas de StoreKit, no tendrás que preocuparte por proporcionar el contexto de la IU.

El sistema lo gestiona automáticamente por ti. Para aprender cómo implementar la mejor experiencia de compra dentro de la app para tus clientes con ProductView, StoreView y SubscriptionStoreView, consulta nuestra sesión WWDC 23, “Conozca StoreKit para SwiftUI”. Ahora que vimos las mejoras principales de la API, quiero llamar tu atención sobre otra actualización importante. Este año, introdujimos nuevas API que requieren una firma web JSON. Exploremos estas API y cómo puedes utilizar la biblioteca de App Store Server en tu flujo de trabajo de desarrollo para simplificar el proceso de firma. Como novedad este año, puedes establecer la elegibilidad de un cliente para una oferta introductoria con introductoryOfferEligibility. También, puedes firmar tus ofertas promocionales utilizando el formato JWS con la nueva opción de compra promotionalOffer. Estas nuevas opciones de compra requieren una cadena JWS compacta y están implementadas nuevamente en iOS 15. También introdujimos nuevos modificadores de vista SwiftUI para acompañar cada una de estas opciones de compra. El uso de JWS ayuda a la App Store a verificar que autorizaste la compra para casos de uso específicos, como establecer la elegibilidad de un cliente para una oferta promocional o una oferta de introducción. Para que firmar sus solicitudes sea lo más fácil posible, tenemos excelentes herramientas de código abierto, como la biblioteca de App Store Server, que simplifican el proceso de firma. Para ver lo rápido que es crear solicitudes firmadas para tu app, veamos cómo firmaríamos una oferta promocional en SKDemo. Antes de comenzar, deberás recuperar tu clave de firma de compra dentro de la app desde App Store Connect. Puedes hacerlo desde la pestaña Usuarios y acceso, haciendo clic en Integraciones

y eligiendo Compras dentro de la app en la navegación izquierda. Puedes utilizar cualquier clave activa o crear una nueva clave. Querrás tomar nota del ID del emisor y el ID de la clave de firma de tu compra dentro de la app. Ya que tienes una clave de firma de compra dentro de la app, veamos la tienda de suscripciones dentro de la app en SKDemo. Nuestra tienda de suscripciones comercializa los planes disponibles que un cliente puede comprar. Me gustaría volver a adquirir suscriptores cuyas suscripciones expiraron. Para ello, comercializaré una oferta promocional en el plan Pro usando el nuevo modificador subscriptionPromotionalOffer basado en JWS. Este modificador espera dos cierres. En el primer cierre, proporcionas la oferta que debe aplicarse a la compra de una suscripción determinada. Para este ejemplo, elegiré la oferta promocional que tenga el período de prueba gratuito más largo para el Plan Pro usando un método auxiliar que creé anteriormente. El segundo cierre de este modificador espera un JWS compacto que contenga los detalles de la oferta firmada. Esto nos lo proporciona el tipo NetworkLayer. Veamos más de cerca cómo se ve esa implementación. En ourNetworkLayer, pasamos el productID y el ID de la oferta para nuestro producto y oferta de suscripción como parámetros de consulta de la solicitud. Luego, realizamos una solicitud GET a la ruta de firma de oferta de promoción en nuestro servidor. Finalmente, decodificamos la respuesta. En tu proyecto de servidor, agrega la dependencia del paquete Swift de la biblioteca de App Store Server e importa la biblioteca. En su implementación de la ruta responsable de manejar las solicitudes de firma de ofertas de promoción, creas un contexto de firma promocional inicializando un PromotionOfferV2SignatureCreator con el ID del paquete de tu app, la clave de firma, el ID de clave y el ID del emisor que recuperaste de App Store Connect anteriormente. Luego, llama a la función createSignature y proporciona el productID de la suscripción que se está comprando y el ID de la oferta de suscripción. También es una buena práctica incluir un valor para el campo ID de transacción. Este valor puede ser el appTransactionID o el TransactionID de cualquier transacción que pertenezca al cliente. Aunque el campo TransactionID es opcional, se recomienda incluirlo.

De nuevo en la app, la oferta promocional se puede canjear con éxito y la compra se completa sin incidentes. Así es cómo puedes crear solicitudes firmadas de compra dentro de la app mediante la biblioteca de App Store Server. Firmar tus solicitudes de compra dentro de la app ayuda al App Store a verificar que autorizaste una compra. La integración con la biblioteca de App Store Server hace que firmar tus solicitudes sea fácil. Lo mejor es que la biblioteca del App Store Server está disponible en cuatro idiomas: Java, Python, Node.js y Swift. Para comenzar a utilizar la biblioteca, consulta nuestra sesión WWDC24, “Explorar las API del App Store Server para compras dentro de la app”. Para nuestro conjunto final de actualizaciones, veremos una nueva forma de usar SwiftUI para interactuar con clientes en tu app. Me complace presentar al miembro más nuevo de la familia de vistas de StoreKit: SubscriptionOfferView. Esta es una nueva vista de SwiftUI para comercialización y suscripción con renovación automática y está diseñada para captar la atención de tus clientes sobre el servicio de tu app. Declaras un SubscriptionOfferView utilizando una suscripción con renovación automática ya cargada, o utilizando el productID para una suscripción con renovación automática. Cuando se declara de esta manera, la vista hace todo el trabajo de cargar los metadatos del producto desde la App Store. También puedes utilizar la imagen de suscripción configurada en App Store Connect para decorar la vista estableciendo el indicador prefersPromotionalIcon en verdadero. El ícon decorativo se muestra cuando el sistema termina de cargar los metadatos de la suscripción. Si prefieres utilizar un ícono personalizado para decorar la vista, puedes usar la ortografía alternativa de esta API y pasar un cierre ViewBuilder final. Puedes proporcionar un ícono de marcador de posición personalizado, que se muestra mientras se descargan los metadatos de suscripción desde App Store Server. SubscriptionOfferView puede comercializar más que un solo plan de suscripción individual. Al combinarse con el nuevo modificador, subscriptionOfferViewDetailAction, puedes usar esta vista para, por ejemplo, dirigir el tráfico de clientes a tu tienda de suscripciones en la app. Al declarar este modificador, se dibuja el botón detailLink en la vista. Cuando un cliente toca el botón detailLink, la vista llama para cerrar su ruta a este modificador. Aquí hay un ejemplo en SKDemo. Modifico algún estado en ContentView que controla el método de presentación del flujo de usuario de la app. Cuando el cliente toca el botón detailLink, se lo lleva a la tienda de suscripciones de la app para ver los planes de suscripción disponibles para comprar. Algo a tener en cuenta al decidir usar la API es qué plan de suscripción comercializar o si debería mostrarse o no. Regresemos al código para ver un ejemplo de cómo utilizar esta API. Para saber qué plan de suscripción comercializar con un SubscriptionOfferView, primero hay que determinar el estado de suscripción del cliente. En las apps escritas con SwiftUI, el lugar más conveniente para esto es en la implementación del protocolo de la app. Luego, utiliza estos datos para informar al resto de la jerarquía de vistas. Puedes hacer esto declarando el modificador subscriptionStatusTask, introducido en iOS 17. Luego, traduce los estados de suscripción de StoreKit en este modificador a un modelo que tu app entienda. En SKDemo, este modelo se llama SKDemoPlusStatus. Luego, actualiza una fuente de verdad en su vista que rastrea un estado y lo vende a través del entorno utilizando una variable de entorno.

Ahora que tengo el estado del cliente, lo usaré para mostrar un SubscriptionOfferView en ContentView. Leo el valor del entorno que contiene el estado del cliente y decido comercializar un plan estándar si el cliente no es un suscriptor activo o planes de nivel superior si el cliente ya está suscrito. Para mantener mi código más conciso, usaré el inicializador de ID de grupo para crear mi SubscriptionOfferView. Cuando se declara de esta manera, el sistema elige automáticamente un plan de mi grupo de suscripción. También deberá especificar la relación del plan comercializado con respecto al plan actual del cliente. El parámetro visibleRelationship puede ser uno de cinco valores: actualizar, degradar, cambiar de versión, actual y todo. Esta API se comporta de manera diferente según el estado del cliente. Echemos un mirada más de cerca a cada una de las relaciones, comenzando con la actualización. Para fines de demostración, supongamos que el cliente de nuestro ejemplo está suscrito al plan de nivel medio. Al especificar la actualización, se muestra un plan de suscripción que es un nivel superior al plan actual. En el caso de la relación de degradación, ocurre lo inverso. En este ejemplo, el cliente suscrito y el no suscrito verían el mismo plan. Es posible que desees comercializar un plan más asequible si el cliente desactivó la renovación automática y deseas conservarlo antes de que finalice el ciclo de renovación. La opción de actualización cruzada considera los planes del grupo cuyo nivel es equivalente al plan actual y elige la opción con mejor valor. Con la relación actual se comercializa el plan actual del cliente. De forma predeterminada, las interacciones están deshabilitadas a menos que haya una oferta de suscripción disponible para canjear. Puede marcar a un cliente como elegible para una oferta utilizando cualquiera de los modificadores de oferta, como el nuevo modificador subscriptionPromotionalOffer y preferredSubscriptionOffer. Un gran uso de esta relación es ofrecer un descuento para una suscripción que está por vencer para ayudar a retener a los suscriptores. Finalmente, toda la relación. Esta relación se comporta igual para todos los clientes. Cuando se inicializa de esta manera, la vista muestra información de precios sobre todos los planes de tu grupo. Debes proporcionar la acción que se realizará en la vista declarando el modificador subscriptionOfferViewDetailAction. Independientemente de la relación con la que crees un SubscriptionOfferView, también puedes decorarlo utilizando un ícono personalizado y un ícono de marcador de posición, similar al ejemplo anterior en la sesión. También resulta cómodo utilizar el ícon de la app. Simplemente establece el indicador useAppIcon en verdadero. Y con esto finaliza el nuevo SubscriptionOfferView, una forma emocionante de interactuar con tus clientes. Hoy hablé de numerosas mejoras de la API de StoreKit que te ayudarán a ofrecer una excelente experiencia de compra dentro de la app a tus clientes. Para utilizar estas nuevas funciones, ahora es un excelente momento para adoptar StoreKit 2 en tu proyecto, si aún no lo hiciste. Para obtener los últimos diseños y crear una excelente tienda en tu app, usa las vistas de StoreKit y comercializa tus compras en la app y suscripciones. Consulta la biblioteca de App Store Server en GitHub e intégrala en tu proyecto para que el registro de solicitudes de compras dentro la app sea lo más fácil posible. Para obtener más información sobre las API del servidor de App Store, tenemos una nueva sesión de WWDC25, “Profundice en las API de App Store Server para compras dentro de la app”. Y para comenzar a adoptar StoreKit 2, nuestra sesión WWDC21, “Conozca StoreKit 2”, es un excelente punto de partida. ¡Gracias por acompañarme! Me emociona ver lo que construyes con StoreKit.