Apple Subscriptions Notifications for iOS Tutorial. Are they really good?

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 his 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 😈

To implement Status Polling you should:

1. send and save all subscriptions receipts on your server and
2. implement quite complicated server logic. According to it you will check these receipts on regular basis.

This’s difficult. But in 2017 Apple seemed to solve this problem. In WWDC it shows Apple Subscriptions Status Update Notifications.

What are Subscriptions Notifications?

Apple Subscriptions Status Update Notifications is a way to send webhooks on your server from Apple when something happens to your subscriptions. 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.

Notification types

There are 6 different notifications you could receive from Apple. Let’s look through each of them.

INITIAL_BUY

Apple sends this notification when a user purchases a subscription at a first time in some subscriptions group.

You can read about subscriptions groups in our another article.

CANCEL

Apple sends this notification, when user cancels subscriptions through Apple Care support and refunds his 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.

DID_CHANGE_RENEWAL_STATUS

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.

RENEWAL

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 issueand…
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 analyze its expiration_date.

INTERACTIVE_RENEWAL

This notification is being sent if a user canceled his subscription and after some time re-enabled it.

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

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:

In a nutshell

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:

Notification	When it is being sent
INITIAL_BUY	Initial subscription in some subscriptions group
CANCEL	Subscription cancellation and refund through Apple Care
DID_CHANGE_RENEWAL_STATUS	Subscription cancellation or re-activation by a user
RENEWAL	Subscription cancellation due to billing issue
INTERACTIVE_RENEWAL	Subscription re-activation after its manual cancellation
DID_CHANGE_RENEWAL_PREF	Switch from one subscription to another in one subscription group

How to use Apple Subscriptions Notifications?

Because Apple doesn’t send you a real renewal event, 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 own server. The server will be a “layer” between Apple and another analytics (like Amplitude, Flurry or Mixpanel). You will check receipts and will send notifications about renewals, cancellations and refunds to analytics.

Once we faced the same problem and decided to create a service which could solve this problem. This is how Apphud was born. Apphud is iOS subscriptions analytics tool. One of its main features is sending subscriptions-based notifications to your favorite analytics tool. Apphud fills the gap in sending events from Apple, practicing a hybrid approach: we use both Subscriptions Status Polling and Apple Subscriptions Notifications to collect the most accurate information. All you need if to integrate our lightweight SDK and setup integrations. Apphud will do the rest.

The project is currently in beta. So if you would like to participate in it, visit Apphud and leave your email. That’s it! So easy!

Conclusion

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.