Mesmo aqui. Alguém pode ajudar?

Não pendurado, mas retorna []

Para nós, a caixa de diálogo de compra é exibida e o ouvinte de compra é chamado corretamente, mas a chamada requestSubscription retorna uma promessa que nunca é resolvida.

Parece que isso pode ter sido resolvido aqui https://github.com/dooboolab/react-native-iap/pull/1064

Eu apliquei essa correção de promessa anteriormente, então esse não é o problema aqui.

Funciona para mim com iOS14, eis como fiz:
// request purchase, listener registered above will receive notification when processing done RNIap.requestSubscription(this.productIds[0]).catch(err => { console.log(err.code, err.message); });

Estava chamando o método com o parâmetro booleano false, que acho que é a recomendação. Eu removi isso e ainda estou vendo um comportamento muito estranho no iOS14, não importa como eu chamo o método, e ele funciona bem em um iPhone e iPad executando iOS 13 via TestFlight. Testei requestSubscription com e sem o booleano e nunca estou recebendo as caixas de diálogo de compra no iOS 14. Agora, na maioria das vezes, ele chama RequestUpdatedListener imediatamente com o que parece um recibo inválido.

Existem outras pessoas que não estão tendo problemas com suas assinaturas no iOS14 e xCode 12 usando TestFlight?

Ei, algum de vocês usa getPurchaseHistory() ou getAvailablePurchases() antes de requestSubscription() ? em caso afirmativo, esse parece ser o problema no iOS 14.

Eu obtenho getAvailablePurchases () no início do fluxo - no carregamento do aplicativo, a tela logo antes da minha tela de assinatura.

sim, infelizmente isso parece ser um bug no iOS 14. Não é culpa deste plugin. Verifiquei o código nativo e é o mesmo problema.

Esse era o problema. Removi a chamada para getAvailablePurchases () e os pop-ups de compra ocorreram e a compra foi bem-sucedida. Infelizmente, preciso fazer essa chamada para getAvailablePurchases, pois verifico o status de sua assinatura no App Load. Então, parece que precisamos esperar por um patch do iOS 14 para corrigir isso? Nada mais que alguém possa fazer? A propósito, muito obrigado theDev23!

De nada, the-dut. Sua melhor aposta é provavelmente confiar em uma verificação baseada no servidor.

Eu esperava evitar que um servidor fizesse isso. É tão fácil quanto copiar o código da minha reação em algo como um Firebase Cloud Function? Ou isso é algo que precisa ser redesenhado? Provavelmente uma pergunta idiota, mas hey .. todos nós começamos fazendo perguntas idiotas. :)

@ the-dut Você pode usar iaphub para cuidar da validação do recibo do servidor

Bebida de sua escolha se você estiver no meio-oeste dos EUA. :)

O mesmo problema aqui afeta os usuários ao vivo. @ theDev23 você tem um link para alguma discussão sobre o problema no iOS? Existe algum cronograma para uma correção?

@nicknjpconsultingllc sem link, desculpe. Eu mesma fiz a escavação.

@ the-dut, também estou usando o Firebase Cloud Functions. Confira este repo .

Acabei salvando o recibo em um banco de dados na compra bem-sucedida no purchaseUpdatedListener, então, ao carregar o aplicativo, pego o recibo do banco de dados, valido novamente e verifico se ele expirou ou não. Isso me permitiu livrar-me da chamada para getAvailablePurchases () se ela funcionar muito bem no iOS14. Funcionou muito bem até agora e é muito mais rápido. Agora uma pergunta sobre o quão longe eu preciso levar isso. Se isso for tudo o que faço, o UpdatedPurchaseListener será chamado em todas as atualizações da assinatura (basicamente as renovações automáticas) até que eu conclua as transações? Ou preciso implementar as notificações de servidor para servidor para me informar sobre as renovações automáticas? Quase parece que usar o UpdatedPurchaseListener é uma solução melhor (e mais simples), pois tenho lido que a integração de servidor para servidor não é perfeita.

Ainda estou tendo esse problema após remover getPurchaseHistory e aplicar a correção de promessa. Não consigo fazer a caixa de diálogo de compra aparecer. Alguém pode ajudar?

