iOS 15 introduces tons of new subscription and IAP capabilties including refunds, customer support, StoreKit 2, new server APIs and server notifications, and more.
The introduction of iOS 15 is bringing many new updates to in-app purchases and subscriptions, including StoreKit 2, Server Notifications v2, new server-side APIs, customer refunds, signed transactions, in-app events, new customer support capabilities, and new sandbox testing options. It was a huge week at Apple’s WWDC 21 for subscription and in-app purchase news. Tons of updates are coming this year to help make it even easier to sell subscriptions and IAPs in your apps. Below we’ll look at the highlights of the various announcements, how they might impact your apps, and how Nami works with all the latest and greatest tools from Apple.
Refunds
Let’s start with refunds as this was the single biggest announcement that offers new capabilities to app publishers to help create and maintain happy customers.
Apple had 2 big announcements here:
You will be able to start a refund process directly in your app
You’ll be able to start a refund process with a new server-side API
Starting a refund request in your app is very simple, there’s a new StoreKit method beginRefundRequest(). This will launch an Apple-controlled UI that collects a reason for the refund request.
Note that the request still goes to Apple for review and then they make a decision and let the customer know, the refund is not instantaneous.
Another new interesting feature is Apple has already started sending a new CONSUMPTION_REQUEST server notification. This is a request for information about whether the customer has made use of their consumable IAP to help in making a decision on a refund request. For apps that sell consumable purchases, this will be a very important request to respond to.
Customer support on the App Store has always been tricky because Apple did not have any tools to help app developers look up a particular customer record or transaction. They’ve now introduced a new server-side API that will enable building tools to help you look up customer records. It is all triggered from the Invoice ID that the customer receives via email for each purchase (and each renewal of an auto-renewable subscription).
The only challenge here is that this ID is only available to the customer and not to the app developer, so you can’t pre-build and store this type of information in advance. It will only be provided by the customer when they reach out to your customer service.
Signed Transactions
There are a number of updates included in what Apple is calling Signed Transactions, which are an update to the existing Apple receipt. We won’t get into the technical details of working with Signed Transactions in this article but look for some coverage from us soon to help you understand how to work with these new elements. These new transactions are signed using JSON Web Signature (JWS) and you’ll have to decode them to validate and check the data contained within.
Perhaps the single most important part of Signed Transactions is you can now directly verify a purchase in your app on-device without having a server that talks to Apple to verify the receipt. This requirement was often a barrier to app developers and is a big simplification for fighting against fraud in your app.
A couple of other interesting notes:
Data elements are now actually integers and booleans instead of everything being a string, which should make them easier to work with
Data payload is now a JSON instead of the custom receipt format, making parsing much simpler
It seems Apple has gotten rid of the odd time format used in the receipt payload that looks like UTC but is actually something different. Also, there were some timestamps that were in different time zones as well as different formats. You can find full details on what this looks like in receipt payloads here if you happen to be curious.
StoreKit 2
iOS 15 is bringing big changes to Swift in general and the StoreKit framework in particular. Most notably is the introduction of Swift Concurrency which is heavily used in the new StoreKit 2 framework.
In addition to simplifying how you work with receipts using the new Signed Transactions discussed in the last section, there are a few new capabilities that are coming with StoreKit 2
Easier access to products
Simplifying how to make a purchase
New ways to handle app accounts
On-device purchase validation
Let’s look at a few simple examples here. In the new StoreKit you no longer have to work through SKProductRequest. Getting a product is as simple as:
To then purchase that product, you can make the following call:
Finally, to verify the purchase on-device you can:
Pretty simple! There’s a lot more you can do with StoreKit 2, but this simple set of a couple of examples really highlights the power and simplicity o the new APIs.
The other big capability we mentioned above is to help you if your app has accounts. You can now create an App Account Token that is a UUID that Apple will tie to the purchase for you.
Simply add this App Account Token to the purchase and it will show up in any method where you access purchases as well as in the Signed Transactions. This greatly simplifies how you manage access to purchases when you have an app account. In StoreKit 1, all this logic has to be custom-built on your server.
Apple announced a number of new server-side APIs. Here’s a full list:
Consumption - provide data on consumable IAP usage to help Apple make a decision on a refund request
In-App Purchase History - Get a list of Signed Transactions for all purchase the user has made
Invoice Lookup - takes the order ID from their emailed invoice and returns if the ID is valid and any associated Signed Transactions
Refunded Purchases - takes the original transaction ID and returns a list of Signed Transactions for any purchases that have been refunded
Renewal Extension - allows you to extend the current bill term of a subscription by up to 90 days. Used to issue refunds or credits on subscriptions
Subscription Status - Check the status of a subscription at any time with the original transaction ID
Server Notifications v2
There was a lot of news here if you maintain the server-side portion of Apple’s in-app purchase system for your app. There were 2 big pieces of news here:
Apple is adding both new events and a new field called substate. The combination of a single server notification and its substate is now supposed to have a 1:1 mapping to an actual customer lifecycle event.
The notification payload will include the Signed Transaction so that a separate call to Apple is not needed to interpret the notification.
As many of you will know, the existing Server Notifications from Apple do not have a 1:1 mapping to subscription lifecycle events. In some cases, multiple events are sent that have to be interpreted in combination to understand what has happened. Additionally, you always have to make an additional API call to Apple to get the latest receipt which is required to determine the lifecycle state of the customer.
List of Server Notifications types in available in version 1 and version 2.
In addition to these big changes, a few other items were announced:
As mentioned above, a new CONSUMPTION_REQUEST notification that requires a response be sent back to Apple’s servers has been introduced as part of the new refund process
New Server notifications will also be sent for Family Subscriptions
The new family notifications will be sent in both v1 and v2 versions of Server notifications. Different notifications will be available in each version.
In a very exciting announcement from Apple, they now support In-App Events. In-app events will be promoted and searchable on the App Store. Events can require specific in-app purchases or subscriptions to access and may contain a deep link to take you directly to the specific event page in your app.
If you plan to create in-app events for your app, you can use Nami Paywalls to help gate access to your in-app events. Simply create an Entitlement that grants access to the event and when deep linking to the screen for the event, check the entitlement status with the Nami SDK. If the user does not have the correct entitlement, display a paywall created with our cloud Paywall Creator to ask them to make the purchase to grant access.
This is a great new feature to help create value in your app for your paying customers. We are looking forward to seeing how different apps use this in the future.
What changes for Nami?
The great news here is that most of these updates only require some internal changes to our platform, and do not affect how you as a developer use Nami.
Nami also helps to solve the challenge of leveraging iOS 15 only features in apps that still have a large install base on iOS 14 as we’ll be supporting both frameworks in our SDK.
We are excited about the new IAP use cases around in-app events that you’ll be able to enable with Nami and will be working to seamlessly integrate the new refund capabilities with our existing Customer Support tools.
Excited about testing out StoreKit 2 code yourself? Did you know Nami can run along-side a custom-written StoreKit implementation. You can still leverage all the great tools on the Nami platform and use your own StoreKit code. Reach out to us to learn more.
Kendall Gelner is a Senior iOS Engineer at Fieldwire. Previous, he was the founding iOS Architect at Nami ML. He is well regarded in the iOS development community for his technical knowledge and platform experience going back to the App Store launch. The last SDK Kendall was responsible for shipped inside of some of the most widely installed apps, reaching more than 200 million devices.
Sign up to our newsletter
Get the latest articles delivered straight to your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
