Novidades do StoreKit e das compras dentro do app

Olá! Meu nome é Rudy. Vou mostrar os novos recursos do StoreKit e como você pode incorporar a App Store Server Library e as novas APIs do StoreKit 2 ao seu fluxo de desenvolvimento. Primeiro, vou falar sobre os novos recursos do framework no StoreKit. Depois, vou mostrar como assinar solicitações de compras dentro do app usando a App Store Server Library.

Por fim, vou analisar como vender assinaturas dentro do app usando views do SwiftUI e do StoreKit.

Para começar, vamos discutir as atualizações feitas em três tipos cruciais: AppTransaction, Transaction e RenewalInfo. Esses tipos fornecem informações sobre a compra do app e permitem monitorar o histórico de compras e gerenciar status de assinaturas. O AppTransaction fornece informações sobre a compra original do app. Você pode usá-lo para saber a data de compra original, a versão do app que o cliente baixou e a data em que um cliente comprou o app na pré-venda antes do lançamento na App Store. Você pode, por exemplo, usar appVersion para pedir que os clientes atualizem o app para a versão mais recente. Para obter um AppTransaction, consulte a API AppTransaction.shared e use um resultado verificado. O StoreKit valida automaticamente a Assinatura Web JSON para o AppTransaction e retorna um valor verificado no resultado da verificação. Um AppTransaction verificado significa que o StoreKit conseguiu verificar que o AppTransaction foi assinado pela App Store e pertence ao seu app e ao dispositivo do cliente. Queremos fornecer o máximo de informações possível sobre assinaturas e ofertas enquanto você monta sua estratégia de negócios. Este ano, adicionamos dois campos ao tipo AppTransaction. No iOS 18.4, o tipo AppTransaction inclui o campo appTransactionID, que foi reimplantado no iOS 15. appTransactionID é um valor global exclusivo para cada Conta Apple que baixa seu app. Ele também é exclusivo para cada membro do grupo familiar em apps compatíveis com o Compartilhamento Familiar. Com o appTransactionID, você pode associar IDs de transação originais distintos sem uma chamada de servidor para servidor.

O iOS 18.4 também introduziu o campo originalPlatform. originalPlatform é de um novo tipo chamado AppStore.Platform. Esse valor representa a plataforma em que o cliente comprou seu app originalmente: iOS, macOS, tvOS ou visionOS. Esses valores correspondem às plataformas de destino disponíveis no App Store Connect. Os apps baixados no watchOS terão o campo originalPlatform definido como iOS. No campo originalPlatform, você apoia mudanças no modelo de negócios com mais facilidade, como mudar de um app pago para um app gratuito com compras dentro do app. Ele também pode ajudar a dar direitos aos clientes à medida que sua empresa evoluir com o tempo. A seguir, temos atualizações para o tipo Transaction. Um Transaction representa uma compra dentro do app e contém informações úteis sobre ela. O Transaction inclui a data da compra, o productID da compra dentro do app e, no caso de assinaturas de renovação automática, a data em que a assinatura expira. Ele é usado principalmente para validar o direito do cliente e desbloquear conteúdo. Seu app identifica o conteúdo que deve ser desbloqueado usando o campo productID. O sistema produz um Transaction in-line após a conclusão de uma compra ou por meio de uma das sequências de Transaction, como Transaction.currentEntitlements. Independentemente de como você recupera um Transaction, ele é sempre encapsulado em um resultado de verificação, semelhante ao AppTransaction. Isso significa que você não precisa se preocupar em verificar o Transaction manualmente, já que o StoreKit 2 faz isso de maneira automática. Falando em direitos atuais, no iOS 18.4, a API Transaction.currentEntitlement for productID foi descontinuada e substituída pela nova API Transaction.currentEntitlements. Acione essa nova API com um productID. Ela retorna uma sequência assíncrona de Transactions que dão ao cliente direito a um produto. Como um cliente pode ter mais de um Transaction que dá direito a um produto (por exemplo, ele tem uma assinatura e tem acesso a ela pelo Compartilhamento Familiar), é recomendável que você use essa API no seu projeto. Novidade este ano, o modelo Transaction tem três campos adicionais.

