Die einzige Möglichkeit, dies wirklich zu verhindern, besteht darin, alles über Ihre eigenen Server zu steuern. Selbst der berüchtigte "com.zeptolab.ctrbonus.superpower1" -Bon ist ein tatsächlich gültiger Beleg, den Apples eigener Validierungsendpunkt Ihnen mitteilen wird, dass er in Ordnung ist. Sobald eine Transaktion abgeschlossen ist, sollte die App die Transaktionsdaten an einen Server senden, den Sie steuern, und:
Validate the receipt with Apple von Ihrem eigenen Server.
Wenn Apple sagt, dass es in Ordnung ist, analysieren Sie das Feld product_id von Apples Antwort und stellen Sie sicher, dass es sich um eine Produkt-ID aus Ihrer App handelt.
Wenn die ersten beiden Elemente erfolgreich sind, geben Sie die Daten zurück, um Ihrer App mitzuteilen, wo Sie Ihre Inhalte herunterladen können (sofern es sich um gehosteten Inhalt handelt).
Auch das hat einen Fehler, vor allem wenn Ihr IAP-Inhalt einfach auf dem Gerät aber "gesperrt" ist. Es gibt Möglichkeiten, den Bestätigungsaufruf von Ihrem Server umzuleiten, damit Ihre App denkt, dass Ihr Server "alles in Ordnung" sagt. Dies ist viel schwieriger, wenn Ihre IAP-Inhalte remote gehostet werden, da sie die Antwort mit dem Speicherort des Inhalts nicht so leicht fälschen können, wenn sie nicht wissen, wo der Inhalt an erster Stelle steht.
Das Problem in all diesen für die meisten Menschen ist, dass die Kontrolle Ihrer eigenen Server und Remote-Inhalte kann teuer werden, ganz zu schweigen von der Notwendigkeit, Ihre eigene Validierungslogik zu schreiben. Je schwieriger es für diese Hacks ist, erfolgreich zu sein, desto mehr kann es Sie kosten, also müssen Sie abwägen, wie viel Sie sie "leiden" lassen wollen mit wie viel Zeit, Mühe und Geld Sie ausgeben wollen vs. wie viel du machst und/oder verlierst. Denken Sie daran, dass ein "raubkopierter" IAP nicht unbedingt einem verlorenen Verkauf entspricht, daher kann es schwierig sein, abzuschätzen, wie viel Sie davon verlieren könnten.
Leiden, haha. Du solltest wahrscheinlich nicht den Schlaf darüber verlieren. – Wain