iphone - suscripción - Borrado de las compras de la zona de pruebas de compra en la aplicación de IOS para un usuario de prueba

las compras dentro de la app estan restringidas

Question

¿Alguien tiene alguna idea sobre cómo restablecer y / o borrar el arenero de compra en la aplicación de iOS? Tengo una aplicación que estoy probando con el entorno limitado, y me gustaría probar nuevas compras sin tener que crear un nuevo usuario de prueba cada vez que compro algo. Si no hago esto, entonces (por supuesto) siempre recibo un mensaje de que el artículo de compra en la aplicación ya se ha comprado cuando hago clic en el botón de compra de mi aplicación.

Answer 1

Alternativamente, para crear una solución de usuario de prueba múltiple, puede crear múltiples pruebas en compras de aplicaciones en iTunes connect, luego no necesita cambiar una cuenta de usuario.

Answer 2

Bueno, técnicamente no necesitas eso.

Si obtiene SKPaymentTransactionStateRestored , es 100% equivalente a que la tienda de aplicaciones verifique al usuario y le otorgue la compra. Tengo un interruptor como:

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
  for( SKPaymentTransaction *purch in transactions )
  {
    switch( purch.transactionState )
    {
      case SKPaymentTransactionStateRestored:
        info( "PURCHASE RESTORE" ) ;
        // fall thru
      case SKPaymentTransactionStatePurchased:
        [[SKPaymentQueue defaultQueue] finishTransaction:purch];
        // Do regular changes to app state for this purchase,
        // register in keychain, etc.
        break ;

       //.. other cases
     }
  }
}

La cuestión de tener su aplicación lógica / recuperar la compra es simple: si está almacenando en caché las compras en llavero, elimine su llavero. Si lo está haciendo de otra manera, simplemente cambie el estado de su aplicación local para simular que el usuario nunca lo ha comprado antes. El cuadro de diálogo de solicitud de compra sigue siendo exactamente el mismo, la única diferencia es cuando perfora SÍ, le da SKPaymentTransactionStateRestored lugar de SKPaymentTransactionStatePurchased .

Answer 3

Eliminar la aplicación y volver a instalar también funciona para las pruebas de espacio aislado. Depende de la aplicación, obviamente, pero estoy probando una aplicación basada en suscripción que solo compra durante el registro en este momento, por lo que ha sido la solución más fácil.

Answer 4

Mira SimStoreKit . Es una "versión simulada del StoreKit del iPhone, para probar las UI de la tienda en el simulador de iPhone, o incluso en el dispositivo sin tener que configurar IAP en Connect".

SimStoreKit almacena las compras en los valores predeterminados del usuario bajo la clave ILSimSKTransactions . Entonces, para borrar todas las compras, puede hacer:

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"ILSimSKTransactions"]

En el simulador, simplemente puede eliminar su aplicación e instalarla de nuevo.