Eu diria que dá uma olhada em qualquer / todas as ligações que você está fazendo para o AIP antes de fazer a solicitação de compra. Você está chamando getAvailablePurchases () também?

Não posso excluir as chamadas para getAvailablePurchases () e getPurchaseHistory (). Há alguma maneira de fazer com que requestSubscription () apareça o menu de compra com essas chamadas?

Olá @ HamzaIkram2727 , se não estou errado, você pode simplesmente criar uma nova conta sandbox para usar e excluir a antiga. Deve funcionar.

@ the-dut Mesmo que eu não esteja usando nenhuma chamada getAvailablePurchases () e getPurchaseHistory (), ainda estou enfrentando o mesmo problema. Não mostra a caixa de diálogo de compra, mas o sucesso da compra é automático.

Também estou chamando as funções finishTrsanactionIOS e finishTransation

Consegui obter o diálogo de compra nativo do iOS ao sair do aplicativo. Isso me parece algumas promessas finalmente resolvidas. Não tenho certeza se existe alguma dependência de promessa em react-native-iap mas o comportamento parece estranho. Chamar requestSubscription resolve no aplicativo, mas não há diálogo até que eu saia do aplicativo.

Estou tendo o mesmo problema com getAvailblePruchases (), na maioria das vezes a promessa não resolve ou rejeita. Isso começou a acontecer durante o teste em dispositivos iOS 14.

Estou tendo o mesmo problema

1. Eu chamo getAvailablePurchases ()
2. requestSubscription ()

Removi getAvailablePurchase e aparentemente funciona bem

Alguma atualização?

Comportamento muito estranho e pelo que estou percebendo não é só no iOS 14 que isso acontece ... Estou entrando em contato com a apple para tentar entender o que está acontecendo pq não acho que seja um problema relacionado com a embalagem dele auto.

Estou aqui apenas para dizer que estou enfrentando o mesmo problema. Já testei no iOS 12 e está funcionando bem ... iOS 14 tem bugs.

Minha chamada de requestSubscription dura para sempre ... E está bugando na produção!

Bem, depois de um dia de "diversão" foi isso que concluí até agora ... Tenho vários dispositivos em diferentes versões de SO e tenho esse problema em cada um deles. Entrei em contato com a Apple a respeito disso e ainda estamos acompanhando o caso, porém, sem nenhuma conclusão sólida. Não acredito que seja problema de embalagem, deve ser algo do lado da Apple. Eu tentei tudo que as pessoas estão mencionando neste tópico e em outros tópicos que relataram um problema semelhante. A caixa de diálogo In App Purchase é apenas inconsistente em aparecer e, até agora, não consigo encontrar uma razão válida para isso porque os resultados são sempre diferentes. Às vezes recebo um erro E_UNKNOWN, outras vezes não recebo nenhum feedback, às vezes o pop-up aparece após 10 minutos de espera e outras vezes simplesmente funciona ... Eu tentei com usuários de sandbox, não usuários de sandbox, tive o os mesmos resultados diferentes para o mesmo usuário e dispositivo e nem mesmo um erro ou um registro conclusivo / perspicaz é mostrado. Isso é frustrante para depurar porque você não consegue encontrar quase nada ... Bem, se vocês têm algum tipo de conselho ou visão, estou ouvindo ... Enquanto isso, se eu tiver alguma notícia da Apple, Vou mantê-lo informado ...
PS EDIT. depois de ler o último comentário, uma coisa é consistente e posso confirmar, no iOS 14 a coisa parece mais inconsistente, embora aconteça em todas as versões do sistema operacional que testei (12, 13.7, 14). Porém, continuo com a impressão de que o problema não está apenas relacionado à versão do SO e por isso estou pensando que deve ser algo com o servidor Sandbox ou qualquer outra coisa no final da Apple ..

Testamos nosso pacote de aplicativos com uma versão aprovada da App Store e parece que a inconsistência vem com mais destaque no iOS versão 14+

Nossa conclusão é que a forma como a Apple verifica o recebimento no iOS 14+ é um pouco diferente.

