- We have some doubts about how we can manage the subscription in our iOS application?
Since you use your own user management system, you must maintain the status of the subscription associated with the user in your database. When the user creates a purchase in the application, the application must send this receipt to your API, which then proceeds to check it .
After saving, start the scheduled process to start the expiration date of the subscription to update the record and to infinity until the expiration date in the future.
Your application should request your API when a user opens the application to determine the status of their subscription. Do not rely on the receipt locally in the application, as your user devices will not be associated with this purchase.
- How do the device settings reflect our 4 application purchase options for updating and unifying the form of one option for another?
If all products listed on iTunes Connect have the same “subscription family”, they will appear on the “Subscribe Management” page in the iTunes user account.
When the user switches between products, a transaction will be created, and the SKPaymentQueue event will be added to SKPaymentTransactionStatePurchased . This will be a new transaction with the same Original Transaction ID as the first purchase made with a product from the same subscription family with a Product ID reflecting the new product.
For this reason, you want your transaction watcher in your background application to receive new transactions. When a new transaction is received, you can: a) send the entire receipt to your API or b) inform your API that a new transaction has been received and re-confirm the receipt that has been saved.
Switching from (a) can become problematic, as receipts will become larger over time, requiring more bandwidth from the user each time.
Switching from (b) also has its drawbacks, because you may run into problems with extreme cases such as a user switching iTunes accounts. The solution for this is to save the identifierForVendor applications with the receipt and it is required that the application send the entire receipt if it does not match. In most cases, you will simply inform the API that a transaction has occurred, and in a few cases when the identifier does not match, it will send a new receipt.
- What attention should we give to care as an iOS developer to restore an automatic renewable subscription? we did not understand the possible scenario, if a user tries to restore an iTunes account with several user accounts in our application, what warnings can we take care of which apple resolves when a user purchases a subscription once and tries to restore it on several user accounts?
Upon recovery, a new transaction will be created with a new transaction identifier, the original transaction identifier will be the same. If you create a transaction table in your database, you can ensure the transaction, and its initial transaction is tied to only one user, which does not allow users to restore purchases on other devices by another user and gain access to the subscription.
The restored transaction will be transferred to the queue using SKPaymentTransactionStateRestored , and therefore, when this happens, I advise you to send the receipt to your API and process the receipt as usual; linking any new transactions to the original user.
- Will Apple Reject Family Sharing Option Using Auto Renewable Subscription Option?
I doubt it, but I am not an Apple, so do not dare the word for the Gospel. Spotify has a similar scheme called " Spotify Family , where a user can share their Spotify account with their family, not sure if this is enabled for their iTunes app, though.
- What are the points that we need to take care of our end, which the apple will not process if we can use the above functions?
- You need your own user management API and family association.
- Your users need to log in / register in their application.
- You will need to prohibit purchases to family members if their parent account already has a purchase.
- Persistent receipts and ForVendor identifier in the database.
- Acknowledgment of receipt of checks using the validation API .
- Save the transaction table and consider this table self-referencing so that the transaction can belong to the original transaction through
original_transaction_id . Make sure the transaction_id column is unique. - Check the receipt every time a transaction is to be extended.
- What are the possibilities of breaking Apple’s rules and rejecting apps if we use the above features with an iOS app?
I do not see anything in the guidelines , with the exception of section 17.2 :
Applications that require users to share personal information such as email address and date of birth in order to function will be rejected.
I think this is a bit controversial, as 17.5 says:
Applications that include account registration or access to an existing user account must include a privacy policy or be rejected
I assume that this means that the user should be able to use the application without requiring registration, but I know many examples of applications that do just that.