Ich arbeite für eine Spielentwicklungsfirma, die mindestens ein Spiel pro Monat veröffentlicht. Für unsere wahren Fans möchten wir ein Abonnement für unsere Spiele anbieten, damit sie alle unsere Spiele (auf jeder Plattform) spielen können, ohne sie ständig kaufen zu müssen.
Die Idee für iOS besteht darin, das In-App-Abo zu verwenden, das automatisch verlängert werden kann. Dies führt zu einer Quittung, die wir in unserem Backend speichern. Das Back-End kann diesen Beleg validieren und den Apps Informationen über das Abonnement des Benutzers bereitstellen. Dieses System wird viele Probleme lösen: Sie können das Abonnement in einem Spiel nehmen und alle Spiele auf jedem beliebigen Gerät spielen.
Aber jetzt kommen wir zu dem Problem: Nach einem Monat ist der Empfang nicht mehr gültig und wir müssen im iTunes Store nachsehen, ob der Benutzer noch ein gültiges Abonnement hat.
Meine erste Idee war es, das Feld "next_receipt_info" zu verwenden, um den neuesten Beleg zu erhalten und dies zu bestätigen. Aber laut der Dokumentation sollte diese Funktion nur für iOS 6-Quittungen verwendet werden:
"Wird nur für Transaktionsretouren mit iOS 6-Stil für automatisch verlängerbare Transaktionen zurückgegeben Abonnements. "
Quelle: Ссылка
Obwohl ich dieses Feld tatsächlich immer noch mit meinem brandneuen iOS 10-Empfang verwenden kann, glaube ich nicht, dass es schlau ist, es zu benutzen, da es veraltet ist.
(Eine andere Quelle sagt Ihnen, dass Sie sie nicht mehr verwenden sollten: Ссылка )
Die empfohlene Lösung von Apple besteht darin, einen SKPaymentTransactionObserver in der App zu implementieren. Dadurch wird der neueste Beleg abgerufen, sobald er verfügbar ist, und an das Back-End gesendet. Auch wenn dies alles andere als ideal ist, könnte dies funktionieren ... jedoch:
Dies bedeutet, dass die App aktiv sein muss, um den neuesten Beleg abzurufen. Und in unserem Fall ist es sehr gut möglich, dass ein Benutzer ein Abonnement in app1 nimmt und nach ein paar Tagen die app2, 3 und 4 herunterlädt, aber nie wieder app1 verwendet. In diesem Fall wird der letzte Beleg niemals abgerufen (weil nur der Beobachter von app1 auf den Beleg zugreifen kann)
Um dieses Problem zu beheben, sollten wir in der Lage sein, die Belege aus diesem Abonnement von jeder App in unserer Abonnementgruppe abzurufen. Aber gemäß der Dokumentation auf der Apple-Website ( Ссылка ) können Sie nur auf ein Abonnement von 1 App und Sie zugreifen musst du die App selbst machen:
Sie können automatisch erneuerbar anbieten Abonnements für den Zugriff auf mehrere Apps in Ihrem Portfolio. Jede App muss genehmigt sein, um automatisch erneuerbare In-App-Käufe zu verwenden und müssen unter dem gleichen Entwicklernamen im App Store veröffentlicht.
In iTunes Connect müssen Sie separate und äquivalente Einstellungen vornehmen automatisch verlängerbare In-App-Käufe in jeder App, die in der Multi-App angeboten wird Abonnement, damit Benutzer von jeder App aus abonnieren können. Um Benutzer zu vermeiden mehrere Male für das gleiche Angebot zahlen, sind Sie verantwortlich für Überprüfen, ob sie Abonnenten in einer der Apps sind, bevor sie angezeigt werden irgendwelche Abonnementwahlen. Erwägen Sie dazu, ein Konto zu verwalten Verwaltungssystem, in dem Benutzer ein Konto mit Ihrem Unternehmen erstellen um sich bei jeder App anzumelden.
Gibt es also eine Möglichkeit, das zu tun, was wir wollen, ohne den Benutzer dazu zu zwingen, zu der App zurückzukehren, mit der er das Abonnement jeden Monat gekauft hat?
Auf der letzten WWDC sind wir zu StoreKit Labs gegangen und haben StoreKit evangelisch persönlich darüber befragt. Uns wurde gesagt, dass das Feld "latest_receipt_info", das vom iTunes validateReceipt-Endpunkt zurückgegeben wird, genau das ist, was wir verwenden sollen, um zu überprüfen, ob das Abonnement erneuert wurde oder nicht. Dies wird nicht in naher Zukunft veraltet sein, aber sie haben Pläne, einige Server-zu-Server-Kommunikation hinzuzufügen, die einige der Probleme lösen, mit denen wir konfrontiert wurden:
Quellen:
WWDC 2017 Sitzung 303 - Was ist neu in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit
Tags und Links ios in-app-purchase subscription