Acontece com contas que já fizeram compras

1. Crie uma nova conta no Sandbox
2. Faça uma compra (funciona bem porque o restorePurchases não tem compras)
3. Espere até que expire.
4. Compre novamente. (Agora, a restauração de compras responde a um objeto e o pop-up para confirmar que a compra não funciona mais)

É estranho. Eu estava revisando o código da biblioteca e adicionei alguns logs para teste. E eu tenho o seguinte

1. Quando restorePurchases é chamado. Ele executa o listener "paymentQueueRestoreCompletedTransactionsFinished"

-(void)paymentQueueRestoreCompletedTransactionsFinished:(SKPaymentQueue *)queue {  ////////   RESTORE
    NSLog(@"\n\n\n  paymentQueueRestoreCompletedTransactionsFinished  \n\n.");
    NSMutableArray* items = [NSMutableArray arrayWithCapacity:queue.transactions.count];
    NSLog(@"Number of items in my array is: %d", [queue.transactions count]);//this will return (5)

    for(SKPaymentTransaction *transaction in queue.transactions) {
        if(transaction.transactionState == SKPaymentTransactionStateRestored
           || transaction.transactionState == SKPaymentTransactionStatePurchased) {
            [self getPurchaseData:transaction withBlock:^(NSDictionary *restored) {
                [items addObject:restored];
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
            }];
        }
    }
    NSLog(@"\n  finished paymentQueueRestoreCompletedTransactionsFinished ");

    [self resolvePromisesForKey:@"availableItems" value:items];
}

Aqui eu imprimo no log o tamanho das transações e tenho 23 itens

1. A função paymentQueue é executada para finalizar as transações de restauração

case SKPaymentTransactionStateRestored: {
          NSLog(@"Restored ");

         NSLog(@"\n  paymentQueue transaction : %@", transaction.transactionDate);
         [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
           break;
  }

1. resolvePromisesForKey conclui o restorePurchase

2. requestSubscription começa a chamar a função buyProduct

3. Aqui eu adicionei logs para ver o log

 NSLog(@"\n  produc purchase : %@", product);

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

  NSLog(@"\n  payment buy product : %@", payment.productIdentifier);

  [[SKPaymentQueue defaultQueue] addPayment:payment];

1. Obtive o seguinte log:
   a) Registro RestorePurchases

2020-10-22 14:01:49.319677-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319784-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:46:53 2020
2020-10-22 14:01:49.319930-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319970-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:16:45 2020
2020-10-22 14:01:49.320044-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320082-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:06:37 2020
2020-10-22 14:01:49.320155-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320275-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:01:37 2020
2020-10-22 14:01:49.320421-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320532-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:49:31 2020
2020-10-22 14:01:49.320671-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320776-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:21:39 2020
2020-10-22 14:01:49.320915-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321018-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:26:39 2020
2020-10-22 14:01:49.321180-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321282-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:56:53 2020
2020-10-22 14:01:49.321414-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321516-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:51:53 2020
2020-10-22 14:01:49.321648-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321749-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 08:04:31 2020
2020-10-22 14:01:49.321879-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321984-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:11:41 2020
2020-10-22 14:01:49.322113-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322214-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:41:53 2020
2020-10-22 14:01:49.322346-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322444-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:31:39 2020
2020-10-22 14:01:49.323955-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324097-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 12:07:14 2020
2020-10-22 14:01:49.324240-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324344-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:16:39 2020
2020-10-22 14:01:49.324474-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324579-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:11:39 2020
2020-10-22 14:01:49.324709-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324808-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:39:31 2020
2020-10-22 14:01:49.324934-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325030-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:59:31 2020
2020-10-22 14:01:49.325163-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325260-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:26:45 2020
2020-10-22 14:01:49.327079-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327212-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:44:31 2020
2020-10-22 14:01:49.327360-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327465-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:54:31 2020
2020-10-22 14:01:49.327594-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327695-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:37:11 2020
2020-10-22 14:01:49.327823-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327923-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:21:45 2020
2020-10-22 14:01:49.328099-0500 ApplicationTest[532:51039] 

  paymentQueueRestoreCompletedTransactionsFinished  

