Non-renew subscription and receipt?

I'm experiencing the same issue with a production app. I opened bug #23056345. Hopefully, this is a bug and not a change of policy. The specification above is very clear. And if it's a change of policy, why was no warning given? It's also hard to imagine why a change of policy would be needed in this case.

After deleting and re-creating the in-app product SKUs in iTunesConnect, I still get receipts from the Sandbox app store that do not contain persistent receipt fields for the purchase of a non-renewing subscription. The purchase shows only in the receipt received after the purchase transaction.

As a test, I added a non-consumable in-app SKU, puchased that and consistent with the above quoted documents, the non-consumable item purchase IS persisted.

Now I'm stuck again trying to understand why my current non-renewing subscription purchases do not persist in the receipt. This is blocking me completing this app and getting it into the app store review process.

Stu

As a further test, I added a new SKU for a non-renewing subscription in iTunesConnect, then purchased it from the app.

As before the purchase of the NON_CONSUMSABLE still persists in the receipt but purchases of the new non-renewable subscription do NOT.

It appears that Apple has changed the policy of what is persisted in the receipt to be consistent with the documentation about the app developer being responsible for this actions.

This document:

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html#//apple_ref/doc/uid/TP40008267-CH2-SW2

has long been in conflict with the document defining receipt fields. From this document:

Non-renewing subscriptions differ from auto-renewable subscriptions in a few key ways. These differences give your app the flexibility to implement the correct behavior for your needs, as follows:

• Your app is responsible for calculating the time period that the subscription is active and determining what content needs to be made available to the user.
• Your app is responsible for detecting that a subscription is approaching its expiration date and prompting the user to renew the subscription by purchasing the product again.
• Your app is responsible for making subscriptions available across all the user’s devices after they’re purchased and for letting users restore past purchases. For example, most subscriptions are provided by a server; your server would need some mechanism to identify users and associate subscription purchases with the user who purchased them.

Looks to me that Apple has changed the way that non-renewing subscriptions work to be consistent with this latter document and that the document describing persistence of fields in receipts in now wrong.

This is REALLY annoying.

I don't mind Apple setting their policies - its their toy box. But making a change like this apparently without annoucement is very bad.

Stu

I filed a Developer Tech Support request to request an explanation about which of the two referenced documents were correct and whether there had been a change of poilcy regarding which one was correct.

The initial response was that the first document was correct - non-renewing subscriptions were persisted in the app receipt. The person handling my reqest asked for some validation that dumped out all fields in the receipt which I provided. Again, showing that the purchases of non-renewing subsctiptions were not persisted in the receipt from the Sandbox.

First thing today I was asked to file a bug report as the developer handing my DTS confirmed what i was seeing.

Several hours later I got a follow up response that the change I was seeing was the result of a "bug fix" to the store logic and that now the SECOND document is considered the right answer. Developers are responsible for persisting non-renewing subscription status themselves and that the app receipt does not provide (as it did) a persisted record of the purchase of a non-renewing subscription.

The developer handling the case expressed surprise at this change but had confirmed the change with the AppStore development team.

So at least I now know what I have to do... although for the last three months of development after adding in-app purchases for this app using non-renewing subscriptions, the receipt information persisted all purchases.

No fuss, no muss and no annoucement of the change.

I am thankful that I learnt this BEFORE my app got approved for production and then had to deal with a bunch of unhappy customers.

Hopefully this thread saves others from the same headache.

Perhaps the App Store development team has a change of heart and reinstates this behavior but clearly there is still (without clarity across all doucment sources) a risk that the "bug" gets "fixed" again.

Stu

This is apparently a bug and, in time, the receipt will again have these purchases. They are very useful for copying the subscription from one device to another.

I contacted DTS and was instructed to do the following (I recomnmend everyone do it to raise the level of urgency):

"Please file a bug report - 'non renewing subscription in app purchase items are disappearing after the transaction completion.'

Please assign this bug report to component “iTunes Production Support” version “P2 Issue”

Add your findings and appropriate comments about this issue."

I hope you are correct but the response I received from my DTS request was far less optimistic.

I agree with filing a bug report as you describe - I also suggest a direct email to Tim Cook - his email is easily available via a Google search.

Stu

You may be correct. This may be a change in the receipt policy. In which case it is even more important to do as noted above - report it as a bug. If enough developers complain perhaps Apple will reconsider this policy change, classify it as a bug and fix it.

Thanks for the info.

We actually have noticed an increase in the number of customer tickets about missing subscriptions in the account. For the past few days, we've been getting a lot of 503's from the receipt verification API.

We're trying to re-request the verification a few times, but if it fails completely, the receipt is gone forever. This means that we'll have to add another system to store those receipts for later, but in the meantime, the customer can't access their purchased item...

Please help to return non-renewing subscription purchases to the encoded receipt by filling out a bug report as described below....Thanks!

I filed a bug report and also send an email highlighting the issue to Tim Cook.

It will be interesting to see what happens next.

Have to say this change is a real pain and I'm very surprised it was made without any annoucement or time for change.

Stu

I filed a bug report as well. I strongly feel non-renewing in-app purchases belong in the receipt. However, if they want to stop doing this, we will need the purchases restored in the receipt temporarily to move them to a separate server. Otherwise our users' purchases are gone forever, and they will be forced to ask for a refund from Apple.

FYI, we have also filed a bug report about this.

In addition to filing bug reports, I suggest the following.

• Call Apple HQ in Cupertino on the main number and ask for the Office of the President
• When one of Tim Cook's EA's answers the phone, ask for his direct FAX number
• Write a polite, professional but firm letter emphasizing the impact of this change and how it impacts Apple and our joint customers
• Ask specifically for him to investigate the change and require the AppStore/StoreKit team to reverse the change they have made AND upadte all documentation so that it is consistent, leaving non-renewable subscription receipts in bundle receipt indefinitely.
• Reference your bug report number
• Send the fax.

CEO's care about their companies and are often (like almost always) unaware of the decisions made by folks in their organizations.

This change is unacceptable and shoots lots of people including Apple in the foot.

Please take the time to do these steps.

Stu

Can you add the bug to openradar please?

I also started seeing this change of receipt behaviour towards the end of last week and assumed (incorrectly) that it was a symptom of the...<ahem>...flakiness of the App Store / iTunes Connect last week (15/16 Oct 2015)

From a user experience perspective, this is not a positive change. Even if the in-app receipt information is stored separately by an app at the point of purchase, there is no guarantee that the attempt to store the receipt will succeed due to a multitude of reasons (network connectivity, battery state, memory pressure, ...). Should that happen then the only way to support purchase restore onto a different device is to refresh the app receipt, which will now no longer recover the situation!

So from a user experience perspective they'll end up annoyed, angry with the app developer and inconvenienced trying to find-out how to request a refund.

I don't know if you've added anything about the user experience perspective to the bug report but please consider doing so as Apple are meant to be strong on user experience.

The procedure of using the user's iCloud key-value file to copy receipts to other devices (and restore it to the purchasing device) still works.