app rejected.how to track user non-renewing subscription

Question

i developed an app for on Online Magazine with non-renewing subscription type.

Apple Developer Guide say :

" it's not appropriate to track the subscription using the UDID or the Apple Store ID. The subscription should be tracked with an external server that you should provide in order to deliver subscription to multiple devices. Additionally, please keep in mind that it is not appropriate to force user registration to meet this requirement; such user registration must be made optional. "

and i recently had my app rejected by apple for those reasons:

11.6: Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
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

so.. how can i TRACK users and also user subscription on my Server in order to assign the right expiration day for the magazines? like apple said here https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html (into Server Product Model)

i think i had rejected my app because i force the user to put a valid e-mail on my server in order to track his subscription.

i'm sure some one went into that..did anyone had the same problems?

Answer 1

You might try this approach:

On the first run, the app registers with your server and get back a unique_token. Store it on server and client side.
Upon every purchase submit to your server the unique_token and store the association between unique_token and the purchased product. If the user register with your service (login & pass) send also the unique_token and associate the product id to the user directly.

When you design your database keep in mind that a user can buy 2 different products on 2 different devices, register on one of them and then login on the other one.

Pros:

• Registration is not mandatory.
• You don't need to use UDID.

Cons:

• Way more complex. (thx Apple)
• If a user deletes the app without registering all the purchases are lost. However some workarounds might be possible (ex submit to the server also the mac address of WiFi/Bluetooth interface [I have no idea if any private api is needed or it's again someother apple guideline] )