2020-10-22 14:01:49.328204-0500 ApplicationTest[532:51039] Number of items in my array is: 23
2020-10-22 14:01:49.336873-0500 ApplicationTest[532:51039] 
  finished paymentQueueRestoreCompletedTransactionsFinished
2020-10-22 14:01:50.317721-0500 ApplicationTest[532:51234] 

b. log de inscrição de compra:

2020-10-22 14:01:50.319607-0500 ApplicationTest[532:51234] 
  produc purchase : <SKProduct: 0x2839c0630>

2020-10-22 14:01:50.319694-0500 ApplicationTest[532:51234] 
  payment buy product : test.applicationtest

**2020-10-22 14:01:50.319849-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:50.319895-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:16:45 2020**

Então, não entendo por que o método paymentQueue é executado com um SKPaymentTransactionStateRestored datado de 5 de outubro

@andresordonezfm Você ligou para finishTransaction após a compra?

Também em relação aos pop-ups, aqui estão os grandes testes fornecidos em # 863. Espero que ajude.

@andresordonezfm Você ligou para finishTransaction após a compra?

Certo! também chamei clearTransactionIOS () de qualquer maneira se pudesse ser o problema, mas nada.

Também em relação aos pop-ups, aqui estão os grandes testes fornecidos em # 863. Espero que ajude.

Obrigado. Eu vou revisar

Alguma solução / atualização?

Nada ainda. Eu estava revisando e a Apple adicionou novos recursos no StoreKit e nos tipos de notificação.
Não tenho certeza se esse poderia ser o problema

https://developer.apple.com/videos/play/wwdc2020/10661/

Eu fiz downgrade do pacote para 4.5.2 funcionou para mim
verifique se você está ligando
await RNIap.initConnection();
antes de RNIap.requestSubscription

Parece que resolvi após este problema:
https://github.com/dooboolab/react-native-iap/issues/1146

Em primeiro lugar, quando eu estava validando o recibo, estava passando true como parâmetro isTest (mesmo quando era um build de produção).
Então eu adicionei RNIap.clearTransactionIOS(); em purchaseUpdatedListener antes de validar o recibo e RNIap.finishTransaction(purchase, false) após RNIap.finishTransactionIOS(purchase.transactionId);

Testei no TestFlight e consegui concluir uma compra pela primeira vez (com uma conta sandbox), agora vou testá-lo em produção 🤞

Parece que resolvi após este problema:

1146

Em primeiro lugar, quando eu estava validando o recibo, estava passando true como parâmetro isTest (mesmo quando era um build de produção).
Então eu adicionei RNIap.clearTransactionIOS(); em purchaseUpdatedListener antes de validar o recibo e RNIap.finishTransaction(purchase, false) após RNIap.finishTransactionIOS(purchase.transactionId);

Testei no TestFlight e consegui concluir uma compra pela primeira vez (com uma conta sandbox), agora vou testá-lo em produção 🤞

Oi cara eu tentei essa solução, mas não funcionou para mim.

Estou tendo o mesmo problema. Acontece quando você tenta comprar a assinatura após restaurar a compra.

Posso confirmar os logs de @andresordonezfm , onde parece que SKPaymentQueue recebe transação do tipo SKPaymentTransactionStateRestored , em vez do tipo SKPaymentTransactionStatePurchasing , que é o motivo do "Restaurar" string sendo registrado na compra.

Oi pessoal desculpe a demora.

Eu estava revisando e encontrei uma solução para esse problema. O problema é que antes de chamar as compras de restauração, as transações recém-abertas das mesmas compras de restauração não fecham corretamente. Então eu os fecho à força.

Em seguida, a função clearTransactionIOS da biblioteca, a promessa deve ser adicionada para esperar que as transações sejam fechadas usando a função removedTransactions

Aqui está o meu código:

Arquivo: react-native-iap / ios / RNIapIos.m

1. Substitua a função RCT_EXPORT_METHOD (clearTransaction) pelo seguinte código

