Jon,
Thanks for the detailed walk-through! So you’re saying that Apple will reject an app if we use showWebPopup instead of opening the store in Mobile Safari? [import]uid: 8194 topic_id: 475 reply_id: 6888[/import]
Jon,
Thanks for the detailed walk-through! So you’re saying that Apple will reject an app if we use showWebPopup instead of opening the store in Mobile Safari? [import]uid: 8194 topic_id: 475 reply_id: 6888[/import]
This seems pratically what the kindle app does, obviously on their own servers. It should not violate any rules. The only issue that you will have is dealing with refunds and all the other pain the ass customer stuff. I think 30% to apple to deal with that is worth it. [import]uid: 8192 topic_id: 475 reply_id: 6892[/import]
@dknell: I don’t personally own the Kindle app, so I’m not sure if they close the app and open mobile Safari, or if they use a Web Popup. If they close and open mobile safari, then I assume it’s against the TOS somehow to simply open a web popup. However, on the other hand, if they DO simply open a web popup within the app… then that’s even better for folks like us because you can easily make the user feel as though they never left your app.
Perhaps someone who uses Kindle for iPhone can give us some more clarity on that.
@amigoni: You could always include a clause in your TOS upon signup, that they must agree to when they create their account, that states that anything purchased from the web store is non-refundable.
I also think it might be easier to use Facebook connect for their login information, that way you don’t have to keep track of their username/password. Instead, they would log into Facebook, you extract their Facebook ID (long string of numbers) and use THAT as the id that gets interfaced with your database. I do that with the Facebook Friends leaderboard, and they pretty much log into Facebook once and then can see their friends leaderboard whenever they want (without having to constantly re-login). [import]uid: 7849 topic_id: 475 reply_id: 6905[/import]
My wife uses the kindle app and has purchased a bunch of books. I will check it out and let you know. [import]uid: 8194 topic_id: 475 reply_id: 6908[/import]
@jonbeebe: I have the kindle app. In iOS 3, it closes the app and opens safari. I don’t know if it is the same on iOS 4 and above. [import]uid: 8192 topic_id: 475 reply_id: 6910[/import]
FYI:: the ansca engineers are monitoring this forum thread very closely.
carlos [import]uid: 24 topic_id: 475 reply_id: 6914[/import]
@amigoni: Thanks a lot. It sort of struck me as out of bounds to simply open up a web popup “within” the app, since you’re still in the app.
I’ve been thinking a lot about my solution, and I think the best way to implement the solution I proposed is to focus a little bit more on “bundles” and less on single ($0.99c) in app purchases.
Of course, in your little web store you can still sell cheap singular items (e.g. the cow), but I think since they have to go through so much more effort to get to your store (close your app and open mobile safari), the focus should be put on “bundles” instead, so they get more at a better value. For example, instead of selling them a sheep for .99, instead, sell them a herd of sheep with a bonus chicken for $4.99.
A lot of people might think that’s ineffective, but the post linked below convinced me that IAP bundles are definitely worth it… and I think they’re likely to do better than single-item purchases in this temporary workaround (of course, until Corona includes some kind of IAP functionality).
–> http://gamesfromwithin.com/iap-bundles-more-than-just-good-deals
Another upside to my “solution” that I didn’t think about before (because it doesn’t apply to me just yet), is that this would at least be A solution for Android in-app purchases (or semi-in app anyway). As far as I know Android doesn’t have anything like IAP built in.
I guess you could call this whole thing “for-app” purchases, since they’re not in-app at all.
Whoever implements it first, let us know how it goes! Once I finish Dungeon Tap up and another title Biffy will be directing, I’ll work on a title with these “for-app” purchases and then let everyone know if apple approves or not.
If I’m lucky Corona will have IAP built-in by then and I won’t have to worry about it. [import]uid: 7849 topic_id: 475 reply_id: 6916[/import]
@jonbeebe
Check out this article. What you said about the bigger packages seems to be correct. Pocket Frog is a good example. Of course you have to have compelling packages.
http://www.pocketgamer.biz/r/PG.Biz/NimbleBit+news/news.asp?c=23626
@carlos: Great to hear. We all want to find a good solution or solutions that work for everyone.
Even though this might be technically possible there are still a couple of issues that are very important:
Consumer Trust. People trust to give money to apple. They trust to give money to Amazon. Will they trust giving money to us? I doubt it, unless we can do the transaction through a known brand such as PayPal or something of that stature. Only then they might trust that the purchase is secure and safe for them. Otherwise we might loose on many purchases just on that. Even if they use Paypal, most people don’t have a paypal account but every iOS user has an iTunes account. That’s unbeatable especially outside of the US. I bet you that this alone is worth the wait. Your customer base must be at least 10 times bigger through the iTunes Store.
Administration. Refunds, complaints, legal issues etc. Even if you have a disclaimer. There will be pissed off people and you will have to deal with them instead of apple or paypal or whomever it is. For me that is a huge issue. I have run a retail business for 7 years and you get to know what a pain dealing with customers is especially when they give you money. Say your app makes it huge and sells 1 million copies. Will you be ready to deal with all those customers directly since they are giving money to you? Although at that scale it might be consideration.
Porting over. What if one day you are forced or want to port over to inApp purchases? How will you handle the old purchases in the game then? How will you handle the transfer if any of information?
Apple shutdown. Apple might shutdown whatever solution we find at any time. They can just change their agreement.
Even if #3 is more of a technical issue. I think #1 and #2 are enough to sit and throughly think on what to do. Especially # 1. These are business related issues more than coding alone. [import]uid: 8192 topic_id: 475 reply_id: 6919[/import]
@amigoni: Below are my thoughts on all your points:
On #1 – As far as payments go, I would only implement it if going through a 3rd party was the only option. I personally was thinking of PayPal Mobile, but you can also go with Google Checkout, and Amazon even has a checkout solution, so I don’t see customer trust as being a huge issue. Chances are people who would be purchasing any of the items from your web store would have most-likely made an online purchase in the past, which makes it even more likely that they have already made purchases through Paypal, Google Checkout, or even Amazon.
On #2 – Since it’s for an iPhone app, I think people are generally used to not having the ability to refund, so I’m sure that would take care of a large number of ‘would-be’ refunds, and if you have a disclaimer stating no-refunds, that would make that number *even lower*. Of course, there will inevitably be some people who STILL want a refund. They can always contact you and perhaps a “quiet” refund can take place. If I had a million people doing in-app purchases, I would use some of that money to outsource the task of calming down any pissed off folks. Actually, if a million people were interested in buying things for my game, let’s just say that’s the kind of problems I WANT to be having lol.
On #3 – I never saw porting over to In-App purchases as a big problem. As far as I know, EVERYTHING can still work exactly the same as you had it before. The only difference would be the payment process for FUTURE purchases. The people who already purchased items would still have all their items, but any future items they purchase would simply go through the IAP-API. As far as I know, the API simply handles the actual purchase–you still have to figure out how to get the virtual goods to your users. With that said, your current system for “delivering” the virtual goods would still work.
On #4 – Yes, Apple could very well put a stop to the whole thing, so for that reason I would suggest only putting a few items in your web store initially and if your app gets approved, then add the rest. That way, you don’t waste a lot of effort creating the web store. Remember, this whole thing is meant to simply be a temporary fix until Corona comes out with actual IAP–so hopefully that would happen before Apple got “fed up” with this solution and decides to put a stop to it. Honestly, with apps like Kindle out there making it big time, I don’t think there is a problem with this system.
And if Apple were to put a stop to it, you’d simply remove the ‘Get Even More Supplies’ button from your app and you’re back at square one waiting for Corona… at least that whole process would have killed some of the waiting time
I don’t doubt that there would be LESS overall sales because of the extra few steps involved, but mobile checkout systems are meant to be quick, easy, and minimalistic, so I think as long as you keep things simple for the user, it could still work.
To me, putting up with LESS sales going the “for-app” route is much better than putting up with NO sales while waiting for the actual “in app” solution… and this way, you have pretty much everything in place (such as your game) for when the IAP features DO appear in Corona. [import]uid: 7849 topic_id: 475 reply_id: 6920[/import]
@carlos: I missed your reply, you must have submitted it while I was writing my last post. That’s really great to hear! [import]uid: 7849 topic_id: 475 reply_id: 6918[/import]
@jonbebee All very good points. I think if it works, It is a great “temporary” solution. While waiting for inApp purchases to be implemented by Corona or at least iOS and whatever system will be used for Android. [import]uid: 8192 topic_id: 475 reply_id: 6921[/import]
Another thought that I had was. That if Apple allows this it would be a good saving of 30% [import]uid: 8192 topic_id: 475 reply_id: 6922[/import]
@amigoni: Yup And if you go through a mobile checkout provider that provides a debit card (I know there are some out there, PayPal is one of them)… your payments are instant (instead of having to wait 1-2 months to get a check from Apple for all your “for app” purchases).
Doing things this way also opens up some other possibilities, like adding some kind of “web interface” to your games. For instance, on your server, you could even host a website that allows them to log in, check the stats of their “farm”, perform some of the simple tasks and even make purchases in their game. I think doing something like that makes it **even more** like Kindle since the content you purchase could be used in the browser version of your game and your iPhone app.
If you made the “web interface” very close to your actual game, you could open up your game to a whole new market: browser-based games market (many of those people don’t even own an iOS or Android device!). Like Farmville, people could log in and play their same account on their computer AND on their iPhone… and the “for app” purchasing system would be synced because it would obviously go through the same web store (even if you had to make a “desktop optimized” version of it for the browser-players).
A lot of things to think about. There are a lot of downsides, but there are also some up-sides. I think since IAP aren’t a possibility in Corona at the moment, then we should definitely be focusing on the up-sides since it’s really our only option right now (with Corona, that is).
[import]uid: 7849 topic_id: 475 reply_id: 6923[/import]
I am always impressed with how creative people are and how a little creativity goes a long way towards finding solutions. Very cool that you shared this clever approach. I don’t really care what technical decision ansca makes as long as it solves the problem. I hope they apply equal amount of creativity in their solution as well. Personally I would like to see the ability to include a header path or something for linking against native libraries or perhaps the ability to load a “bundle” or similar library at runtime. I don’t think something like that would be out of the question and wouldn’t be giving away too much in terms of how they want to hide some of their binaries. Long term there will always be features being added to these devices that might killer features to some and this is especially the case with the android platform based on how fragmented the platform is already getting because of OEMs. I really don’t want to see ansca in a position where they are playing “catch-up” or “whack-a-mole” with the latest features on any given device and this is already happening. Let’s hope they come up with a good solution. [import]uid: 6769 topic_id: 475 reply_id: 6933[/import]
One more thing is that I would really like to see Ansca promotion clever solutions such as this as either a showcase or guide to others to leverage the community and put gold stars next to good ideas. I was thinking a live document such as a wiki or sticky thread or something that stands out so others won’t have to fish around for commonly requested features. [import]uid: 6769 topic_id: 475 reply_id: 6934[/import]
Don’t underestimate the doubts a user will have when prompted to buy something from a webpage his has never visit again. This can easily be translated to a just <50% conversion rate, if not less. IAP works so well because users trust Apple and have a very quick purchase session with a flow they know well and have done successfully many times before. This security factor does not exist outside the app.
I think Ansca should not delay any iPhone specific features when there is no cross-platform solution available yet. The iPhone market is still a monopoly (in terms of developer income) and relevant features should be served as soon as possible. Android compatibility should be seen as a major evolving feature, not a commitment.
Just my thoughts…
PS: I also think that some 3G networks don’t fully allow https sessions, whick is required for paypal payments. [import]uid: 7356 topic_id: 475 reply_id: 6938[/import]
“The cut income due to various issues with this approach seems to invalidate it (from a business perspective).”
Since this is all theory you actually have no results that show a web-based solution would significantly affect income. Many people think it would, but there are (tens of, or hundreds of) thousands of businesses who market products from their main website and then send the person to a 3rd-party shopping cart for the actual transaction. That’s all this “work-around” is talking about.
And while most people believe an in-app solution would bring in more money, until someone does this – oh, wait, someone already does it. Amazon, as has been mentioned here. I’m someone who has purchased a book for the Kindle app on my iPhone, and it kicked me to Safari for the transaction and then when I went back into the Kindle app, there was my ebook.
Sounds like a proven system, at least for one company. =:)
Jay (J. A. Whye)
[import]uid: 9440 topic_id: 475 reply_id: 6944[/import]
Users may trust Amazon, but not “Magenda Wannabe Studios”. At least not at the same level.
Amazon has spent zillions for loyalty/brand making.
We, iIndies, are a kind of parasites, just like mushrooms: we can only grow under big trees. [import]uid: 7356 topic_id: 475 reply_id: 6949[/import]
I’m going to be honest since “the ansca engineers are monitoring this forum thread very closely”. While I appreciate the cross-platform “feature” of Corona, I don’t think that Android devices should hold back iPhone features in Corona. Same goes for Android - if something was available for Android and not the iPhone add it to the SDK and let us developers decide how or if we want to use it. We have the ability to test which device our app is running on.
One of the things that REALLY drew me to Corona was the release early release often philosophy. Coming from Gamesalad, this was a major selling point (well, not having the SDK crash every 2 minutes was nice too, among other things). Anyway, I hope that Ansca continues to release early release often despite shedding the beta moniker. Even if that means you release/test new features with beta versions that continue to be updated and then roll them into the stable versions once all the bugs have been fixed.
I am only speaking for myself - cross-platform is nice, but I’d rather have IAP, GameCenter, real UI components, etc for the iPhone than wait for work-arounds as a result of being cross-plaform. In my opinion Android is small potatoes - especially when it comes to developer profits. [import]uid: 8194 topic_id: 475 reply_id: 6951[/import]
“I am only speaking for myself - cross-platform is nice, but I’d rather have IAP, GameCenter, real UI components, etc for the iPhone than wait for work-arounds as a result of being cross-plaform. In my opinion Android is small potatoes - especially when it comes to developer profits.”
Very well said, and I completely agree. I wish we could take a poll to see what percentage of people here are developing for:
I think those features are a higher priority for developer than full Android support for them. Might be a different picture in 6 months to a year. But in the meantime our apps will be a bit established already in the iOS systems. And porting will be easier. [import]uid: 8192 topic_id: 475 reply_id: 6956[/import]