Utilicé con éxito SimStoreKit para depurar el frente de la tienda de mi aplicación antes de probar con la caja de arena. La belleza de esta biblioteca es que se puede configurar para usar los mismos nombres de clase que el marco StoreKit real (haciendo #define ILSimReplaceRealStoreKit 1 antes de hacer #include <ILSimStoreKit.h> ).

En los archivos fuente donde necesito acceder a StoreKit, incluyo este archivo de encabezado:

#import <TargetConditionals.h>

#if TARGET_IPHONE_SIMULATOR
    #define kILSimAllowSimulatedStoreKit 1
    #define ILSimReplaceRealStoreKit 1
    #import <ILSimStoreKit.h>
#else
    #import <StoreKit/StoreKit.h>
#endif

Esto tiene el efecto de usar SimStoreKit cuando ejecuto en el simulador y el StoreKit real cuando me ejecuto en el dispositivo.

Answer 5

No es realmente una respuesta, pero ayuda a explicar.

Pensé que, dado que el archivo debía descargarse, simplemente podría eliminarse. La función simple a continuación intenta eso (Swift 3.0):

func removeReceipt() {
    if let receiptURL = Bundle.main.appStoreReceiptURL {
        print("receipt URL: /(receiptURL)")
        do {
            try FileManager.default.removeItem(at: receiptURL)
            print("Success")
        } catch let error as NSError {
            print("ERROR: /(error.localizedDescription)")
        }
    }
}

Tengo la siguiente respuesta:

URL de recibo: file: /// private / var / mobile / Containers / Data / Application / 7A2-App-Related-Number-67 / StoreKit / sandboxReceipt

ERROR: "sandboxReceipt" no se pudo eliminar porque no tienes permiso para acceder a él.

Aunque el código muestra que extrae el recibo del paquete de la aplicación, pensó que el paquete era estático, por lo que el recibo aún podría eliminarse. Estoy seguro de que hay razones de seguridad por las cuales todo esto funciona de esta manera, así que terminé teniendo que eliminar la aplicación para (re) probar el caso de pasar de no recibo a recibo nuevo descargado.

Answer 6

No puedes hacer esto, hasta donde yo sé. El backend de sandbox funciona como una cuenta real: una vez que se compra, se compra (y, por lo tanto, puede probar la restauración). Debes hacer la mayor parte de tu desarrollo con las cosas de la tienda ajustadas, y luego cuando lo pruebes de verdad, solo espera crear varias cuentas de prueba.

Answer 7

OMI hay 3 cosas que puede hacer para que las pruebas no consumibles sean soportables:

1. Puede tener muchas cuentas de prueba asociadas a un correo electrónico. Gmail, por ejemplo, le permite agregar una cadena de "más" al correo electrónico para crear alias para una dirección : [email protected] y [email protected] ambos solo van a [email protected] . Probablemente otros anfitriones de correo electrónico hagan lo mismo. Cuando crea una cuenta de prueba, debe introducir: nombre, apellido, dirección de correo electrónico, contraseña, pregunta secreta, respuesta secreta, fecha de nacimiento y país de la tienda de iTunes. Puede poner exactamente los mismos datos (incluida la contraseña) para [email protected] y [email protected] y tendrá dos cuentas de prueba. Finalmente, en su [email protected] entrada de [email protected] , recibirá dos correos electrónicos de verificación de Apple para confirmar ambas cuentas de prueba.

2. Supongamos que tiene un producto no consumible con el ID del producto @ "Extra_Levels". En lugar de escribir @ "Extra_Levels" en todos los métodos (requestProduct, purchaseProduct, ...), simplemente escriba PRODUCT_ID1 y en algún archivo de encabezado ponga #define PRODUCT_ID1 @"Extra_Levels" (sin punto y coma), luego el preprocesador buscará PRODUCT_ID1 y sustitúyalo por @ "Extra_Levels". Luego, crear un nuevo no consumible llamado @ "Extra_Levels_01" y cambiar el #define será tan bueno como reiniciar las compras para todos los usuarios de prueba.

3. Como señaló Appsmatics, puede probar el comportamiento correcto de su código cuando compra un IAP no consumible usando primero un IAP consumible (para que el usuario de prueba pueda hacer tantas compras como sea necesario) para deshacerse de algunos errores. Por supuesto, también debe probar el código con el IAP real no consumible después de eso.

Answer 8

Simplemente siga usando la misma cuenta de prueba, restaure las compras en lugar de completar las nuevas. Después de todo, ya sea que inicie una nueva compra o restaure una anterior, SU APLICACIÓN hará lo mismo (al menos inicialmente, tal vez la interfaz de usuario se actualizará de manera diferente una vez completada). Apple es la gente que maneja las cosas de manera diferente en esas situaciones diferentes, no te preocupes por eso.

Coloque su lógica de entrega en el caso SKPaymentTransactionStateRestored dentro de la implementación de este método para probar:

- (void)paymentQueue:(SKPaymentQueue *)queue
 updatedTransactions:(NSArray *)transactions;

Luego, asegúrese de poner esa lógica de entrega en el caso SKPaymentTransactionStateComprado.

Al final, debido a que la mayoría de nosotros somos obsesivos-compulsivos en diversos grados, hagamos una prueba final con una nueva cuenta (no es un gran problema hacer una segunda para una certeza absoluta).

Lo último a tener en cuenta: considere la posición de la manzana. Si había un problema con los desarrolladores que tenían que perder tiempo creando decenas o cientos de cuentas para probar el IAP a fondo, habrían resuelto el problema. No hay ningún problema.

Answer 9

Tengo 2 en artículos de compra de la aplicación. 1 para producción. y el otro para probar cuando necesito "borrar" elimino el elemento de la aplicación en la entrada y creo uno nuevo (15 segundos en iTunes y 1 segundo para cambiar la identificación del producto en el código)

si no necesito probar "nuevo usuario", uso la producción en el elemento de la aplicación.