iOSサンドボックステストユーザーアカウントのサブスクリプション管理
現在、IAPを既存のアプリに追加しようとしています。そのために、いくつかの製品を追加し、テストユーザーを作成しました。製品は定期的なサブスクリプションです。私がテストしているデバイスは、iOS 5.1を搭載したiPhone 4Sです。
私は自分の製品についてストアを正常に照会し、新しいテストユーザーと一緒に正常に購入できます。私が抱えている問題は、ストア設定アプリからサブスクリプションを管理しようとすると、「このアカウントはAppStoreでの購入に使用されていないため、アカウントを確認して続行してください。 」アカウントを確認すると、CreditCard情報を入力しないと続行できません。
最終的に、テストサブスクリプションをキャンセルすることはできません。テストユーザーを削除して新しいユーザーを作成し、アプリを削除して再インストールし、StoreAppと設定アプリを強制終了し、デバイスを再起動し、購入前にメールでアカウントを確認しましたが、購入前にメールでアカウントを確認しませんでした...すべての順列失敗したようです。
同じサブスクリプションを2回購入することがあります。その場合、StoreKitにサブスクリプション設定の管理を求めるプロンプトが表示されます。これにより、前の「アカウントレビュー」プロセスが発生する場合と、「iTunes Storeに接続できない」という警告が発生する場合があります。
続行する方法についてのアイデアが不足しています。
編集-ここに私が作成したiTunesConnectテストユーザーのイベントの流れがあります
最初のサブスクリプション
既存のIDを使用
アカウントサインインのテスト
サブスクリプションを管理する
AppStoreサインイン
AppStoreに接続できません
アカウントを確認
次に、住所が「1 Infinite Loop Cupertino、CA」である（つまり、これがテストアカウントであることを認識している）にもかかわらず、レビュープロセスにより、クレジットカード情報を入力する必要があります。
Apple developer。（Rich Kubota））による応答があります。サンドボックス環境でのサブスクリプションテストについて。
これは、アプリ内購入シミュレーションプロセスのバグホールです。キャンセルプロセスをシミュレートする方法、またはユーザーのiTunesアプリからサブスクリプション管理プロセスをシミュレートする方法はサポートされていません。この制限は、アプリのTestFlightバージョンにも存在します。アプリのTestFlightビルドをユーザーに送信し、ユーザーがアプリをテストすると、ユーザーアカウントは実際にはサンドボックス環境で動作しています。 TestFlightアプリは、TestFlightユーザーのiTunes管理サブスクリプションセクションに管理アプリとして表示されないため、これを確認しました。これは、アプリがサンドボックス環境にあり、iTunesアプリが何も知らないためです。
私がこのフォーラムで返信してから久しぶりですが、アプリケーションが自動更新プロセスを処理することを確認する最良の方法は、transactionObserverを介して自動更新サブスクリプション更新の検出もアプリが処理することを確認することです。たとえば、サンドボックス環境で1か月のサブスクリプションを購入した場合。次に、アプリを強制終了し、6分間待ってからアプリを再起動します。transactionObserverは、処理するincompleteTransaction（圧縮された1か月の更新）があることを検出します。
これは、ユーザーがiTunesサブスクリプション管理ページでサブスクリプションを再開した場合に起こることと非常によく似ています。トランザクションはiTunesストアによって記録され、ユーザーアカウント/アプリバンドルIDのincompleteTransactionが有効になります。アプリが起動し、transactionObserverをアクティブ化すると（addTransactionObserverの呼び出しを介して）、incompleteTransactionが検出され、更新を処理するためにupdatedTransaction delefgateメソッドが呼び出されます。次に、アプリはapplicationReceiptを検証して、現在の日付よりも有効期限が切れており、自動更新サブスクリプションのproduct_idがアクティブであることを認識する自動更新サブスクリプションアイテムのin_app配列アイテムが存在することを確認できます。
自動更新サブスクリプションがキャンセルされたことのテストに関しては、これもシミュレートするためにiTunes Storeサーバーのサポートが必要です。ただし、レシート検証プロセスは毎日機能し、自動更新サブスクリプションの最新のin_app配列アイテムを検出できます。cancel_dateが設定されているかどうかを検出すると、サブスクリプションがキャンセルされたことをアプリに通知します。注として、任意の要素のcancel_dateフィールドが誤検知になる可能性があることを検出するだけです。ユーザーが自動更新サブスクリプションを以前にキャンセルした可能性があり、それがそれほど悪くないと判断し、アイテムを再購入しました。このため、ロジックは最新のin_app配列要素でcancel_dateフィールドが設定されていることを確認して、現在のサブスクリプションが実際にキャンセルされていることを確認する必要があります。確認しようとしている問題の1つ-キャンセルされたアイテムのexpire_dateがcancel_dateに移動し、キャンセルされたサブスクリプションが期限切れのサブスクリプションと同じように表示されるかどうか。正しい動きのようですが、この情報はiTunes Storeサーバーチームによって制御されています。
サンドボックス内の本番ストア環境のこれらの機能をシミュレートするためのメカニズムを追求したい場合は、Apple開発者バグレポートWebページを使用して拡張リクエストを送信することをお勧めします。iTunesConnectを選択してくださいバグレポート用の製品。提案はiOSではなく、iTunes Storeがシミュレートするためのものです。
サンドボックスでサブスクリプションを実際に管理することはできませんが、Jean-Paul de Ville de Goyetが Apple Developer Forums で見つけたように：
1か月のサブスクリプションは5分ごとに自動更新されます。ここまでは順調ですね。それらは5回自動更新されてから停止するため、25分後に21006エラーが発生します。ただし、同じサブスクリプションを再購入した場合でも、すでに5回自動更新されているため、同じテストアカウントで再度自動更新されることはありません。したがって、更新をテストしたいが、しばらくの間これらのサブスクリプションをいじっていた場合は、新しいiTunes接続テストユーザーを作成する必要があります。これは正直非常に迷惑です。テストユーザーアカウントの購入履歴全体をリセットできれば、はるかに簡単になります。
同じ方法でサブスクリプションをテストしました。