aplicación rechazada. Cómo rastrear suscripción no renovadora del usuario

Question

desarrollé una aplicación en la revista en línea con tipo de suscripción sin renovación.

Guía del Desarrollador de Apple decir:.

"No es apropiado para realizar un seguimiento de la suscripción mediante el UDID o de la tienda de Apple ID La suscripción debe ser rastreado con un servidor externo que se debe proporcionar a fin de ofrecer suscripción a múltiples dispositivos. Además, tenga en cuenta que no es apropiado forzar el registro del usuario para cumplir este requisito; dicho registro de usuario debe ser opcional. "

y recientemente mi aplicación fue rechazada por Apple para aquellos razones:

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 

así .. ¿Cómo puedo rastrear usuarios y también de suscripción de usuario en mi servidor con el fin de asignar el día de vencimiento correcta para las revistas? como la manzana dicho aquí https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html (en modelo de servidor de Producto)

Creo que había rechazado mi aplicación porque obligar al usuario a poner un correo electrónico válida en mi servidor con el fin de realizar un seguimiento de su suscripción.

Estoy seguro de que alguien entró en eso ... ¿Alguien tuvo los mismos problemas?

Answer 1

Usted puede tratar de este enfoque:

En la primera ejecución, los registros de aplicaciones con el servidor y volver a unique_token. Guárdelo en el servidor y el lado del cliente.
En cada compra, envíe a su servidor el unique_token y almacene la asociación entre unique_token y el producto adquirido. Si el usuario se registra con su servicio (inicie sesión & pase), envíe también unique_token y asocie directamente la identificación del producto al usuario.

Al diseñar su base de datos, tenga en cuenta que un usuario puede comprar 2 productos diferentes en 2 dispositivos diferentes, registrarse en uno de ellos y luego iniciar sesión en el otro.

Pros:

• registro no es obligatorio.
• No necesita usar UDID.

Contras:

• manera más compleja. (thx Apple)
• Si un usuario borra la aplicación sin registrar, todas las compras se pierden. Sin embargo, algunas soluciones podrían ser posibles (ex enviar al servidor también la dirección MAC de la interfaz WiFi/Bluetooth [No tengo idea si se necesita una API privada o es otra guía de Apple]]