netshade · August 18, 2011 18:45
diff --git a/gistfile1.txt b/gistfile1.txt
 Just a thought experiment on how to identify a phone's iTunes user account as they migrate from phone to phone ( they have to have purchased an IAP item from you ).

 The first time someone buys an IAP item from you, they'll create an SKPayment with you. If you add it to an SKPaymentQueue, this payment is now tied directly to your app bundle identifier and the iTunes account. So long as you NEVER call finishTransaction: on the resultant SKPaymentTransaction, iTunes will try to restore this payment in your app as the iTunes account of the user migrates from phone to phone.  I believe you could try to do something similar with SKPaymentTransaction's originalTransactions property, such that instead of leaving a payment constantly in the queue, you always call restoreTransactions at the start of your app, and inspect the originalTransaction property's transaction id ( compared w/ some stored transaction id you have on your own server to support migrating all associated data w/ the iTunes account ).

 Lacking some way to tie information directly to someone's iTunes user account, it'd be an interesting way to sort of tie app specific data w/ an iTunes account.  This is probably all moot w/ the advent of iCloud however. :-)
	Just a thought experiment on how to identify a phone's iTunes user account as they migrate from phone to phone ( they have to have purchased an IAP item from you ).

	The first time someone buys an IAP item from you, they'll create an SKPayment with you. If you add it to an SKPaymentQueue, this payment is now tied directly to your app bundle identifier and the iTunes account. So long as you NEVER call finishTransaction: on the resultant SKPaymentTransaction, iTunes will try to restore this payment in your app as the iTunes account of the user migrates from phone to phone. I believe you could try to do something similar with SKPaymentTransaction's originalTransactions property, such that instead of leaving a payment constantly in the queue, you always call restoreTransactions at the start of your app, and inspect the originalTransaction property's transaction id ( compared w/ some stored transaction id you have on your own server to support migrating all associated data w/ the iTunes account ).

	Lacking some way to tie information directly to someone's iTunes user account, it'd be an interesting way to sort of tie app specific data w/ an iTunes account. This is probably all moot w/ the advent of iCloud however. :-)