support in-app purchase within free apps
This would:
1. create a "trial ware" business model option.
2. increase lite-to-paid conversions by enabling impulse buys: finish the last free level of a game? buy the whole thing right from the app and play through!
3. simplify lite-to-paid data migrations. e.g., when switching from a lite-to-paid version of a productivity application either (a) I have to re-enter all my todos or (b) the developer has to create server infrastructure to do it for me.
AdminDan Grigsby
(Admin, The Unofficial iPhone SDK Feedback Project)
shared this idea
9 comments
-
Mr.Rosicky
commented
Where can I download unofficial iphone sdk (all link on internet was died)?
Can you help me or send it to me via email mr.rosicky@gmail.com
Thanks for advance. -
Martin Grider
commented
ganesh: Sorry, I realize that last comment was a bit vague. I wasn't saying I hate your idea. I was saying I LOVE your idea. :) What I hate is the current topic: "support in-app purchase within free apps". Sorry about that.
But I've come to realize that it's the whole idea of in-app purchases that I hate, not really whether they're in free or paid apps. I hate the idea of anything that has an indeterminate price tag. I think the thing that would "fix" in-app purchases for me would be if apple displayed all the possible purchases along side the app itself in the app store.
-
ganesh
commented
@Bill, although Apple could potentially check the description of every apps, it's clear to everyone that it's not happening. Whether it's laziness or simply because the task would take a gigantic amount of resources I can't tell (I presume the latter, by the way). Putting the onus of advertising in-app purchase to the developer is pointless: if a developer is honest she would do that anyway, but if she's not, she will try hard to obfuscate the thing and she probably won't be caught. On the other hand, the App Store does know whether the app is in-app purchase enabled, so it wouldn't be difficult to show that to the user in a clear and unambiguous way.
Having a separate category would not prevent in-app purchases to be used in free apps. Simply, instead of being "Free" apps, they will be "In-app purchase" apps with a base price of $0.
@Martin: I don't understand what you hate about my suggestion. Could you be more specific, please?
Anyway, thinking at in-app purchases with the attitude "I paid for the damn thing, you want me to pay again?" is reductive to say the least. It's a different business model. For example I may release a game with episodic content. As a small developer, programming all episodes before shipping is a great financial risk, therefore the idea is to sell the game as soon as the first episode is finished and start getting some money and precious feedback while developing the rest of the episodes. Without in-app purchase I have to release several apps, one for each episode. This is very impractical for the user, because she will have one icon on the springboard for each episode and she can't easily share savegames between episodes. It's also impractical for me, because each time I make a new release, I have to upgrade all apps. With in-app purchase there will be only one app and it's a win situation for everyone.
Ah, and there are not just games in the world. Consider apps with subscriptions, for example to newspapers or magazines. There are endless opportunities.
-
Billy Gray commented
@ganesh, i think the provider should be required to describe the in-app purchasing in the app's store description, if used, but i don't think they should become an additional and distinct category of application, preventing the use in free apps, etc...
-
Martin Grider
commented
I'd vote for ganesh's suggested "display apps that support in-app purchase to end users" feature FOR SURE, but as written, I hate this idea. Free should be free. The whole idea of in app purchases kind of pisses me off. I paid for the damn thing, you want me to pay again? What?!!?
-
Dan, got my vote!
With regard to data migrations from Lite to Paid apps, we came up with a hack for Strip Lite -> Strip. We basically package up the DB, base64 encode it, forward it via URL to the pro version of the app with the base64 encoded DB as a parameter. Works great, allows you to skip some kind of server infrastructure component, keeps all data on device. Was thinking to put together a demo or tutorial if anyone's interested, but it's pretty easy to implement on your own.
Cheers,
B -
ganesh
commented
@nevyn: We actually agree, but you probably didn't get my point. My point is that applications that allow in-app purchase should be clearly labeled as such in the App Store and put into a different category from "Free" and "Paid". The main benefit is that the user is made aware that more money will be asked to her to unlock/get some of the application features. This means that the only objection that created the dreaded "free-forever" policy in the first place is removed and applications could be priced $0 without any (reasonable) risk of cheating the user.
By the way this is what it's being done with game consoles: games that have an in-app purchase feature are clearly labeled as such on the game box. Now, in the App Store, you can't tell if a paid application uses in-app purchase unless you read the app description. But descriptions, as you reported, can be deceptive. "In-app purchase" is not a feature, it's a different business model, which should, IMHO, be recognized and clearly advertised by the App Store itself. My mentioning of the term "try before you buy" was probably misleading: every app with in-app purchase should be part of this new category regardless the "entry" price being $0 or $1 or $100. -
nevyn
commented
ganesh: I get that argument, but Apple's solution ("free should be free") only makes the matter WORSE. See [1]; in short, say you download a free app, and you find out it's basically useless without making in-app purchases. Okay, annoying, but you've lost nothing. With the current situation, you've *paid* and downloaded for an app, *and* you find out it's useless without in-app purchases. Now you've lost money, and you're mighty pissed. How is this situation in any way better than had the app been free? It's already happening, see [2].
Re the "Try before you buy" (aka shareware) alternative: Devs have been asking for this since day one, but apparently it's nothing Apple cares for.
[1]: http://www.marco.org/127294959
[2]: http://www.techcrunch.com/2009/06/23/iphone-in-app-purchases-already-leading-to-the-dreaded-two-words-bait-and-switch/ -
ganesh
commented
I understand why Apple want to stick with the policy "a free app will always be free" and that's because there is the possibility for a developer to misuse the in-app purchase feature by luring users with free apps and then ask for money. One thing to avoid this could be to create a third app class between "Free" and "Paid", namely "Try before you buy" (better names are welcome) precisely for free apps with in-app purchase enabled. With that, application would be clearly labeled in the App Store, providing the correct information to the users and reducing room for misuse.