O campo appTransactionID, que foi reimplantado no iOS 15, é um identificador exclusivo do Transaction de download do app. Esse é o mesmo valor que o tipo AppTransaction contém, que mencionei antes. O iOS 18.4 também introduziu o campo "Período de oferta", contido no membro da oferta. "Período de oferta" é o período de assinatura associado a uma oferta de assinatura que um cliente resgata no momento da compra. O último campo introduzido no iOS 18.4 é advancedCommerceInfo. AdvancedCommerceInfo só se aplica a apps que usam a API Advanced Commerce. Para apps que não usam essa API, esse campo é sempre nulo. Com a API Advanced Commerce, você oferece suporte a compras dentro do app para grandes catálogos de conteúdo, experiências de criação e assinaturas com complementos opcionais. Para oferecer suporte à API Advanced Commerce, o StoreKit 2 fornece novas APIs nativas, incluindo AdvancedCommerceProduct, que está disponível no iOS 18.4, e APIs atuais, como Transaction e SubscriptionStatus. Para saber mais sobre a API Advanced Commerce, acesse a lista de recursos da web desta sessão. Agora, vamos revisar as atualizações para o tipo RenewalInfo. O tipo RenewalInfo é específico para assinaturas de renovação automática. Ele informa se a assinatura terá renovação automática, a data da próxima renovação e, para assinantes cuja assinatura expirou, o motivo da expiração, entre outras informações. Um exemplo de como você pode usar o motivo da expiração da assinatura é se você tiver aumentado o preço do seu serviço e o motivo da expiração for didNotConsentToPriceIncrease. Esse seria um bom momento para vender uma oferta para reconquistar o cliente e incentivá-lo a voltar a assinar seu serviço. O StoreKit disponibiliza valores RenewalInfo como um membro VerificationResult encapsulado em instâncias SubscriptionStatus. Você pode obter um SubscriptionStatus de várias maneiras, como por meio da API de atualizações de SubscriptionStatus ou consultando status de assinatura no StoreKit usando um ID de grupo. Lembre-se: ao consultar status de assinatura no StoreKit usando um ID de grupo, forneça acesso ao seu serviço de app com base no SubscriptionStatus que oferece o nível de serviço mais alto, conforme descrito no seu modelo de negócios. Outra novidade do iOS 18.4 é a API SubscriptionStatus que usa um ID de transação. Agora você pode consultar status de assinatura no StoreKit usando o ID de transação de qualquer Transaction associada a uma assinatura. Este ano, introduzimos quatro campos adicionais para o tipo RenewalInfo. O campo appTransactionID foi reimplantado no iOS 15, e os campos "Período de oferta" e advancedCommerceInfo estão disponíveis desde o iOS 18.4. Também adicionamos o campo appAccountToken, que associa uma assinatura a uma conta de cliente no seu serviço. Você pode fornecer um appAccountToken no momento da compra usando a opção de compra appAccountToken. A App Store retorna esse mesmo valor no novo campo appAccountToken para o RenewalInfo associado à assinatura. Para acessar esses novos campos, basta criar seu app usando o Xcode mais recente. Acreditamos que eles vão facilitar ainda mais o desenvolvimento do seu app e ajudar você a oferecer uma experiência ainda melhor ao cliente. Agora, vou mudar o foco e falar sobre códigos de oferta. São códigos alfanuméricos que permitem oferecer assinaturas com desconto ou gratuitamente por um período específico. Os clientes podem resgatar os códigos na App Store usando URLs de resgate único ou no seu app se você implementar as APIs do StoreKit para resgate de códigos. Os códigos de oferta estão disponíveis para assinaturas consumíveis, não consumíveis e não renováveis. Os clientes podem resgatar os códigos dentro do seu app por meio da API offerCodeRedemption. Se seu app usa o UIKit, use a API presentOfferCodeRedeemSheet. O resgate de códigos para assinaturas consumíveis, não consumíveis e não renováveis está disponível desde o iOS 16.3. O Transaction gerado por um resgate de código está disponível em qualquer versão do sistema operacional usando as APIs do StoreKit 2. Se seu app for compatível com versões anteriores, os clientes poderão resgatar códigos de oferta para assinaturas de renovação automática desde o iOS 14.2. Para resgate de códigos para outros tipos de produto que não sejam assinaturas de renovação automática, introduzimos uma nova forma de pagamento no tipo Transaction.Offer.PaymentMode. Ele descreve como o cliente é cobrado ou não durante o período de oferta, dependendo do tipo de oferta. Ele representa várias formas de pagamento, incluindo casos como freeTrial, em que nenhum pagamento é necessário. As outras formas de pagamento incluem payAsYouGo e payUpFront. Agora no iOS, você tem a forma de pagamento oneTime para códigos de oferta para compras dentro do app, que está disponível desde o iOS 17.2. Se seu app for compatível com versões anteriores à 17.2, você poderá acessar essa nova forma por meio do membro offerPaymentModeStringRepresentation no Transaction, que está disponível a partir do iOS 15. Se quiser se aprofundar na configuração de códigos de oferta para compras dentro do app, confira a sessão de 2025 "Novidades no App Store Connect". Também no iOS 18.2, o StoreKit adicionou métodos de compra que exigem um contexto de interface. O app precisa especificar o contexto da interface onde a compra é feita para exibir a página de pagamento e a caixa de diálogo de transação realizada na região mais intuitiva da cena ativa do dispositivo. Esses novos métodos de compra estão disponíveis desde o iOS 18.2 e versões alinhadas. O contexto da interface fornecido varia conforme a plataforma. No iOS, Mac Catalyst, tvOS e visionOS, o contexto da interface é um UIViewController. Na macOS, é um NSWindow. Se estiver desenvolvendo apps para watchOS, não forneça o contexto da interface. Ao comprar em uma view do SwiftUI, você não realiza esse cálculo por conta própria. Em vez disso, leia o valor do ambiente de compra para obter uma instância PurchaseAction. Quando estiver tudo pronto para fazer uma compra, chame a instância PurchaseAction diretamente, pois ela define um método callAsFunction que o Swift aciona quando a instância é chamada. Se estiver usando as views do StoreKit, não se preocupe em fornecer o contexto da interface.

