I'm starting to work on adding a auto-renewable subscription in my app to unlock certain features. I understand the StoreKit and iTC details, but one thing that's not clear to me is *why* we need to do receipt validation for in-app purchases? There seems to be a lot of empasis on doing this, and it gets complicated because you need to either import different libraries to do this client-side (which isn't the recommended option) or do it server-side, which adds a lot of overhead. In my case, I don't have any server running at all, and my whole app relies on CloudKit instead.
So I'm wondering why it's so essential in case of IAP.
a) if it's for preventing piracy, shouldn't that apply to paid-apps as well? But no one talks about reciept validation for paid-up-front apps.
b) when StoreKit's paymentQueue "updatedTransactions" delegate tells us that someone has purchased an IAP, is that something that can be spoofed? I would imagine not, and even so, this would only be possible with jailbroken devices. Is that what people are worried about? How much of a problem is this in the real world?
c) is there certain information in the reciept that is essential for subscriptions to work correctly?
In my mind, the simplest implementation would be this: display the IAP products, implement the storekit delegate to see when the user purchased the product and mark that user's CloudKit "User" record with the type and date of subscription (this can also be used to restore the IAP on another device) and unlock the features. When the next billing cycle comes, I can wait for StoreKit to tell me whether the user cancelled or continued the subscription, and lock/unlock the feature accordingly. I don't see the necessity of receipt validation in this case. But I might be wrong and misguided about my assumptions.
Would love some comments about this.