Probleme mit App Publishing wegen fehlenden 'Restore Button' für in App Käufe?!

yockl · 9. Oktober 2020, 10:35

Hallo zusammen,

ich hoffe Ihr könnt mir hier bei einer Sache weiterhelfen?

Wir versuchen, gerade unsere App im App Store hochzuladen. Leider wurde uns diese jetzt abgelehnt (Guideline 3.1.1 - Business - Payments - In-App Purchase) mit der Begründung, dass wir keinen „Restore Button“ in der App haben um die in App Käufe wiederherzustellen.

Zum Hintergrund: Wir haben alle in App Käufe mit der E-Mail-Adresse des Benutzers Server Seitig verknüpft und daher spielt es keine Rolle ob der User mit einem neuen oder sich gleichzeitig mit 5 Smartphones anmeldet. Es stehen ihm immer alle in App Käufe sofort nach dem anmelden zur Verfügung ohne etwas manuell wiederherstellen zu müssen.

Für Android haben wir das exakt gleich umgesetzt und die App wurde Problemlos im Play Store veröffentlicht.

Kann mir jemand erklären warum sich Apple hier so quer stellt und bedeutet das im Umkehrschluss das wir den Restore Button hinzufügen müssen oder haben die das ggf. vielleicht nicht verstanden wie wir das gelöst haben (was ich definitiv nicht glaube)?

Vielen Dank vorab

MyMattes · 9. Oktober 2020, 10:53

yockl schrieb:

Kann mir jemand erklären warum sich Apple hier so quer stellt und bedeutet das im Umkehrschluss das wir den Restore Button hinzufügen müssen oder haben die das ggf. vielleicht nicht verstanden wie wir das gelöst haben (was ich definitiv nicht glaube)?

Ich bin nicht sicher, Euer IAP-Prinzip 100% verstanden zu haben: Macht Ihr die Receipt-Validierung server-seitig und nutzt aber für Kauf etc. das SKStoreKit? Oder habt Ihr einen eigenen Verkaufsprozess, und schaltet Funktionen einfach nach Prüfung der eMail-Adresse im Backend frei?

Im ersten Fall könnt Ihr Apple natürlich in länglichen Diskussionen erklären, warum Ihr keinen "Restore Purchases"-Button benötigt. Falls es dieses Mal gelingt, werdet Ihr die Diskussion wahrscheinlich beim nächsten Update erneut führen müssen, App-Reviews zeichnen sich nicht durch konsistentes Auslegen der Guidelines aus. Einfacher und nervenschonender ist wahrscheinlich, eine entsprechende Funktion einzubauen, die einen Restore-Request absetzt.

Im zweiten Fall bewegt Ihr Euch m. E. auf sehr dünnem Eis, da Apple Verkäufe, die an ihrem Ökosystem vorbeigehen, nur bei wenigen (großen) Anbietern zulässt ... letztlich geht ihnen dabei die Provision flöten.

Mattes

yockl · 9. Oktober 2020, 11:33

Genau, wir haben das SKStoreKit implementiert für die in App Käufe bei Apple. Wir speichern und Verknüpfen alle in App Käufe in unserer App Datenbank (MariaDB) welches wir über einen WebService abfragen. So haben wir die Möglichkeit, dass ggf. ein IOS User im Anschluss ein Android nutzen kann ohne auf seine in App Käufe verzichten zu müssen. Wir haben wirklich keinerlei Möglichkeiten außerhalb von den App Käufe zu tätigen, aber das müssen die einen erstmal glauben.

Siehst du da irgendwie einen Ansatz das so ohne Restore Button durchzubekommen?

MyMattes · 9. Oktober 2020, 11:55

yockl schrieb:

Siehst du da irgendwie einen Ansatz das so ohne Restore Button durchzubekommen?

Naja, natürlich kannst Du auf die Ablehnung reagieren und Euren Fall erläutern. Ich musste so einmal mein Preismodell rechtfertigen, als ich eine ehemals kostenpflichtige App in eine Freemium-Version umwandelte. Das war allerdings eine einmalige Sache und man hört häufig von (Update-) Reviews, die Sachen reklamieren, welche vormals akzeptiert wurden. Also selbst im Erfolgsfall bleibt das eine tickende Zeitbombe, insbesondere wenn Ihr mal ein kritisches Update „rausdrücken“ müsst.

Inhaltlich sollte Euer Konzept verargumentierbar sein, ein expliziter „Restore“-Button o.ä. wird nicht (mehr) gefordert:

Apple schrieb:

Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.

Mattes

Marco Feltmann · 9. Oktober 2020, 15:17

yockl schrieb:

Siehst du da irgendwie einen Ansatz das so ohne Restore Button durchzubekommen?

Ich nicht.
Als Nutzer erwarte ich diesen verdammten Button, weil sonst nirgendwo ersichtlich ist, ob ich das Ding jetzt in vollem Umfang nutze oder nicht.
Gut, bei einigen Systemen ist ersichtlich, ob ich das Ding jetzt in vollem Umfang nutze oder nicht.

Bei Eurem vermutlich nicht.

MyMattes · 9. Oktober 2020, 16:56

Marco Feltmann schrieb:

Als Nutzer erwarte ich diesen verdammten Button, weil sonst nirgendwo ersichtlich ist, ob ich das Ding jetzt in vollem Umfang nutze oder nicht.

Das ist für mich ein anderes Thema:

Es gibt eine Option (Menüeintrag o.ä.), den IAP zu tätigen. Hier erwarte ich eine Preisinformation und einen Indikator, ob der Kauf bereits getätigt wurde: Haken und disablen, Text ändern, ...
Zusätzlich gibt es die Möglichkeit des Wiederherstellens auf anderen / neuen Geräten, nach Restore etc.

Wenn die App eh den Kauf (und damit das Freischalten von Features) im Backend prüft - und somit kein aktuallisiertes Receipt benötigt, ist ein Refresh-Request unnötig, die erste Option oben würde immer den aktuellen Stand wiedergeben.

Natürlich weiss ich nicht, ob der TO es so löst, aber so würde ich es handhaben.

Mattes