Limpando compras da sandbox de compra no aplicativo iOS para um usuário de teste

Alguém tem alguma ideia sobre como redefinir e / ou limpar a sandbox de compra no aplicativo iOS?

Tenho um aplicativo que estou testando com o sandbox e gostaria de testar novas compras sem ter que criar um novo usuário de teste sempre que compro algo.

Se eu não fizer isso, então (é claro) sempre recebo uma mensagem de que o item de compra no aplicativo já foi comprado quando clico no botão de compra do meu aplicativo.

IMO, existem 3 coisas que você pode fazer para tornar os testes de não consumíveis suportáveis:

1. Você pode ter várias contas de teste associadas a um e-mail. O Gmail, por exemplo, permite que você adicione uma string "mais" ao e - mail para criar aliases para um endereço : então, tester+01@gmail.come tester+02@gmail.comambos vão para tester@gmail.com. Provavelmente, outros hosts de e-mail fazem o mesmo. Ao criar uma conta de teste, você precisa apresentar: nome, sobrenome, endereço de e-mail, senha, pergunta secreta, resposta secreta, data de nascimento e país da loja iTunes. Você pode colocar exatamente os mesmos dados (incluindo senha) para tester+01@gmail.come tester+02@gmail.come você terá duas contas de teste. Por fim, em sua tester@gmail.comcaixa de entrada, você receberá dois e-mails de verificação da Apple para confirmar as duas contas de teste.

2. Digamos que você tenha um não consumível com ID do produto @ "Extra_Levels". Em vez de escrever @ "Extra_Levels" em todos os métodos (requestProduct, purchaseProduct, ...), basta escrever PRODUCT_ID1e colocar algum arquivo de cabeçalho #define PRODUCT_ID1 @"Extra_Levels"(sem ponto-e-vírgula!), Então o pré-processador irá pesquisar PRODUCT_ID1 e substituí-lo por @ "Extra_Levels". Então, criar um novo não consumível chamado @ "Extra_Levels_01" e alterar o #define será tão bom quanto redefinir as compras para todos os seus usuários de teste.

3. Como o appsmatics apontou, você pode testar o comportamento correto do seu código ao comprar um IAP não consumível usando primeiro um IAP consumível (para que o usuário de teste possa fazer quantas compras forem necessárias) para se livrar de alguns bugs. Obviamente, você também deve testar o código com o IAP não consumível real depois disso.

Você não pode fazer isso, pelo que eu sei. O back-end do sandbox funciona como uma conta real - depois de comprado, é comprado (e, portanto, você pode testar a restauração). Você deve fazer a maior parte do seu desenvolvimento com o material da loja corrigido e, então, quando começar a testá-lo de verdade, espere criar várias contas de teste.

Tenho 2 itens de compra no aplicativo. 1 para produção. e o outro para teste. quando preciso "limpar", excluo o item no aplicativo e crio um novo (15 segundos no iTunes Connect e 1 segundo para alterar a id do produto no código)

se eu não precisar testar o "novo usuário", uso o item de produção no aplicativo.

Bem, tecnicamente você não precisa disso.

Se você conseguir SKPaymentTransactionStateRestored, é 100% equivalente à app store verificando o usuário e concedendo-lhe a compra. Eu tenho um switch 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
     }
  }
}

A questão de ter sua lógica de aplicativo / retomar a compra é simples: se você estiver armazenando compras em cache, exclua suas chaves. Se você estiver fazendo de outra forma, apenas altere o estado do aplicativo local para fingir que o usuário nunca o comprou antes. O diálogo de solicitação de compra ainda é exatamente o mesmo, a única diferença é quando você digita SIM, ele dá a você em SKPaymentTransactionStateRestoredvez de SKPaymentTransactionStatePurchased.

Excluir seu aplicativo e reinstalar também funciona para testes de sandbox. Depende do aplicativo, obviamente, mas estou testando um aplicativo baseado em assinatura que só compra durante a inscrição no momento, então tem sido a solução mais fácil.

Verificação de saída SimStoreKit . É uma "versão simulada do StoreKit do iPhone, para testar IUs da loja no simulador do iPhone, ou mesmo no dispositivo sem ter que configurar o IAP no Connect".

O SimStoreKit armazena as compras nos padrões do usuário sob a chave ILSimSKTransactions. Portanto, para limpar todas as compras, você pode fazer:

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

No simulador, você pode simplesmente remover seu aplicativo e instalá-lo novamente.

Usei com sucesso o SimStoreKit para depurar a fachada da loja do meu aplicativo antes de testar com a sandbox. A beleza desta biblioteca é que ela pode ser configurada para usar os mesmos nomes de classe que o framework StoreKit real (fazendo #define ILSimReplaceRealStoreKit 1antes de fazer#include <ILSimStoreKit.h> ).

Nos arquivos de origem em que preciso acessar o StoreKit, incluo este arquivo de cabeçalho:

#import <TargetConditionals.h>

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

Isso tem o efeito de usar o SimStoreKit quando executo no simulador e o StoreKit real quando executo no dispositivo.

alternativamente, para criar uma solução de vários usuários de teste, você pode criar vários testes em compras de aplicativos no iTunes Connect e, em seguida, não precisa alterar uma conta de usuário.

Continue usando a mesma conta de teste, restaurando compras em vez de concluir novas. Afinal, quer você inicie uma nova compra ou restaure uma antiga, SEU APP fará a mesma coisa (pelo menos inicialmente, talvez a interface do usuário seja atualizada de forma diferente após a conclusão). A Apple é quem está lidando com as coisas de forma diferente nessas diferentes situações - não se preocupe com isso.

Coloque sua lógica de entrega no caso SKPaymentTransactionStateRestored dentro da implementação deste método para teste:

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

Em seguida, certifique-se de colocar essa lógica de entrega no caso SKPaymentTransactionStatePurchased.

No final, como a maioria de nós é obsessivo-compulsiva em vários graus, faça um teste final com uma nova conta (não é grande coisa fazer uma segunda para certeza absoluta).

A última coisa a observar: considere a posição da apple. Se houvesse um problema com os desenvolvedores perdendo tempo criando dezenas ou centenas de contas para testar o IAP completamente, eles teriam resolvido o problema. Não tem problema.