テストユーザーのiOSアプリ内購入サンドボックスからの購入のクリア


116

iOSのアプリ内購入のサンドボックスをリセットまたはクリアする方法について何かアイデアはありますか?

サンドボックスでテストしているアプリがあり、何かを購入するたびに新しいテストユーザーを作成しなくても、新しい購入をテストしたいと思います。

これを行わない場合、(もちろん)アプリの購入ボタンをクリックすると、常にアプリ内購入アイテムが既に購入されているというメッセージが表示されます。

回答:


75

IMO非消耗品のテストに耐えられるようにするためにできることは3つあります。

  1. 1つのメールに複数のテストアカウントを関連付けることができます。例えばGmailは、あなたが電子メールに「プラス」の文字列を追加することができますアドレスのエイリアスを作成するように:tester+01@gmail.comtester+02@gmail.com両方本当にちょうどに行きますtester@gmail.com。おそらく他のメールホストも同じことをします。テストアカウントを作成するときに、次のことを紹介する必要があります。姓、名、電子メールアドレス、パスワード、秘密の質問、秘密の答え、生年月日、iTunesストアの国。あなたは、のために、正確に(パスワードを含む)は、同じデータを置くことができるtester+01@gmail.comtester+02@gmail.com、あなたは2つのテストアカウントを持っています。最後に、tester@gmail.com受信トレイで、両方のテストアカウントを確認するために、Appleから2通の確認メールを受信します。

  2. 製品ID @ "Extra_Levels"の非消耗品があるとします。@ "Extra_Levels"をすべてのメソッド(requestProduct、purchaseProductなど)に書き込む代わりに、PRODUCT_ID1ヘッダーファイルに#define PRODUCT_ID1 @"Extra_Levels"(セミコロンなしで)書き込むだけで、プリプロセッサはPRODUCT_ID1を検索して@ "Extra_Levels"に置き換えます。次に、@ "Extra_Levels_01"という新しい非消耗品を作成し、#defineを変更することで、すべてのテストユーザーの購入をリセットするのと同じくらい効果があります。

  3. アプリマティクスが指摘しているように、最初に消費可能なIAPを使用して(テストユーザーが必要なだけ購入できるように)、いくつかのバグを取り除くことにより、非消費可能なIAPを購入するときにコードの正しい動作をテストできます。もちろん、その後、実際の非消費型IAPでコードをテストする必要もあります。


17
うわー、私はこの超秘密のGmail機能を知りませんでした。なんと便利!
bobobobo 2013年

4
テストユーザーのメールを実際に確認する必要がないことがわかりました。123@123.comにパスワードを指定して(サンドボックスモードでパスワードを使用することになります)、単純に機能します。昨夜テストしたところです。
2014年

3
メールエイリアスのプラス記号のトリックは、GMailだけのものではありません。これは、数十年前に遡る、電子メールサーバーの間の非常に古い伝統です。しかし、電子メールの仕様には組み込まれていません。したがって、特定の電子メールサーバーでテストして、この機能に精通していることを確認してください。
バジルブルク2014

2
私はテストアカウント用のアプリ内購入をクリアすることは不可能であることを考えるwould'n;)ビバアップル:)
パルトロミエSemańczyk

12
+メールアドレスは、Apple IDのサインアップに使用できなくなりました。
pkamb

32

私の知る限り、これを行うことはできません。サンドボックスバックエンドは、実際のアカウントのように機能します。いったん購入すると、購入されます(したがって、復元をテストできます)。ほとんどの開発は、ストアのものをシムアウトして行い、実際にテストする場合は、いくつかのテストアカウントを作成することを期待します。


3
samvermetteに同意します。これは、テストが実際のストアに非常に密接に機能するということです。少なくともサンドボックスでの購入をクリアする方法がなければなりません。テストのために同じユーザーに対して複数の購入を行うために、消費型も追加しました。
appsmatics 2012年

