Dir auch ein frohes Neues

IAP hat mit Datenbanken nichts zu tun: Letztlich muss in Deiner App ein "Verkaufsbeleg" (das sogenannte Receipt) überprüft werden. Apple bietet hier die Möglichkeit der remote Überprüfung, die im Backend über Apple's und eigene Server erfolgen kann. Das macht bei einer aufwendigen Verwaltung der Verkäufe absolut Sinn - und lässt Dich vielleicht an eine DB denken, ist aber keinesfalls notwendig:

Du kannst erweiterte Funktionen in Deiner App freischalten, wenn eine o. g. Receipt-Überprüfung ergeben hat, dass der Benutzer den entsprechenden IAP erworben hat. Das kann lokal in der App erfolgen, allerdings ist diese (kryptografische) Überprüfung ein etwas größeres Thema, ich nutze dafür Receigen und binde OpenSSL statisch ein.

Zusätzlich musst Du in der App natürlich die Möglichkeit des Kaufs und des Wiederherstellens von Käufen bieten...

Ich biete alle meine Apps als "Freemium"-Demos mit IAP an und finde das Vorgehen für beide - Entwickler und Benutzer - den optimalen Weg ... wenn das ganze nicht exzessiv für x kleine Funktionen benutzt wird.

Mattes

Lässt sich ein IAP so leicht manipulieren bzw. faken, dass eine Überprüfung des Receipt überhaupt erforderlich ist?

Ich kann nicht beurteilen, wie leicht man einen IAP faken könnte ... und wage zu bezweifeln, dass meine Zielgruppe (oder andere Akteure) bei meinen Apps dazu Interesse hätten.

Allerdings musst Du das Receipt ja schon interpretieren können, um einen IAP überhaupt zu identifizieren, auch ohne Validierung der Signatur, Ausstellerzertifikate etc.

Mit der Begründung, fertige Lösungen würden den notwendigen Schutz vor Reengineering schwächen, bietet Apple keine "Out-of-the-box"-Lösung an. Ich wollte mir die Zeit (und potentielle Fehler) einer eigenen Implementierung sparen und setzte daher auf die o. g. Software...

Mattes

Theoretisch könntest Du natürlich den IAP anbieten und bei Erfolg nur ein Flag in den UserDefaults setzen ... das ist aber zu kurz gedacht:

Zum einen ist das Umgehen des IAPs eine Gefahr - bei 0,99€ vielleicht überschaubar. Wichtiger ist aber, dass Du ein Wiederherstellen der Käufe von "non-consumable goods" bieten musst: Wie sonst sollte jemand seinen Kauf auf einem neuen Gerät oder nach einer Neuinstallation nutzen können? Das geht nur mit einer Receipt-Validierung.

Alternativ könntest Du ja eine Spende als "consumable good" erbitten: Dann kannst Du Dir diesen Umstand sparen und ich finde es - bei kleinen Apps - eine sinnvolle Alternative zu Werbung. Bei der deutschen Sparmentalität wird dabei aber kein neuer Mac abfallen...

Mattes

Moin Ferdinand,

schau mal hier: blckbirds.com/post/how-to-use-…urchases-in-swiftui-apps/

Schöne Grüsse
Wolf

Ich bleibe aber dabei, dass ein Speichern der Käufe in den UserDefaults eine schlechte Idee ist. Spätestens wenn die iOS-App auf einem M1-Mac läuft, kommt jemand auf die Idee, die .plist einfach zu manipulieren (oder an andere zu verteilen).

Die Notwendigkeit einer Receipt-Validierung haben einige App-Publisher in den Anfangstagen des App-Stores auf die harte Tour lernen müssen...

Mattes