Dieser Artikel basiert auf einem X-Thread, den ich im September 2024 über den Start von youProof veröffentlicht habe. Die folgenden Details beziehen sich auf den damaligen Stand. youProof wurde nie zum Erfolg, aber ich habe dabei viel gelernt.

Im Juli 2024 habe ich meine erste App, youProof, im App Store und bei Google Play veröffentlicht. Sie kombinierte Ende-zu-Ende-verschlüsselte, digital signierte Visitenkarten mit digitalen Profilen. Die kostenlose Version reichte für die grundlegende Nutzung aus; kostenpflichtige Funktionen gab es im Abo.

Die App war mit Ionic/Capacitor gebaut. Im Backend lief Supabase mit Edge Functions auf Deno. Für die meisten Dinge funktionierte diese Kombination gut. In-App-Käufe erwiesen sich allerdings als mühsamer als erwartet.

Der Anfang mit Apple

youProof entstand zuerst für iOS, weil ich selbst im Alltag ein iPhone nutze. Also begann ich mit Apples System. Der grundlegende Ablauf ist bekannt: Man legt Produkte in App Store Connect an, jemand kauft etwas, die App erhält einen Kaufbeleg und man prüft diesen, bevor Funktionen freigeschaltet werden.

Wenn ein Kauf auf deiner Seite laufende Kosten verursacht, gehört die Validierung auf den Server. Apples Bibliotheken spielten damals nicht besonders gut mit Deno zusammen. Nach genügend Versuchen und Fehlschlägen beschloss ich, die komplizierten Teile lieber jemand anderem zu überlassen. Schließlich wollte ich die App auch auf Android anbieten.

RevenueCat

Ich sah mir ein paar Dienste für die Verwaltung von In-App-Käufen an und entschied mich für RevenueCat. Es gab ein Capacitor-Plugin und die damaligen Preise schienen mir vernünftig: 1 % des Umsatzes oberhalb einer bestimmten Grenze.

Die Einrichtung ist überschaubar:

• Produkte in App Store Connect und in der Play Console anlegen, in meinem Fall Abos.
• Die beiden Stores mit dem RevenueCat-Projekt verbinden.
• In der App nur noch mit dem RevenueCat-Plugin kommunizieren.

RevenueCat schickt dann Webhooks an dein Backend, wenn jemand etwas kauft, ein Abo verlängert oder kündigt oder es Probleme mit einer Zahlung gibt. Zwischen einem erfolgreichen Kauf und dem Eintreffen des Webhooks liegt meist eine kurze Verzögerung. Die sollte man einplanen.

Auch die mühsamen Details übernimmt der Dienst: Kaufbelege validieren, Nutzer über mehrere Plattformen hinweg zuordnen, Abos übertragen und so weiter. Die Dokumentation ist gut genug, dass sich die meisten Fragen damit beantworten lassen.

Was ich gelernt habe und wo es gehakt hat

An ein paar Dinge hatte ich beim damaligen Start nicht sofort gedacht:

• Bau einen Button zum Wiederherstellen von Käufen ein. Apple verlangt ihn, und er spart dir auch Supportaufwand, wenn auf Nutzerseite etwas schiefgeht.
• Du kannst Käufe mit Konten in deinem eigenen Backend verknüpfen. Verwende dafür die Login-Funktion des RevenueCat-Plugins mit einer Nutzer-ID aus deinem System. Diese ID ist dann auch im Webhook enthalten.
• Apple: Auch wenn sonst alles eingerichtet ist, kannst du erst richtig testen, nachdem du das Paid Apps Agreement akzeptiert hast. Außerdem muss mindestens ein Build hochgeladen sein, bevor sich In-App-Käufe einrichten lassen. Veröffentlicht sein muss er noch nicht.
• Android: Du musst mindestens einen Build veröffentlichen, bevor du In-App-Käufe konfigurieren kannst. Ein geschlossener Test reicht dafür aus.
• Tests: Bei Builds aus TestFlight und Xcode sind Testkäufe automatisch kostenlos. Auf Android musst du die Google-Konten, die kostenlose Testkäufe durchführen dürfen, ausdrücklich hinzufügen. Auch die Abozeiträume sind für Tests stark verkürzt.
• Beide Stores bieten Programme für kleine Unternehmen an, die die Gebühren von 30 % auf 15 % senken.

Durch den App-Review kommen

Sowohl Apple als auch Google lehnten die App zunächst wegen Problemen mit den In-App-Käufen ab.

Bei Apple kann das Review-Team Testkäufe durchführen, ähnlich wie bei TestFlight. Die Produkte selbst müssen aber zuerst freigegeben sein, und RevenueCat braucht Zeit, um sie zu synchronisieren. Wenn die App abgelehnt wird, weil die Produkte nicht laden, bitte darum, zuerst die In-App-Käufe und danach die App zu prüfen. Oder reiche sie erneut zur Prüfung ein, bis es klappt.

Google möchte die Abo-Bedingungen direkt auf dem Angebotsbildschirm sehen. Eine kurze, klare Formulierung reicht meist aus. Das Review-Team führt außerdem selbst keine Testkäufe durch, weil es das nicht will oder nicht kann. Deshalb braucht es ein Testkonto, das ohne tatsächlichen Kauf auf die kostenpflichtigen Funktionen zugreifen kann. Und deaktiviere keine Buttons für Funktionen hinter einer Bezahlschranke. Auf Android zeigte ich stattdessen am Ende einen Hinweis an. Die Buttons auszublenden, sollte vermutlich ebenfalls funktionieren.

Zum Schluss

Der Thread wurde länger als geplant. RevenueCat nahm mir einen großen Teil der Arbeit mit Kaufbelegen und den Unterschieden zwischen den Plattformen ab. Für ein Soloprojekt, das in beiden Stores funktionieren sollte, hat sich das gelohnt. Wenn du etwas Ähnliches mit Capacitor baust oder bei Abos weniger Überraschungen erleben möchtest, ist die Dokumentation ein vernünftiger Ausgangspunkt.

Zum Start ließ sich youProof kostenlos ausprobieren und war in der gesamten EU außer Frankreich verfügbar, mittlerweile auch in den USA: youproof.at.