購入履歴をNSUserDefaultsに記録 (非推奨)
Appleのドキュメントにはこの方法が書かれているが、セキュリティの観点から非推奨。
pros
- 手軽に実装できる
cons
- NSUserDefaultsファイルは簡単に閲覧/編集できる
参考
-
(pdf) In-App Purchase
プログラミングガイド
- NSUserDefaultsにデータを保持するコード例あり
- NSUserDefaults are not the place for sensitive data!
購入履歴を暗号化 or 難読化してNSUserDefaultsに記録 (非推奨)
pros
- ライブラリを使うと手軽に実装できる
cons
- NSUserDefaultsファイルは簡単に閲覧/編集できるので、暗号化 or 難読化方法が知られると購入履歴を操作されてしまう
参考
購入履歴をKeychainに記録
pros
- ライブラリを使うと手軽に実装できる
cons
- 他のiPhone/iPadへバックアップデータを復元する際に、バックアップの設定/方法によってはKeychainのデータが移行されない
参考
レシートの確認
アプリ内課金をすると、課金情報が記載されたレシートが暗号化された状態で端末へ保存されるので、それを復号して購入履歴を確認する。
Non-Consumables と Auto-Renewable Subscriptions はレシートだけの情報から課金履歴を確認することができる。
他のタイプはレシートに記載されないデータを開発者側で保持しておく必要がある。
App Store を使用してレシートを検証/確認
JSONにレシートのバイナリデータを含めてAppleのサーバへPOSTすると、そのレシートが正しいものか検証され、正しいであればレシートの情報がJSONで返される。
Sandbox環境: https://sandbox.itunes.apple.com/verifyReceipt
本番環境: https://buy.itunes.apple.com/verifyReceipt
pros
- 自前のサーバから App Store へ接続すればセキュリティの担保が可能
cons
- デバイスから直接 App Store へ接続することは推奨されていないため、自前のサーバを用意する必要がある
- 通信が必要
参考
ローカルでレシートを検証/確認
App Store を使用したレシートの検証/確認と同じことをローカルで行う。
pros
- 通信が必要ない
cons
- セキュリティ的に完全ではない
- アプリのバイナリが解析されてパッチを当てられたりする可能性がある
参考
自前のサーバで購入履歴を管理
ユーザのアカウントに購入履歴を紐付ける。
ただし、Auto-Renewable Subscription は購読を中止したことを検知する必要があるため、定期的にレシートの検証が必要。
pros
- セキュリティの担保が可能
cons
- サーバ側の用意が必要
参考