O sistema cuida disso para você automaticamente. Para saber como implementar a melhor experiência de compras dentro do app usando ProductView, StoreView e SubscriptionStoreView, confira a sessão "Meet StoreKit for SwiftUI" da WWDC23. Agora que exploramos os principais aprimoramentos da API, quero chamar atenção para outra atualização importante. Este ano, apresentamos novas APIs que exigem uma Assinatura Web JSON. Vamos explorá-las e mostrar como você pode usar a App Store Server Library no seu fluxo de desenvolvimento para simplificar o processo de assinatura. A partir deste ano, você pode definir a qualificação de um cliente para uma oferta introdutória usando a opção de compra introductoryOfferEligibility. Você também pode assinar suas ofertas promocionais usando o formato JWS com a nova opção de compra promotionalOffer. Essas novas opções exigem uma string JWS compacta e foram reimplantadas no iOS 15. Também introduzimos novos modificadores de view do SwiftUI para essas opções de compra. O JWS ajuda a App Store a verificar se você autorizou a compra para situações específicas, como definir a qualificação de um cliente para uma oferta promocional ou oferta introdutória. Para facilitar ao máximo a assinatura das suas solicitações, temos ótimas ferramentas de código aberto, como a App Store Server Library, que simplificam o processo. Para ver como é rápido criar solicitações assinadas para seu app, vamos conferir como assinaríamos uma oferta promocional no SKDemo. Antes de começar, primeiro você vai precisar recuperar sua chave de assinatura para compras dentro do app do App Store Connect. Para isso, acesse a aba "Usuários e acesso", clique no cabeçalho Integrações

