iOS: In App Purchase managing multiple auto-renewable subscriptions with upgrade and down grade option

Question

We are developing one iOS application for iPhone which will free features as well app will have premium features with 4 in app purchase auto-renewable subscription options a

Answer 1

1. We have some doubts how we can manage the subscription in our iOS application?

Because you are using your own user management system, you should persist the state of a subscription associated to the user in your database. When the user creates a purchase in the app, the app should send this receipt on to your API which will then proceed to validate it.

Once persisted, enqueue a scheduled process to run on the Subscription Expiration Date to update the record and ad infinitum until the expiration date is no longer in the future.

Your app should query your API when the user opens the app to determine their subscription status. Don't rely on the receipt locally in the app as your user's family member devices will not have this purchase associated.

2. How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?

If all products listed in iTunes Connect are of the same "Subscription Family", they will appear in the Subscription Management page in the users iTunes account.

When a user switches between products a transaction will be created and a SKPaymentTransactionStatePurchased event will be added to the SKPaymentQueue. This will be a new transaction with the same Original Transaction Identifier as the first purchase made with a product from the same Subscription Family with the Product Identifier reflecting the new product.

For this reason, you want to have your transaction observer in your app running in the background to receive any new transactions. When a new transaction is received you can either a) send the whole receipt to your API or b) inform your API that a new transaction has been received and re-validate the receipt that was persisted.

Going with (a) may become problematic as the receipts will become larger over time requiring more bandwidth from the user each time.

Going with (b) also has it's drawbacks because you can get into trouble with edge cases like the user switching iTunes accounts. A solution for this is to store the apps identifierForVendor with the receipt, and require the app to send the whole receipt if it does not match. Most of the time you will just be informing the API that a transaction has occurred, and on the few occasions that the identifier doesn't match it will send along a new receipt.

3. What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?

When restoring, a new transaction with a new transaction ID will be created, the original transaction ID will be the same though. If you create a transactions table in your database, you can ensure a transaction and it's original transaction is only ever associated to a single user, thus preventing users restoring purchases on other devices with a different user and gaining access to the subscription.

A restored transaction will be pushed onto the queue with SKPaymentTransactionStateRestored and so when this happens simply I advise sending the receipt to your API and process the receipt normally; associating any new transactions to the original user.

4. Apple will reject custom family sharing option using auto renewable subscription option?

I doubt it, but I am not Apple so don't take my word for gospel. Spotify have 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.

5. What are the points we need to take care at our end which apple will not handle if we can go with above features?

1. You need your own API with user management and family association
2. Your users need to sign-in/register on your app
3. You will need to prevent family users from purchasing if their parent account already has a purchase.
4. Persist receipts and the identifierForVendor in the database.
5. Handle receipt validations using the validation API.
6. Persist a table of transactions and consider this table self-referential so that a transaction can belong to an original transaction through the original_transaction_id. Ensure the transaction_id column is unique.
7. Validate the receipt each time a transaction is due for renewal.

6. What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?

I see nothing in the guidelines except for section 17.2:

Apps 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 one is a little contradictory, since in 17.5 it states:

Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected

I guess by this, it means a user must be able to use the app without requiring registration, but I know of many examples of apps that do exactly this.