테스트 사용자를 위해 iOS 인앱 구매 샌드 박스에서 구매 지우기

누구든지 iOS 인앱 구매 샌드 박스를 재설정 및 / 또는 지우는 방법에 대한 아이디어가 있습니까?

샌드 박스로 테스트중인 앱이 있는데 구매할 때마다 새 테스트 사용자를 만들지 않고도 새 구매를 테스트하고 싶습니다.

이렇게하지 않으면 내 앱의 구매 버튼을 클릭 할 때 항상 인앱 구매 항목이 이미 구매되었다는 메시지가 표시됩니다.

IMO에는 비 소모품 테스트를 견딜 수 있도록하기 위해 할 수있는 세 가지가 있습니다.

1. 하나의 이메일에 여러 테스트 계정을 연결할 수 있습니다. 예를 들어 Gmail은 이메일에 "플러스"문자열을 추가 할 수 있습니다 주소에 대한 별칭을 만들 수 있도록 : tester+01@gmail.com그리고 tester+02@gmail.com모두 정말로 이동합니다 tester@gmail.com. 아마도 다른 이메일 호스트도 똑같이 할 것입니다. 테스트 계정을 생성 할 때 이름, 성, 이메일 주소, 암호, 비밀 질문, 비밀 답변, 생년월일 및 iTunes 스토어 국가를 소개해야합니다. 당신을 위해 정확히 (비밀번호 포함) 동일한 데이터를 넣을 수 있습니다 tester+01@gmail.com그리고 tester+02@gmail.com당신은 두 개의 테스트 계정이있을 것이다. 마지막으로 tester@gmail.com받은 편지함에서 두 테스트 계정을 확인하기 위해 Apple로부터 두 개의 확인 이메일을 받게됩니다.

2. 제품 ID가 @ "Extra_Levels"인 비 소모품이 있다고 가정 해보십시오. 모든 메소드 (requestProduct, purchaseProduct, ...)에 @ "Extra_Levels"를 작성하는 대신 써서 PRODUCT_ID1헤더 파일을 넣어서 #define PRODUCT_ID1 @"Extra_Levels"(세미콜론없이!) 전처리 기가 PRODUCT_ID1을 검색하여 @ "Extra_Levels"로 대체합니다. 그런 다음 @ "Extra_Levels_01"이라는 새 비 소모품을 만들고 #define을 변경하는 것은 모든 테스트 사용자의 구매를 재설정하는 것만 큼 좋습니다.

3. 앱 매틱스가 지적했듯이, 먼저 소모성 IAP를 사용하여 (테스트 사용자가 필요한만큼 구매할 수 있도록) 일부 버그를 제거하여 비 소모성 IAP를 구매할 때 코드의 올바른 동작을 테스트 할 수 있습니다. 물론 그 후에는 실제 비 소모성 IAP로 코드를 테스트해야합니다.

내가 아는 한 당신은 이것을 할 수 없습니다. 샌드 박스 백엔드는 실제 계정처럼 작동합니다. 일단 구매하면 구매 한 것이므로 복원을 테스트 할 수 있습니다. 대부분의 개발은 상점의 물건을 떼어 놓은 상태에서 수행해야하며, 실제로 테스트 할 때 여러 테스트 계정을 생성 할 것으로 예상합니다.

인앱 구매 항목이 2 개 있습니다. 생산 용 1 개. 다른 하나는 테스트 용입니다. "삭제"해야 할 때 앱 내 항목을 삭제하고 새 항목을 만듭니다 (iTunes 연결에서 15 초, 코드에서 제품 ID 변경 1 초).

"신규 사용자"를 테스트 할 필요가 없으면 앱 항목에서 프로덕션을 사용합니다.

글쎄, 기술적으로는 필요하지 않습니다.

를 받으면 SKPaymentTransactionStateRestored앱 스토어에서 사용자를 확인하고 구매를 허용하는 것과 100 % 동일합니다. 다음과 같은 스위치가 있습니다.

- (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
     }
  }
}

앱 로직을 갖고 구매를 되 찾는 문제는 간단합니다. 키 체인에서 구매를 캐싱하는 경우 키 체인을 삭제합니다. 다른 방법으로 수행하는 경우 사용자가 이전에 구입 한 적이없는 것처럼 가장하도록 로컬 앱 상태를 변경하십시오. 구매 요청 대화 상자는 여전히 똑같으며 유일한 차이점은 YES를 입력하면 SKPaymentTransactionStateRestored대신 제공 됩니다 SKPaymentTransactionStatePurchased.

앱 삭제 및 재설치는 샌드 박스 테스트에도 적용됩니다. 당연히 앱에 따라 다르지만 지금은 가입 중에 만 구매하는 구독 기반 앱을 테스트하고 있으므로 가장 쉬운 솔루션이었습니다.

SimStoreKit을 확인하십시오 . 이것은 "iPhone Simulator에서 또는 Connect에서 IAP를 설정하지 않고도 장치에서 상점 UI를 테스트하기위한 iPhone StoreKit의 시뮬레이션 버전"입니다.

SimStoreKit은 키 아래의 사용자 기본값에 구매를 저장합니다 ILSimSKTransactions. 따라서 모든 구매를 지우려면 다음을 수행하십시오.

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

시뮬레이터에서 앱을 제거하고 다시 설치할 수 있습니다.

샌드 박스로 테스트하기 전에 SimStoreKit을 사용하여 내 앱의 스토어 전면을 성공적으로 디버깅했습니다. 이 라이브러리의 아름다움은이 설정 될 수있다 (수행하여 실제 StoreKit 프레임 워크와 같은 클래스 이름을 사용하는 것입니다 #define ILSimReplaceRealStoreKit 1하기 전에 #include <ILSimStoreKit.h>).

StoreKit에 액세스해야하는 소스 파일에 다음 헤더 파일을 포함합니다.

#import <TargetConditionals.h>

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

이것은 시뮬레이터에서 실행할 때 SimStoreKit을 사용하고 장치에서 실행할 때 실제 StoreKit을 사용하는 효과가 있습니다.

또는 여러 테스트 사용자 솔루션을 생성하기 위해 iTunes 연결에서 앱 구매에서 여러 테스트를 생성 할 수 있으며 사용자 계정을 변경할 필요가 없습니다.

동일한 테스트 계정을 계속 사용하여 새 계정을 완료하는 대신 구매를 복원하십시오. 결국, 새 구매를 시작하든 이전 구매를 복원하든 귀하의 앱은 동일한 작업을 수행합니다 (적어도 처음에는 완료시 사용자 인터페이스가 다르게 업데이트 될 수 있음). 애플은 상황에 따라 다르게 처리하는 사람들입니다. 걱정하지 마세요.

테스트를 위해이 메서드의 구현 내에서 SKPaymentTransactionStateRestored 케이스에 배달 논리를 배치합니다.

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

그런 다음 해당 전달 로직을 SKPaymentTransactionStatePurchased 케이스에 넣어야합니다.

결국, 우리 대부분은 다양한 정도에 강박 적이므로 새로운 계정으로 최종 테스트를 수행하십시오 (절대 확실성을 위해 두 번째 계정을 만드는 데 큰 문제가 아닙니다).

마지막으로 주목할 것은 사과의 위치를 ​​고려하는 것입니다. 개발자가 IAP를 철저히 테스트하기 위해 수십 또는 수백 개의 계정을 만드는 데 시간을 낭비해야하는 문제가 있었다면 문제를 해결했을 것입니다. 문제 없습니다.