4
@samvermette 唯一の違いはSKPaymentTransactionStateRestored、の代わりにアプリストアから戻ることですSKPaymentTransactionStatePurchased。ここでは実際のお金を使用していないので、すべての意図と目的で、テストが行​​われる限りSKPaymentTransactionStateRestored100%相当SKPaymentTransactionStatePurchasedです。アプリの状態を「未購入」にリセットするかどうかは実際にあなた次第です(関連するキーチェーンエントリまたは「ユーザーがXを購入した」をキャッシュするために使用しているものをすべて削除してください)
bobobobo 2013年

9

アプリの購入アイテムが2つあります。生産用に1つ。もう1つはテスト用です。「クリア」する必要があるときは、アプリ内アイテムを削除して新しいアイテムを作成します(iTunesで15秒、コードで製品IDを変更するために1秒)

「新しいユーザー」をテストする必要がない場合は、アプリアイテムのプロダクションを使用します。


はい、製品の新しいコピーを作成し、コード内の製品名を変更する(おそらくそれを#defineしている)のが、現実的なテストを行うための最も簡単な解決策のようです。
JulianSymes 2014年

7

まあ、技術的にはそれは必要ありません。

を取得した場合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ます。


5

アプリの削除と再インストールは、サンドボックステストでも機能します。アプリに依存していることは明らかですが、現時点ではサインアップ時にのみ購入するサブスクリプションベースのアプリをテストしているため、これが最も簡単な解決策でした。


3

SimStoreKitをチェックしてください。これは「iPhoneのStoreKitのシミュレーションバージョンであり、iPhoneシミュレーターで、またはConnectでIAPをセットアップする必要のないデバイスでさえも、ストアUIをテストするためのものです。」

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を使用するという効果があります。


これを機能させることができませんでした。ビルドエラーが発生します。私はzip内のすべてのファイルをプロジェクトにコピーし、すべての#import <StoreKit / StoreKit.h>を#define ILSimReplaceRealStoreKit 1 #import "ILSimStoreKit.h"で置き換えました
Jay Q.

ILSimSKで始まるファイルが必要です。他のものはデモアプリ用です。おそらく、発生している正確なエラーを含む質問を投稿する必要があります。「ビルドエラーが発生しています」とはあまり言いません。
Emile Cormier、2012年

-1

または、複数のテストユーザーソリューションを作成するために、iTunes Connectでアプリの購入に複数のテストを作成できます。ユーザーアカウントを変更する必要はありません。


1
反対票の理由は次のとおりです。1.アプリケーションユーザーのログインとクロスデバイス/プラットフォームコンテンツの可用性に関する多くのシナリオを必要とする可能性がある特定のアプリ内購入ソリューションをテストしようとしている可能性があるため、良いソリューションではありません。2.複数のテストアカウントを作成するのと同じように、複数のテスト購入を作成するのは(退屈なことに)退屈な作業です。3.また、回答の形式があまりよくありません。
mickeymoon

-1

新しいテストアカウントを完成させるのではなく、同じテストアカウントを使い続け、購入を復元します。結局のところ、新しい購入を開始する場合でも古い購入を復元する場合でも、あなたのアプリは同じことを行います(少なくとも最初は、おそらくユーザーインターフェイスは完了時に異なる方法で更新されます)。アップルはそれらの異なる状況で物事を異なる方法で扱う人々です-心配しないでください。

テストのために、このメソッドの実装内のSKPaymentTransactionStateRestoredケースに配信ロジックを配置します。

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

次に、その配信ロジックを必ずSKPaymentTransactionStatePurchasedケースに入れてください。

最後に、私たちのほとんどはさまざまな程度に強迫的であるため、新しいアカウントで最終的なテストを行います(絶対的な確実性のために2番目のアカウントを作成するのは大したことではありません)。

最後に注意してください:アップルの立場を考慮してください。IAPを完全にテストするために数十または数百のアカウントを作成する時間を浪費しなければならない開発者に問題があった場合、彼らは問題を解決したでしょう。問題はない。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.