e escolha "Compras dentro do app" no painel de navegação à esquerda. Você pode usar qualquer chave ativa ou criar uma nova. Anote o ID do emissor e o ID da sua chave de assinatura para compras dentro do app. Agora que você já tem uma chave, vamos ver a loja de assinaturas dentro do app no SKDemo. Nossa loja de assinaturas vende os planos disponíveis para compra. Quero reconquistar assinantes cujas assinaturas expiraram. Para isso, vou lançar uma oferta promocional no Plano Pro usando o novo modificador subscriptionPromotionalOffer com base em JWS. Esse modificador requer dois fechamentos. No primeiro, você fornece a oferta aplicável à compra de uma determinada assinatura. Neste exemplo, vou escolher a oferta que tem o maior período de teste gratuito para o Plano Pro usando um método auxiliar criado anteriormente. O segundo fechamento requer um JWS compacto contendo os detalhes da oferta assinada. Aqui, ele é fornecido pelo tipo NetworkLayer. Vamos ver como fica essa implementação. Em ourNetworkLayer, inserimos o productID e o ID da oferta como parâmetros de consulta para a solicitação. Depois, fazemos uma solicitação GET para a rota de assinatura da oferta no nosso servidor. Por fim, decodificamos a resposta. No seu projeto de servidor, comece adicionando a dependência de pacote Swift da App Store Server Library e importando a biblioteca. Ao implementar a rota que processa as solicitações de assinatura de oferta promocional, crie um contexto de assinatura promocional inicializando um PromotionOfferV2SignatureCreator com o ID de pacote do app, a chave de assinatura, o ID da chave e o ID do emissor obtidos no App Store Connect. Depois, chame a função createSignature e forneça o productID da assinatura que está sendo comprada e o ID da oferta. Também é recomendável incluir um valor para o campo de ID do Transaction. Esse valor pode ser o appTransactionID ou o TransactionID de qualquer Transaction que pertença ao cliente. O campo TransactionID é opcional, mas recomendamos incluí-lo.

De volta ao app, a oferta promocional agora pode ser resgatada e a compra concluída sem incidentes. E é assim que criamos solicitações assinadas de compras dentro do app usando a App Store Server Library. Assinar suas solicitações de compras dentro do app ajuda a App Store a verificar se você autorizou uma compra. A integração com a App Store Server Library facilita a assinatura das solicitações. E o melhor é que ela está disponível em quatro linguagens: Java, Python, Node.js e Swift. Para começar a usar a App Store Server Library, confira a sessão "Explorar as APIs do servidor da App Store para compras dentro do app" da WWDC24. Sobre as últimas atualizações, vamos ver uma nova maneira de usar o SwiftUI para interagir com os clientes no seu app. Apresento o novo membro da família de views do StoreKit, o SubscriptionOfferView. Essa é uma nova view do SwiftUI para comercialização e assinaturas de renovação automática criada para chamar a atenção do cliente sobre o serviço do seu app. Você declara um SubscriptionOfferView usando uma assinatura de renovação automática já carregada ou o productID de uma assinatura de renovação automática. Quando declarada dessa forma, a view carrega todos os metadados do produto da App Store. Você também pode usar a imagem da assinatura configurada no App Store Connect para decorar a view definindo o sinalizador prefersPromotionalIcon como true. O ícone decorativo é exibido quando o sistema termina de carregar os metadados da assinatura. Se preferir usar um ícone personalizado para decorar a view, use a grafia alternativa dessa API e insira um fechamento ViewBuilder à direita. Você também pode fornecer um ícone de marcador personalizado, que é mostrado enquanto os metadados são baixados do servidor da App Store. O SubscriptionOfferView pode vender mais do que um plano de assinatura individual. Quando emparelhado com o novo modificador subscriptionOfferViewDetailAction, você pode usar essa view para direcionar os clientes para sua loja de assinaturas dentro do app, por exemplo. Declarar esse modificador desenha o botão detailLink na view. Quando um cliente toca no botão detailLink, a view chama a função de fechamento do caminho para esse modificador. Aqui temos um exemplo no SKDemo. Modifiquei um estado em ContentView que controla o método de apresentação do fluxo de usuários do app. Quando o cliente toca no botão detailLink, ele é levado à loja de assinaturas do app para ver os planos disponíveis para compra. Uma consideração importante ao decidir usar essa API é qual plano de assinatura vender ou se ele deve mesmo ser exibido. Vamos voltar ao código para ver um exemplo de como usar essa API. Determine o status da assinatura do cliente para saber qual plano vender com um SubscriptionOfferView. Em apps que usam o SwiftUI, o lugar mais conveniente para fazer isso é na implementação do protocolo do app. Depois, use esses dados para informar o restante da hierarquia de view. Você pode fazer isso declarando o modificador subscriptionStatusTask introduzido no iOS 17. Em seguida, converta os status de assinatura do StoreKit nesse modificador em um modelo que seu app entenda. No SKDemo, esse modelo é chamado de SKDemoPlusStatus. Depois, atualize uma fonte de informações na sua view que rastreie um status e o disponibilize usando uma variável de ambiente.

