UPDATE. Since the publication of the article, Apple has significantly improved App Store Server Notifications by adding DID_RENEW notifications which is fired when subscription renewed as well as newest App Store Server Notifications V2.
So, you have the app with auto-renewable subscriptions. It works perfectly, your users purchase premium subscriptions and write amazing reviews. So cool!
As a product owner, it’s essential for you to know your app’s key metrics. One of the most important metrics is LifeTime value (LTV). This value shows how much money do you earn per user during their life cycle. But how could you calculate it in case of subscriptions? How to track when subscription renews, cancels or is being refunded?
The only way to know this until 2017 was Subscriptions Status Polling. You could receive a subscription’s info at any moment by sending its receipt to URL: https://buy.itunes.apple.com/verifyReceipt
. Once you receive it, you could view some information, including expiration date. However, it’s impossible to get subscription’s price?
For an Apple developer, subscription prices would be retrieved via status polling, as follows:
This’s difficult. But in 2017 Apple seemed to solve this problem. In WWDC it shows Apple Subscriptions Status Update Notifications. This iOS notification tutorial will show you exactly how to do it.
Apple Subscriptions Status Update Notifications is a way to send webhooks on your server from Apple when something happens to your subscriptions. You can receive Apple subscription notifications on renewal status changes, re-enabled subscriptions, and more. To enable them you should set up your server first: the server must conform to App Transport Security protocol (it usually conforms to it by default). After that you should go to App Store Connect and insert a special link at “App Store” section. Apple will send a POST
request every time when subscription-based event happens:
Note, that Apple recommends to use Status Polling in addition to Subscriptions Notifications. Not a good sign…
All set! Now you will receive notifications every time when a subscription, for example, starts or cancels.
There are 6 different notifications you could receive from Apple. Let’s look through each of them.
Apple sends this notification when a user purchases a subscription at a first time in some subscriptions group. The initial_buy notification type includes a latest_receipt field, which can be used at any time to verify the user's subscription status.
You can read about subscriptions groups here:
Apple sends this notification, when user cancels subscriptions through Apple Care support and refunds their money. Please note: this is not about the normal cancellation of a subscription through iOS settings.
Cancel
notification is not being sent if user cancels a subscription through iOS settings.
This notification was added recently. You will receive it when user cancels or re-enables a subscription through iOS settings, App Store app or Apple Support:
Do not confuse this event with the CANCEL
event, which is triggered when a subscription is canceled via Apple Care support.
The first idea when you see a name of this event: Apple sends this notification when a subscription renews. No, Apple doesn’t think so.
RENEWAL
notification is being sent if:
1. a user’s subscription was canceled automatically due to billing issue and…
2. was re-enabled again manually by a user.
In this case Apple sends RENEWAL
notification.
RENEWAL
notification is not being sent in case of usual subscription renewal. Instead of this Apple offers to check subscription’s receipt using /VerifyReceipt
before and after expecting expiration date. And analyse its expiration_date
.
This notification is being sent if a user canceled their subscription and after some time re-enabled it. The iOS interactive_renewal notification is applicable regardless of whether the customer renewed the subscription via your app's interface or through their Subscription settings in the App Store. So, it could act as an Apple in-app purchase server notification or as an app store notification.
A new subscription (which a user re-enabled) may be different from initial subscription, but both of them must be in one products group. For example, a user may cancel a subscription to Bronze plan and after some time choose Gold plan and re-enabled subscription. In this case Apple will send INTERACTIVE_RENEWAL
notification to our server (Bronze and Gold must be in one subscriptions group). You can read more about subscriptions groups here.
DID_CHANGE_RENEWAL_PREF
notification is being sent when a user switches from one subscription to another. Both subscriptions must be in our subscriptions group:
Apple offers as many as 6 events, but none of them is being sent after usual renewal? Why did they do so? Don’t know. Additionally, the names of these events are misleading.
Here is the list of all notifications:
As you can see from the App Store server notification examples above, Apple doesn’t send you a real renewal event. So, you will have to implement Status Polling to calculate LTV. Apple may add this event in the future, but even if this happens, you will still have to use your own server. The server will be a “layer” between Apple and other analytics (like Amplitude, Flurry, or Mixpanel). You will check receipts and send notifications about renewals, cancellations, and refunds to analytics.
You can use Apphud to properly track your subscriptions and get actual real-time analytics with Apple Notifiations. Start now for free!
Apple Subscriptions Notifications are not as good as they seem, because it is not possible to solve the main task with the help of them: find out how much money one user brings to you. Perhaps Apple will make life easier for developers in the future, but one thing is for sure: the current implementation of Subscriptions Notifications is not very obvious and looks like crutches.