How to implement non-renewing subscription in iOS?

Question

iOS

It is necessary to implement a subscription inside the iOS product for access to the feature. Since it is most likely impossible to use an auto-renewable subscription (strict restriction on the subscription content type), it was decided to use the second non-renewing type. But here's the problem - how and where to save information about the subscription period, as well as how to synchronize active subscriptions between devices?
Locally save the time and compare it with the system time - this costs a banal permutation of the system time and is not an option.
Apple does not provide a mechanism for renewing non-renewing subscriptions, nor for checking the status (expiration date) of a subscription.
Is it necessary to make a user registration / authorization form, or can I somehow get by with an iCloud entry? Is it possible to use e-mail in case of authorization and registration? What information is better to store in iCloud and transfer to your server?
In general, I'm interested in how all this can be done and not get rejected from apple when considering an application. I don’t want to mess around with accounts much, but you can make a simple API from the server, but here’s what exactly ... There are a lot of requests on stackoverflow on similar issues, but I still haven’t found a consensus on this matter, sometimes apple allows some decisions, others have the same decisions, in general, a complete mess.
I would be very grateful if someone shares practical information on how all this can be implemented, a scheme, maybe using the example of their applications.
PS: I came across articles on working with in app on Habré, but I did not find the details and logic of how the server + client works with such subscriptions.

Answer 1

Won't wrap. But it’s better to do it with the server part, firstly, the purchase itself can be protected from breakers, and secondly, the subscription period can be controlled. When subscribing, generate a UUID, send it to the server along with the purchase and save it in iCloud KVS, then you will use this UUID to check the subscription through the server.

Answer 2

I made the following subscriptions:
1 own server
2 saving is done by sending a purchase recipe + mac device
3 restoration by request to the API with sending a poppy
4 registration is not required (Apple requirement), but you need to warn the user that you need to register if you want to restore on another device

Answer 3

Recovery is possible only if the user registers or is the mac address enough to send?
If the user first bought a subscription, and then wants to link the purchase to the account, then he, accordingly, has no chance?

Answer 4

And what about if you do it without registration / authorization, but only through iCloud synchronization, will it turn apple or not?

Answer 5

I read iCloud can be turned off. It is then necessary to make a warning as a minimum to enable iCloud for sharing subscriptions. It turns out that you need to store the last UUID (or md5 from receipt) of the purchase in iCloud, and when requesting the subscription status from the server, check by this UUID (whether it is in the database). At the same time, you need to store the recipient locally until the purchase verification request is executed on the server. You never know, the Internet may disappear, the program will freeze and the purchase transaction will be lost. Am I understanding everything correctly? Lots of subtleties can come up

Answer 6

There was a difficulty in checking the receipt for mac os x.
I take it like this:
NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
if([[NSFileManager defaultManager] fileExistsAtPath:[receiptURL path]]){
NSData *receiptData = [NSData dataWithContentsOfURL:receiptURL];
} , but convert to a dictionary, like I can for iOS.
It feels like it has a completely different format.
Has anyone done a purchase check for mac?