Non-renewing subscription with forced account

Is it allowed for my iOS application to force users to log into my custom account management system, so I can link them to my backend when they want to purchase a non-renewing subscription?


Here's the backstory: I have a non-renewing subscription. For a good amount of users I can see that the Apple receipt does not contain information about this subscription; the in_app array is empty. This is correct according to the API:

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt

For some users, I can still see the purchase in the receipt, but let's consider that a bug from Apple and follow their API documentation to the letter. (More on why this is a bug herehttps://forums.developer.apple.com/thread/22345)


In order to restore the user's purchase, I'd need something to identify him with. I could create a unique token, store that on the iCloud keychain and use that across the devices to detect the purchase belongs to that Apple account, but since my application supports account creation, I'd rather just use that mechanism. Else I'm using two different methods of purchase detection side by side: iCloud keychain token or a user account.

Thing is, I'm not sure I am allowed to force users to make an account before making a purchase. Is this something Apple would reject the app submission for with a message like "Your users must be able to buy stuff without going through your lengthy account registration process" ?

With regards to the developer forum posting <https://forums.developer.apple.com/thread/22345> this issue has since been resolved to where non-renewing subscription items are now and will remain present in the in_app array of the application receipt, until documented in the future that this will change. There is no change as to the inclusion of consumable purchase types in the applicationReceipt. When the consumable transaction is completed, the next update to the applicationReceipt will not include the consumable purchase item in the in_app array.


As to the issue at hand, an application cannot require a user to log in, however, the app can advise a user, that for purposes of restoring non-renewing subscription purchases, a login is suggested, otherwise the restore process isn't supported. As for the iCloud keychain, there is a similar restriction - "an application can use iCloud to track a non-renewing-subscription but it can’t force the user to login prior to making the purchase. iCloud login has to be optional and the app should alert the user that iCloud is required to access the subscription content from their other iOS devices - and to provide a way to register later, if users wish to have access to this content at a later time.


Please note, that I'm not App Review - so if you feel your app meets the above guidelines, but App Review rejects the application, their decision is the official one.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

The documents are ambiguous and your reference is now outdated. See:

"Important: Information about auto-renewable subscriptions, non-consumable products, and non-renewing subscriptions is added to the receipt when they are paid for and remains in the receipt indefinitely."

https://developer.apple.com/library/ios/technotes/tn2413/_index.html


Interestingly, this can lead to some fairly long extensions if the receipt is used to restore a non-renewing subscription without testing for the date of each purchase. And a correct restore-from-the-receipt requires a temporal sorting of all purchases and then advancing the expiration date over the purchases to account for overlapping renewals (i.e. first monthly subscription expires on the 25th, renewed for 10 times on the 20th, the subscription expires on the next 25th unless one of the 10 renewals was actually on the 27th) .

Non-renewing subscription with forced account
 
 
Q