RCT_EXPORT_METHOD(clearTransaction:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {  

    NSLog(@"\n\n\n  ***  clear remaining Transactions. Call this before make a new transaction   \n\n.");

    NSArray *pendingTrans = [[SKPaymentQueue defaultQueue] transactions];
    countPendingTransaction = (NSInteger)(pendingTrans.count);

    if (countPendingTransaction > 0) {
        [self addPromiseForKey:@"cleaningTransactions" resolve:resolve reject:reject];

        for (SKPaymentTransaction *transaction in pendingTrans) {
            [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
        }

    } else {
        resolve(nil);
    }
}

1. Adicione a seguinte nova função (adicionei esta função no final do arquivo RNIapIos.m. Antes da linha "@end")

-(void)paymentQueue:(SKPaymentQueue *)queue removedTransactions:(NSArray *)transactions {
    NSLog(@"removedTransactions");
    if (countPendingTransaction != nil && countPendingTransaction > 0) {
        countPendingTransaction--;
        if (countPendingTransaction == 0) {
            [self resolvePromisesForKey:@"cleaningTransactions" value:nil];
            countPendingTransaction = nil;
        }
    }
}

Arquivo: react-native-iap / ios / RNIapIos.h

1. Sob o código "SKProduct * decorridoProduto;" adicione a seguinte linha

  NSInteger countPendingTransaction;

Finalmente, antes de chamar a função "RNIap.requestSubscription (productId, false)".
A função clearTransactionIOS deve ser chamada, por exemplo:

    if (Platform.OS === 'ios') {
      await RNIap.clearTransactionIOS();
    }
    await RNIap.requestSubscription(productId, false);

Espero que ajude. O comportamento estranho das compras de restauração Não consegui encontrar o motivo. Mas isso resolveu para mim testar no Sandbox.

Se você tiver alguma sugestão, por favor me avise.

Eu também tenho esse problema, por favor, autor, me ajude, agradeço sua família

Eu também tenho esse problema, por favor, autor, me ajude, agradeço sua família

Oi cara, No comentário anterior explicam os passos que fiz para resolver isso

Se você tiver algum comentário, me avise

@andresordonezfm você estaria disposto a criar um PR para essas mudanças?

Para a emissão de compras chegando como SKPaymentTransactionStateRestored que acontece após a restauração, criei uma nova conta e fiz algumas compras e não está acontecendo para essa conta. Posso chamar RNIap.getAvailablePurchases() e RNIap.requestSubscription() depois.

Parece que pode estar relacionado com a quantidade de compras que um usuário faz? Ainda não executei nenhum teste de produção.

Bem, depois de um dia de "diversão" foi isso que concluí até agora ... Tenho vários dispositivos em diferentes versões de SO e tenho esse problema em cada um deles. Entrei em contato com a Apple a respeito disso e ainda estamos acompanhando o caso, porém, sem nenhuma conclusão sólida. Não acredito que seja problema de embalagem, deve ser algo do lado da Apple. Eu tentei tudo que as pessoas estão mencionando neste tópico e em outros tópicos que relataram um problema semelhante. A caixa de diálogo In App Purchase é apenas inconsistente em aparecer e, até agora, não consigo encontrar uma razão válida para isso porque os resultados são sempre diferentes. Às vezes recebo um erro E_UNKNOWN, outras vezes não recebo nenhum feedback, às vezes o pop-up aparece após 10 minutos de espera e outras vezes simplesmente funciona ... Eu tentei com usuários de sandbox, não usuários de sandbox, tive o os mesmos resultados diferentes para o mesmo usuário e dispositivo e nem mesmo um erro ou um registro conclusivo / perspicaz é mostrado. Isso é frustrante para depurar porque você não consegue encontrar quase nada ... Bem, se vocês têm algum tipo de conselho ou visão, estou ouvindo ... Enquanto isso, se eu tiver alguma notícia da Apple, Vou mantê-lo informado ...
PS EDIT. depois de ler o último comentário, uma coisa é consistente e posso confirmar, no iOS 14 a coisa parece mais inconsistente, embora aconteça em todas as versões do sistema operacional que testei (12, 13.7, 14). Porém, continuo com a impressão de que o problema não está apenas relacionado à versão do SO e por isso estou pensando que deve ser algo com o servidor Sandbox ou qualquer outra coisa no final da Apple ..

Exatamente o que estou experimentando do meu lado, mesmo após a correção sugerida por @andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587). @ 106firestarter , a Apple alguma vez respondeu?

Vou ver o que posso encontrar nos fóruns de desenvolvedores enquanto isso.

Para a emissão de compras chegando como SKPaymentTransactionStateRestored que acontece após a restauração, criei uma nova conta e fiz algumas compras e não está acontecendo para essa conta. Posso chamar RNIap.getAvailablePurchases() e RNIap.requestSubscription() depois.

Parece que pode estar relacionado com a quantidade de compras que um usuário faz? Ainda não executei nenhum teste de produção.

Vou tentar isso, mas a produção também é uma preocupação, de fato.

Para registro, também estou chamando getAvailablePurchases() antes de requestSubscription() .

Possivelmente relacionado:

• https://developer.apple.com/forums/thread/669435

Posso confirmar também que, com uma conta totalmente nova, o problema não é mais o que

Correção: usar uma nova conta junto com a correção sugerida por @andresordonezfm faz com que funcione para mim. Sem a correção, após a primeira assinatura, o mesmo comportamento que eu estava experimentando surge novamente e não posso mais assinar novamente. Mais uma coisa que notei depois de aplicar a correção é que as assinaturas parecem não ser mais renovadas automaticamente, nem mesmo uma vez, embora usando o sandbox elas devam ser renovadas 5 vezes.

@andresordonezfm você estaria disposto a criar um PR para essas mudanças?

Oi cara desculpe pela demora de novo. Eu criei uma solicitação de pull para iap nativo de reação

~ Posso confirmar também que, com uma conta totalmente nova, o problema não é mais o que # 1120 (comentário) ). ~

Correção: usar uma nova conta junto com a correção sugerida por @andresordonezfm faz com que funcione para mim. Sem a correção, após a primeira assinatura, o mesmo comportamento que eu estava experimentando surge novamente e não posso mais assinar novamente. Mais uma coisa que notei depois de aplicar a correção é que as assinaturas parecem não ser mais renovadas automaticamente, nem mesmo uma vez, embora usando o sandbox elas devam ser renovadas 5 vezes.

Oi cara, eu acho que é um problema de sandbox. Você continua apresentando esse comportamento?

@andresordonezfm sim, eu também suspeito que seja um problema com o sandbox da Apple. Não fiz mais nenhum teste desde meu último comentário e ainda estou para verificar a produção. No entanto, até o momento, não recebi nenhuma reclamação de clientes.

A sandbox parece estar de volta no meu fim ao usar uma conta totalmente nova, conforme relatado anteriormente por

@andresordonezfm Eu encontrei a mesma coisa e seu patch parece para consertar. No entanto, acho que vejo um bug sutil em seu código que pode causar o travamento de cleartTransactionsIOS() . removeTransactions pode ser chamado com 1 ou mais transações a serem removidas. Então, em removeTransactions , acho que queremos:

        countPendingTransaction -= [transactions count];

Na prática, só vi removedTransactions chamados com uma transação, mas os documentos da Apple dizem que pode ser uma ou mais. Bom achado por sinal! Eu estava preso nisso por um tempo.

@andresordonezfm Eu encontrei a mesma coisa e seu patch parece para consertar. No entanto, acho que vejo um bug sutil em seu código que pode causar o travamento de cleartTransactionsIOS() . removeTransactions pode ser chamado com 1 ou mais transações a serem removidas. Então, em removeTransactions , acho que queremos:

        countPendingTransaction -= [transactions count];

Na prática, só vi removedTransactions chamados com uma transação, mas os documentos da Apple dizem que pode ser uma ou mais. Bom achado por sinal! Eu estava preso nisso por um tempo.

Oi cara, obrigado pela recomendação. Testei sua proposta e funcionou bem para mim. Fiz uma solicitação de pull com essa mudança.

Nota: Sim, eu revisei essa documentação, mas como ela é disparada apenas de uma transação para outra, não a implementei. Mas é uma recomendação muito boa. Obrigado!