InApp Käufe mit adapty.io

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Kurz gesagt: Nein…

    Aber aus Neugier habe ich mich einmal auf deren Seiten und dem iOS-SDK umgeschaut: Was mir sofort (negativ) auffiel, waren die Optionen zu Analytics: Aus Verkaufssicht vielleicht charmant, für den Benutzer und aus Gründen der Datensparsamkeit eher nicht. Mich schreckt so etwas ab… Auf jeden Fall sollte es bei entsprechenden Apps in den Datenschutzerklärungen berücksichtigt werden.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • bastl schrieb:

    ich versuche gerade mich in das Thema InApp einzuarbeiten und verzweifle grad und bin auf die Seite als Notlösung gestoßen.
    Schau vielleicht einmal in diesen Thread:

    Letztlich hängt die beste Lösung von verschiedenen Faktoren ab: Deinem Anwendungsfall (z. B. Abos, Backend-Anbindung, Verbrauchsgüter oder Non-Consumables), dem unterstützten Deployment-Target, dem Grad Deiner Paranoia etc. Ich will hier nicht in den Verdacht geraten, Werbung zu betreiben, bin aber für Non-Consumables mit der Implementierung über Receigen sehr zufrieden ... wäre da nicht die potentielle Gefahr durch die externe Abhängigkeit. Diese wird Du aber mit allen 3rd-Party-Anbietern haben.

    Ich habe meinen Frieden mit der aktuellen (lokalen) Receipt-Validierung gemacht und würde im Worst-Case wahrscheinlich auf die - nicht empfohlene - direkte Überprüfung per App-Store wechseln. Allerdings verwende ich kein Abo-Modell und plane auch nicht, ein solches einzuführen. Bei höherem Deployment-Target wäre StoreKit 2 mein Favorit...

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • ok, habe mich nochmal eingehend damit beschäftigt. Habe auch ein gutes Video bei youtube gefunden und konnte meine Zwecke (kleine Entwicklerspende) damit umsetzen.

    Wenn ich nun auch einen Kauf für erweiterte Funktionen einbauen will, klappt das auch. Sogar die Wiederherstellung habe ich mit reinen Applebordmitteln geschafft. Ich bilde mir ein, dass ich den Kauf bzw. die Wiederherstellung verschlüsselt oder im KeyChain abspeichere und damit auf der sicheren Seite bin. Kann da was vom Anwender geändert/manipuliert werden oder was meinst Du mit "dem Grad Deiner Paranoia etc." ?
  • bastl schrieb:

    konnte meine Zwecke (kleine Entwicklerspende) damit umsetzen.
    Meinst Du mit "damit" die Receipt-Validierung über das AppStore-Backend oder StoreKit 2 ... oder etwas anderes?

    bastl schrieb:

    Kann da was vom Anwender geändert/manipuliert werden oder was meinst Du mit "dem Grad Deiner Paranoia etc." ?
    Ich meinte eigentlich die Kommunikation zum Backend, von der Apple - zu Recht - sagt, dass man sie vom Device aus nicht vollkommen gegen Manipulation absichern kann. Die Abwägung ist, welcher Anwender / welche Anwenderin den Aufwnd betreibt (und das Wissen hat), diese Validierung zu faken ... und ob eine solche Person andernfalls überhaupt eine Lizenz erwerben würde. Ich glaube, im Regelfall nicht.

    Aber die lokale Speicherung des IAPs ist natürlich auch ein Angriffsvektor. Mit der KeyChain bist Du vielleicht gegen externe Manipulationen recht gut geschützt. Wie es gegen Eingriffe des Benutzers - insbesondere unter macOS - hilft, ist mir noch nicht klar ... da werde ich mich beizeiten mal schlau machen, gute Idee. Ich plante bisher, die UserDefaults zu benutzen: Ein Attribut über den erfolgten IAP kann dort natürlich leicht überschrieben werden, allerdings würde ich dies bei bestehender Internetverbindung direkt zurücksetzen: Der Nutzen wäre also sehr begrenzt, ausser der Mac wäre nahezu immer offline. Letztlich eine Risikoabwägung, bei meinem Kundenkreis ist die Gefahr einer Raubkopie eher übersichtlich.

    Letztlich ist m. E. eine gute Software-Qualität und ein guter Support das beste Mittel gegen Raubkopien.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • ich meinte, dass mir über die Funktion

    Quellcode

    1. func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction])
    die Kaufabwicklung bestätigt wird. Sollte ich da noch etwas tun?

    Zum Thema "Receipt-Validierung" habe ich im Zusammenhang mit Abos was gelesen. Puh - ich glaube, mir fehlt da noch einiges an Wissen.
  • bastl schrieb:

    ich meinte, dass mir über die Funktion

    Quellcode

    1. func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction])
    die Kaufabwicklung bestätigt wird. Sollte ich da noch etwas tun?
    Definitiv! Du hast schon recht, dass Du die aktuelle Kaufabwicklung über die genannte Delegate-Methode gemeldet bekommst. Bei Spenden ist das ausreichend, letztlich sind diese consumable goods, die jederzeit neu erworben werden können und in der App keine dauerhafte Auswirkung haben: Maximal möchtest Du Dich nach der Transaktion für die Unterstützung bedanken - so habe ich es zumindest in einer meiner Apps realisiert.

    Bei "echten" IAPs zum Freischalten von Funktionen sieht es aber anders aus: Was ist z. B. wenn die App vom Geräte gelöscht und später - vielleicht sogar auf einem anderen Gerät - neu installiert wird? Dann muss der Kauf - der im Receipt hinterlegt ist - von der App wieder honoriert werden. Da rettet Dich auch keine Information in der Key-Chain. Letztlich müssen die Käufe beim alten StoreKit aus dem Receipt gelesen werden, sozusagen eine Erweiterung der "einfachen" Validierung, die Dich nur vor Raubkopien schützt (was bei Freemium-Apps wenig spannend ist).

    In StoreKit 2 gibt es API-Funktionen für Transaktionshistorien und aktuelle Käufe / Abos, dann sollte es leichter werden.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • ich habe den "restore" mal so probiert

    Quellcode

    1. func paymentQueueRestoreCompletedTransactionsFinished(_ queue: SKPaymentQueue) {
    2. for transaction in queue.transactions {
    3. let iapKauf: SKPaymentTransaction = transaction
    4. let prodID = iapKauf.payment.productIdentifier as String
    5. switch prodID {
    6. case "de.apptec_media.ColorBlocks.shaking":
    7. self.view.backgroundColor = UIColor.systemRed
    8. break
    9. case "weitere":
    10. break
    11. default:
    12. print("iap not found")
    13. }
    14. }
    15. }
    Alles anzeigen
    und das klappt.

    Zum Testen habe ich Folgendes gemacht:
    1. also erst kaufe ich den "roten Hintergrund" :D
    2. das speichere ich aber nicht ab
    3. verlasse den View
    4. gehe wieder rein und mache den "restore" mit der Funktion oben und habe den roten Hintergrund wieder
    5. wenn ich den Kauf noch einmal versuche, dann bekomme ich den Hinweis, dass ich das schon gekauft habe

    Gefühlt passt eigentlich alles, oder liege ich da falsch?
  • bastl schrieb:


    Gefühlt passt eigentlich alles, oder liege ich da falsch?
    Prinzipiell schon, bedeutet aber, dass (1.) Du Dir permanente Käufe irgendwo merkst (mit der Gefahr der Manipulation), (2.) Deine Kunden bei Neuinstallationen immer die "Restore"-Funktion ausführen und (3.) Du keinen Schutz vor unautorisierten Installationen hast.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.