I read (almost) all the answers on verifying in-app purchase, and actually I already implement it in a server-side fashion. But managing a server sometimes could be too much expensive, and in theory you could do the verify from your app: basically is just sending a json to Apple and get the answer back.
Of course I know that on jailbroken devices the receipts may be fake (that's why you verify them) but (I beg pardon my ignorance) why I can't trust an https connection to the Apple server?
I mean if the user hack my app, there's no real way to be sure of anything, but if the hack is a general method to provide fake receipts testing with Apple could be enough right?
To be clear, what is the security level of an in-app verify of recipts? Can it add some degree of protection os is useless?
This answer explains quite well why you must use server side checking to limit the effect of some "general purpose" crackers, like "IAP cracker"; besides chaining the iTunes json request in your content delivery API is quite convenient and the answer is fast.
Of course if your aim is to provide some content already in the app but locked, you may feel it is not convenient to setup a server specifically for this, but I will ask you to do this experiment:
- make an app with some good content and this content already locked in the app (so no content server need)
- add some analytics just to track the usage of this locked feature
- after some month, compare the number of purchases with the number of new users using the paid feature.
- at this point it will be clear for you that adding a server script just for receipt validation is a good investment; besides there are some services, which are very cheap (e.g.: urban airship) we already do this for you, so you don't need to setup an hardware for this.
I hack inapp cracker and discover a way to block it client side: the receipts and transaction IDs it creates have a predictable scheme that's easy to spot. I put all the details here:
spot fake receipts client side
update
hope this helps