2009-10-16 13 views
19

Tengo usuarios existentes de una aplicación paga en App Store. Me gustaría hacer la transición de la aplicación a una aplicación gratuita con funciones desbloqueables. ¿Hay alguna forma de transferir mis usuarios existentes a esta nueva versión gratuita que permite una "actualización" pagada para que los usuarios existentes sean tratados como como si ya hubieran pagado por esta actualización? O, como espero, ¿debemos mantener dos bases de código separadas a medida que avanza el desarrollo de la aplicación, en lugar de enojar a nuestros clientes existentes al obligarlos a comprar nuevamente?Transición de una aplicación paga existente a la versión gratuita con Compra en aplicación

Soy consciente de que en un principio no prolly no habrá muchas respuestas autorizadas a esta pregunta ya que Apple ha comenzado hoy en día sólo permitiendo el soporte para Compras In-App desde dentro de aplicaciones gratuitas ...

+0

Actualmente no, al igual que no hay una actualización regular. Me encantaría tener una respuesta. – JoePasq

+0

@Meltemi: Entonces, finalmente qué se ha implementado para su problema anterior. También estoy en el mismo escenario para una de mis aplicaciones. Por favor déjanos saber. – pratik

+0

¿Es posible que podamos acceder al historial de compras de la aplicación a través del código y, en función del sello de la fecha, tomar una decisión? – HariKJ

Respuesta

2

No deberías No necesita dos bases de código separadas: use conditional compilation y cree dos objetivos.

+2

Agregaría esto, y lo convertiría en una oportunidad de mercadotecnia: use una base de código con dos salidas, pero incluya algún tipo de bling o característica especial para las personas que compró la aplicación directamente que ni siquiera se desbloquea desde la versión gratuita.Eso haría que las personas que ya compraron se sientan especiales en lugar de ser súbitamente el hijastro no deseado. –

5

Una posible solución podría ser colocar el código en una nueva actualización de su aplicación paga que cambiaría el interruptor que usaría para identificar a los clientes pagos (ya sea en una lista de propiedades u otra forma). Si les da a sus clientes pagados el tiempo suficiente para actualizarse, deberían marcarse como pagados. Luego, haga que su versión paga sea la versión de actualización gratuita/pagada y elimine su versión "Lite" existente de la tienda. Los nuevos clientes deberán usar la compra en la aplicación para desbloquear la versión completa, pero se reconocerá que los clientes existentes ya pagaron.

Un problema con esto es cómo conseguir que todos sus clientes actuales actualicen a la versión intermedia que activa el conmutador "pagado" a tiempo para migrar la aplicación al modelo de actualización gratuita/pagada.

+4

Pensé en esto, pero me di cuenta de que si alguien borraba su aplicación y la reinstalaba, volvería a la versión "lite". Tal vez esto ocurra con poca frecuencia, pero me molestaría si me sucediera a mí. –

+0

Sí, creo que probablemente también quieras tener un componente del lado del servidor para esto. De esta forma, se registraría algún tipo de identificación única con un servidor para el cliente previamente pagado, y la aplicación gratuita también podría verificar esto si la copia local no se ha marcado como pagada. Sin embargo, no querrá simplemente usar una identificación de dispositivo para el identificador único, porque desea que la versión de pago pase a un nuevo dispositivo al que un usuario pueda actualizar en el futuro. Es un problema complicado. –

+0

Escribí una biblioteca simple para manejar esta https://github.com/dengzhp/FirstVersion – freestyler

5

¿hay alguna manera de saber si su aplicación se ejecutó antes? (Como los ajustes se escriben en la salida, los archivos de datos creados, fecha del sello de la primera carrera?)

si es así, se puede poner el código en su actualización como:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; 
if (nil == [defaults objectForKey:@"app_v2_has_been_run"]) { 
    if (nil == [defaults objectForKey:@"some_key_v1_makes"] { 
     // they never had v1 of your app 
    } else { 
     // they had v1 of your app, so unlock some stuff for them 
    } 
    [defaults setObject:[NSDate date] forKey:@"app_v2_has_been_run"]; // or whatever 
} 
+0

Parece una buena opción, sorprende que no haya tenido comentarios a favor o en contra. Tener un +1 –

+1

Advertencia aquí es que si el usuario reinstala (por alguna razón) o agrega un nuevo dispositivo, no tendrá este valor predeterminado. Almacenar esto en iCloud podría ser capaz de evitarlo, pero eso es lo mejor que puede hacer. –

2

Para mí, mantener dos bases de código separadas no será una buena solución, porque necesitarás mantener 2 en la compra de la aplicación (peor con la compra en la aplicación con un servidor), tal vez 2 centro de juego, y separar tu descarga (y por lo tanto menos visible) porque tal vez algún nuevo usuario comprar directamente la aplicación de pago.

Pero para cambiar la aplicación de pago a la aplicación gratuita, no tengo una buena manera de hacerlo, por la razón principal si actualiza su dispositivo, y luego lo limpia, no tendrá algo que objetar. a los primeros usuarios que paguen por ello y que tengan usuarios realmente enojados.

La mejor manera será pedirle a una base de datos de apple que sepa cuándo el usuario compra la aplicación o algo así. Si alguien sabe trucos para hacer eso, me encantará que lo comparta;)

Cuestiones relacionadas