2012-06-11 10 views
11

Estoy probando una nueva estrategia de mercado, así que voy a poner mi aplicación de 0,79 € ahora gratis, con una compra en la aplicación que desbloquea TODOS los contenidos. Tampoco quiero traicionar a los usuarios que ya lo compraron, así que pensé implementar un cheque donde quienes ya hayan comprado la aplicación, no necesiten comprar el pago en la aplicación para desbloquear todo.iOS App Fecha de compra

Mi problema es ... ¿puedo verificar cuándo se ha comprado la aplicación? ¿O tal vez hay una manera simple?

+0

Gracias por las respuestas, pero necesito algo que no ensuciará después de que el usuario eliminar la aplicación. Necesito algo como hacer que la compra en la aplicación sea "gratis" para quienes ya tienen la aplicación, de modo que pueda restaurarla si la aplicación se está eliminando. –

+0

Es * debe ser * posible (y no una violación de privacidad) para poder acceder a las versiones de la aplicación/precios de compra previamente comprados, pero la App Store es muy escasa en este aspecto (ni siquiera admite actualizaciones pagas, aunque el mensaje original "Ya compró una versión anterior de esta aplicación" sugirió la posibilidad de actualizaciones a precio reducido). El mejor consejo que tengo es [presentar una solicitud de mejora] (https://bugreport.apple.com/). –

Respuesta

4

No puede hacer esto con certeza, ya que no hay forma de comprobar si el usuario compró la aplicación porque no hay forma de preguntarle al sistema operativo sobre la fecha de instalación/compra.

Como se sugirió, puede guardarlo en el NSUserDefaults, pero si el usuario elimina la aplicación, esta información se pierde.

Uno podría guardarlo en el llavero, que no se borra si elimina la aplicación, pero el problema sigue ahí, porque si se restaura el dispositivo iOS, estas configuraciones podrían perderse.

+1

Al menos con iOS 7 esto ya no es correcto. Consulte [abajo] (http://stackoverflow.com/a/23119397/1534401) para obtener la respuesta correcta. – Frederik

+0

@Frederik Eso es cierto, pero cuando se escribió esta respuesta, era correcta. – rckoenes

+1

@rckoenes Todavía es correcto, ya que oficialmente la fecha de compra solo existe para las compras en la aplicación, no para la aplicación en sí. – Mecki

0

Suponiendo que su versión actual de la aplicación guarda el estado, en el primer lanzamiento de la próxima versión de la aplicación, puede verificar cualquier estado guardado (por ejemplo, una clave en NSUserDefaults, un archivo en el directorio de documentos, etc.)

Sin embargo, solo debe hacer esto una vez, por lo que debe tener otra bandera en otro lugar para informarle que la verificación se ha realizado.

+3

mh, pero ¿qué sucede cuando el usuario elimina y vuelve a instalar la aplicación? – Pfitz

+0

Sí, buen punto ... Y también, su fecha de compra puede no ser la fecha en que abren por primera vez la aplicación – MCKapur

1

rckoenes explicación es correcta. He pasado por ese escenario últimamente y he considerado las opciones mencionadas en las respuestas aquí. La opción con la que termino es lanzar otra extensión de la aplicación (como 'pro' o 'lite', etc.) en lugar de una versión de la aplicación existente. Eso cortaría todas las molestias de manejar el estado de compra de su aplicación. Luego, tendrías una versión de pago completa de la aplicación con todo el contenido premium y una versión gratuita con compras en la aplicación para desbloquear el contenido. Espero que eso ayude.

+0

Ya probé la forma de 2 aplicaciones, pero la aplicación fue rechazada porque "ya no se puede hacer más, pero hay que implementar la compra en la aplicación". Y, por cierto, no me gusta mucho tener 2 aplicaciones que necesiten las mismas actualizaciones ... –

+0

Puede haber algo omitido. Debería haber una diferencia en el nombre. El modelo de la aplicación 2 es solo una cuestión de elección, supongo. Si navega por la tienda un poco, sabrá que casi todos los juegos/aplicaciones populares usan el mismo modelo. y para las actualizaciones puede manejarlo desarrollando la aplicación como único, no como dos, proyecte e implemente su lógica sobre la base de algunas directivas de definición sorta. De todas formas, así es como manejé las cosas, me gustaría saber cómo lo harías eventualmente. – Ahmed

+0

Sí ... estoy pensando en una manera fácil y más amigable. Gracias de todos modos por el consejo :-) –

-1

Esto debería ser bastante sencillo. Si sabe cuándo entra en funcionamiento su nueva aplicación, simplemente verifique la fecha/hora de instalación (almacene la fecha/hora en el llavero al ejecutar por primera vez). Los usuarios que instalaron la aplicación antes de la fecha/hora en que entró en funcionamiento su aplicación gratuita pueden acceder al contenido. Si le preocupa que los nuevos usuarios se equivoquen con la fecha/hora, use un servicio de tiempo en línea para obtener el tiempo real.

7

solo para actualizar esto, ES posible. Echar un vistazo a la respuesta a esta pregunta - uno de los campos en el recibo es "fecha de compra"

A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7

+2

La fecha de compra original es solo un campo para las entradas IAP, no existe para la aplicación en sí. La fecha de compra de la aplicación también se encuentra en la recepción de una aplicación, pero no está documentada. – Mecki

+0

¡Ooops! Creo que estaba confundiendo la "Versión de la aplicación original" (que está en el nivel de la aplicación) con la "Fecha de compra original" que (como ha señalado) está dentro de los datos IAP –

+0

@Mecki ¿Qué ocurre con la "Fecha de creación del recibo"? Se puede usar como fecha de compra de la aplicación – derpoliuk

Cuestiones relacionadas