Ich habe eine App, die ich als kostenlose (Lite) Version mit einigen der gesamten Funktionalität und einer kostenpflichtigen Vollversion mit erweiterten Funktionen veröffentlichen würde. Jetzt, mit In-App-Kauf für kostenlose Apps, denke ich daran, diese Route mit der Fähigkeit, Funktionen nach Bedarf zu entsperren. Ich spreche nicht über eine Testversion, die abläuft. Ich möchte, dass die Leute in der Lage sind, die App auszuprobieren und eine Vorstellung von der Schnittstelle und Funktionalität zu bekommen, bevor sie sich entscheiden, die volle Funktionalität jedes Hauptteils der App zu kaufen.
Hier ist eine Analogie, wie meine App aussehen würde. Nehmen wir an, Sie haben eine Koch-App, die Ihnen beibringt, in verschiedenen Stilen zu kochen. Es könnte einen großen Abschnitt für Französisch, Italienisch und Chinesisch geben. Jeder Abschnitt kann einige Rudimente in der kostenlosen App freigeschaltet haben, so dass Benutzer die Benutzeroberfläche und Grundlagen der Funktionalität sehen können. Dann könnte der Benutzer entscheiden, jeden Hauptabschnitt (oder nicht) einzeln mit In-App-Kauf zu kaufen oder die Vollversions-App (mit dem kostenlosen / kostenpflichtigen Modell) zu kaufen.
Eine Sorge, die ich mit dem Angebot einer kostenlosen App mit In-App-Kauf habe, wäre eine Rückmeldung. Ich würde sehr klar in meiner Beschreibung im App Store, dass es in App-Kauf für volle Funktionen gibt, aber ich bin besorgt, dass weniger ernsthafte Benutzer negatives Feedback hinterlassen könnte / würde. Ich nehme an, das ist immer ein Risiko, aber neugierig auf jede Erfahrung mit diesem.
Es scheint auch, dass es viel komplizierter sein könnte, zu verfolgen, welche Teile der App mit dem App-Kauf gesperrt und entsperrt werden. Ich weiß, ich müsste den ganzen Code für die volle Funktionalität haben und die Teile sperren, die nicht gekauft worden sind. Wie sperren Leute normalerweise Teile ihres Codes? Ich spreche nicht über den Kaufprozess (ich habe den In App Purchase Programming Guide gelesen), sondern nachdem der Kauf getätigt wurde. Würde ich nur verfolgen, was der Benutzer gekauft hat, und Bedingungen für die Bereiche festlegen, die ursprünglich gesperrt waren? Oder gibt es einen anderen Weg, dies auch zu tun?
Mein Instinkt ist für den In-App-Kauf (vor allem, weil Benutzer die Hauptabschnitte kaufen können, die sie einzeln wünschen).
Ich würde sehr empfehlen, den In-App-Kauf über verschiedene Versionen hinweg zu nutzen.
Wenn Sie verschiedene Versionen haben, müssen die Benutzer das Ganze erneut herunterladen, wenn sie ein Upgrade durchführen wollen. Dies bedeutet, dass sie doppelt so viel Speicherplatz benötigen und doppelt so viel Netzwerkbandbreite benötigen, um sie zu aktualisieren.
Ich glaube nicht, dass Ihre Bedenken hinsichtlich der Überprüfung begründet sind. Wenn Ihre Bewerbung gut gemacht ist und die Nutzer es mögen, erhalten Sie positive Bewertungen. Um zu vermeiden, dass Benutzer verwirrt werden, vergewissern Sie sich, dass in der Anwendung eindeutig angegeben ist, was gekauft werden kann. Außerdem mögen manche Leute einfach alles nicht und geben dir einen Stern. Diese Benutzer sind unvermeidlich, aber wenn Ihre App gut ist, sollte es genug gute Bewertungen geben, um sie auszugleichen.
Sie haben Recht mit der Annahme, dass Sie Bedingungen für gesperrte / entsperrte Inhalte haben müssten. Dies sollte jedoch kein enormes Problem sein. Behalten Sie einfach bei, was der Benutzer gekauft hat ( vorgeschlagen von Apple ) oder einem anderen dauerhaften Speicher und erstellen Sie eine Klasse, die Sie abfragen können, um herauszufinden, ob eine bestimmte Funktion erworben wurde.
Ich denke, es macht Sinn, eine Lite-App (mit freischaltbaren Inhalten über IAP) und eine voll bezahlte App zu haben. Ich sage dies basierend auf eigenen Erfahrungen mit dem Verkauf von Apps im AppStore. Bei Interesse können Sie sich meinen Beitrag in unserem Unternehmensblog über IAP vs kostenpflichtige App anschauen.
In zwei Worten - eine Lite-Version mit IAP und eine kostenpflichtige Version erhöht den Gesamtumsatz im Vergleich zu nur lite mit IAP oder lite + paid.
Tags und Links iphone in-app-purchase