Agora que tenho o status do cliente, vou usá-lo para exibir um SubscriptionOfferView no ContentView. Aqui, leio o valor do ambiente que contém o status do cliente e decido vender um plano padrão, se o cliente não for um assinante ativo, ou planos de nível superior, se o cliente já for assinante. Para deixar o código mais conciso, vou usar o inicializador de ID de grupo para criar meu SubscriptionOfferView. Quando declarado dessa forma, o sistema escolhe um plano do meu grupo de assinaturas. Você também vai precisar especificar a relação do plano vendido com o plano atual do cliente. O parâmetro visibleRelationship pode ser um destes cinco valores: upgrade, downgrade, crossgrade, current e all. Essa API se comporta de forma diferente dependendo do status do cliente. Vamos ver cada uma dessas relações, começando com upgrade. Para fins de demonstração, vamos supor que nosso cliente assinou um plano intermediário. Especificar o upgrade faz com que a view venda um plano de assinatura que é um nível mais alto do que o plano atual. O inverso acontece na relação downgrade. Neste exemplo, os clientes assinantes e os não assinantes veriam o mesmo plano. Você pode vender um plano mais acessível se o cliente tiver desativado a renovação automática e você quiser retê-lo antes que o ciclo de renovação termine. A opção crossgrade considera os planos do grupo cujo nível é equivalente ao do plano atual e escolhe a opção de melhor valor. Com a relação current, o plano atual do cliente é comercializado. Por padrão, todas as interações são desativadas, a menos que haja uma oferta de assinatura disponível para resgate. Você marca um cliente como qualificado para uma oferta usando um dos modificadores, como o novo modificador subscriptionPromotionalOffer e o preferredSubscriptionOffer. Um ótimo uso dessa relação é comercializar um desconto para uma assinatura prestes a expirar para reter assinantes. Por último, a relação all. Essa relação se comporta da mesma forma para todos os clientes. Quando inicializada dessa forma, a view exibe informações sobre os preços dos planos do grupo. Você fornece a ação a ser executada na view declarando o modificador subscriptionOfferViewDetailAction. Independentemente da relação usada para criar um SubscriptionOfferView, é possível decorá-lo usando um ícone personalizado e um de marcador, como no exemplo que demos antes. Também é conveniente usar o ícone do seu app. Basta definir o sinalizador useAppIcon como true. E esse foi um resumo do novo SubscriptionOfferView, uma maneira incrível de interagir com os clientes. Hoje, falei sobre vários aprimoramentos da API StoreKit que vão ajudar você a oferecer uma ótima experiência de compras dentro do app para os clientes. Para usar esses novos recursos, agora é um ótimo momento para adotar o StoreKit 2 no seu projeto, se ainda não fez isso. Para ter os designs mais recentes e criar uma excelente loja no seu app, use as views do StoreKit para promover suas compras e assinaturas dentro do app. Confira a App Store Server Library no GitHub e integre-a ao seu projeto para facilitar ao máximo a assinatura de solicitações de compras dentro do app. Para saber mais sobre APIs do servidor da App Store, temos uma nova sessão da WWDC25, "Explorar as APIs do servidor da App Store para compras dentro do app". E para começar a usar o StoreKit 2, nossa sessão da WWDC21, "Conhecer o StoreKit 2", é um excelente ponto de partida. Agradeço sua participação hoje. Mal posso esperar para ver o que você vai criar com o StoreKit.