My app has some downloadable (from my server) guides and maps, and user could buy them with InAppPurchase. I would like to update these guides once a month or like that, so users could buy the updates with half price. How should I implement InAppPurchase logic?
I mean, the most obvious solution for me is to create InApp's for every update. When user wants to update guide, he asks server for update's InApp ID, then purchase it, and download it from server. The previous guide will be deleted. The question: is that logic good? And won't Apple reject my app because I delete the content the user has paid for? (even I replace it with the newer one)
Or maybe there are more correct solutions?
Thanks in advance!
Why do you want to delete the previous ones?
Your logc is ok, but the only change i would make is to let the user choose, if he wants to delete the previous content or not, by asking him every time he buys a new one.
That wouldn't make him angry and would prevent a rejection by Apple.
Related
I have a (ios)free app for a while now in appstore and I am considering to change it to subscription app in the next update. It will be a subscription with the first month free.
I would like to know, from the user point of view, how will he know that updating the app will change the type of payment from free to subscription ? Anyone has experience in the matter ?
Thank you
Well from a user standpoint it's quite common to update a well running app to subscription But usualy the users that already own your app are still free to use it. (it's like "you helped me ramp up my app" = "you get it lifetime free").
Otherwise you should make it clear in the release notes and maybe add a single screen for the first startup to make it more obviouse. But the user can't know it up front if for example auto updates are activated.
I have an app that is free but contains a in app purchase item that cost 2 dollar.
Is it possible to make this in app purchase item free for 1 day? If I make it free will the user purchasing the item just get up 0 dollar when he tries to purchase it?
Update
Unfortunately I misunderstood what was asked by Nissefar. Sorry, Nissefar.
Below is a completely unrelated text (the original). I'll probably delete it eventually.
I'm only writing this as an answer because I don't have enough reputation to comment.
You could use consumables. Make the user buy time to use the item. This requires a backend server for your app, responsible to manage the bought time.
If you really want to disable the purchasing for one day, you can do it as well. When the user buys it, the server is notified, manages what has to manage, and tells all devices the item was bought. All devices disable the possibility to buy the item. Whenever the app starts you ask the server if the item is available or should be set to be bought.
Study a little about In-App Purchases, and you'll know what's the best solution to your undetailed problem. Also, if you don't know how your server can notify all devices, study about push notification.
I know this answer isn't very complex, but your question is very simple. You should have explained better what you want, as well as to all solutions you though and their pros and cons. What have you tried to do already?
I'm not expecting you to aprove this answer, only to improve you question. Detail it a little better, and explain what you've tried and the solutions you've considered.
I'm trying to implement the in app purchase mechanism for my app and have a hard time to figure out the right way.
My app provides a service which can be used for as many items the users wants. He can add more over the time as he wish. The service is a yearly service.
From what i understood in the documentations it should be a non-renewing subscription.
The issue is that let's say a user bought the service for item A.
After a week a wants to add a second item to the service,item B. Then when he buys it ios pops up a window and says he already bought it and asks if he wants to renew.
This window isn't correct ! he hadn't bought the service for item B but for item A. This would confuse my users very much and i really need to avoid this.
I've looked and found also no solution to switch subscriptions, for example between a product called "Manage 1 item" to product called "Manage 2 items" which could have been a solution.
Another solution would be to create multiple in app products with the exact name and description and manage which one to buy from within the app. Would that be ok with apple ?
How should i handle in app purchase for my application needs ?
Thank you,
Tom
First of all, have you read iOS In App guide? This should be first stop for you. Secondly, you cannot have two In App products with the same id, so I don't get why adding second product would prompt user about already purchased product? Could you clarify that? In general, if I buy your product, you should keep data about my purchase and i.e. block this feature, so I it will be enabled once again only when I cancel subscription/my subscription expired.
Not sure about non-renewing, but it seems quite fit for situation, I guess. You can always consider buying consumable and store somewhere information how long you enable some features. Plus, when user buys a subscription he/she cannot get money back (except few scenarios, like mistake), so once you decide you don't need it, you cancel it. This way you can detect in receipt if product expired or not, but user cannot just swap in middle time from one product to another.
Right first of all I have tried all kinds of tutorial but they only show how to get the purchase information and display it as a tableview then get the purchase to work, plus this is only for non-consumable or one consumable. As per the image above, I have created this in the XiB and would like to just initiate the consumable purchase when the user taps the button. I would not like to get the purchase info from iTunes Connect then display it as I am already displaying it offline.
I have created the App ID and the App in iTunes Connect and have created 5 in-app purchases. (as per the image below.) I would like the buttons to call for each of these. Does anyone have any suggestions?
I have no experiense in working with consumable purchases, but I don't think there is a large difference. I hope, you've already read Apple In-App Purchasing Programming Guide: http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008267-CH1-SW1
So, what is your problem? If you need to show multiple products in one viewController, you need to take somewhere a list with productIdentifiers (strings, unique for each product in you app at iTunes) for each product. You can hardcode these productIdentifiers, or, better, if you are using server, request them (because, if you hardcode your productIdentifiers, and then add/remove/edit product and it's productIdentifier changes, you'll need to publish a new patch for your app).
To show actual information about each product (price, name), you need to request it. You do it by creating SKProductRequest (for each product) and adding it to your paymentQueue. You'll get price in response. If you don't - don't even show that product in your viewController, because it's something wrong with that product.
To show the products offline you can implement some cache. May be it looks nice, but does it make sense to show "Buy" button if you are offline?
Probably there will be some kind of cell for each product in your viewController. In that case, that should be not a problem to determine, which productIdentifier to use, when user taps on some of the cells.
What to do after that? IMHO it's nicely described in Apple's guide.
If you need more help or some more specific questions - please, comment my post, or edit your question.
P.S. Be aware: in iOS 7 there are some number of changes in working with in-app purchases. Anyway, you can find all information at http://developer.apple.com/library/ .
P.P.S. Check this post: https://meta.stackexchange.com/questions/182266/how-much-research-effort-is-expected-of-stack-overflow-users/182380 . I hope you know, what I mean :) You can try to find some help at #iphonedev # irc.freenode.net , for example. And search and search again. Good luck.
You need to get product information via SKProductsRequest, because you need and SKPayment instance to make a purchase, and SKPayment can be created only with existing SKProduct, not just productIdentifier string.
You can use local cache to show prices to the user even when he is offline, but Apple forces you to get product info every time user tries to purchase something.
Taking product info is not a problem, anyway.
How to store a set/array of productIdentifiers? Read my previous answer.
I can't seem to find an answer to this question anywhere, so here goes...
I've developing an iOS app that will have non-consumable in-app purchases (expansion packs). Say I sell a pack that has 10 levels in it, for example, and in a month I want to update that in-app purchase to have 15 levels. The user will NOT have to re-purchase the pack; they would just need to update it.
Three questions:
Is this even possible?
How are users notified of this (or how SHOULD they be notified of this change?)
Does Apple need to review changes like this?
Thanks in advance,
Rick
Clearly yes. It is up to you, to write the code in a way, that your app remembers which updates a user has bought and how these updates are interpreted in your app. The only thing that will stop you from changing an in-app purchase content is when you take functionality or in your case levels, away again. Apple won't allow you to upload a new paid version with less functionality.
I would probably tell the user in the info text you have on the app-store, that they will receive 5 additional levels if they already have the 10 level upgrade.
Apple reviews every change you make to the app when you upload a new version to the app-store. This is true for any feature as it is for updates to in app purchase.
I did something similar to this in my app recently. I was saving a BOOL value in NSUserDefaults that specified if the user had purchased the expansion pack. In my update I simply had the change the code that was given to the user based on whether or not that BOOL value was YES or NO. As long as you designed it correctly you shouldn't have any troubles updating
Yes it's possible. Provided you keep a track of who has bought what pack (ie. keep a bool value as an NSUserDefault), then they will still have access to it (even if you add more stuff/levels to it).
It depends what you mean by notified; they will know if they read the update comments when they install the update. Also you could just choose to alert them when the load the app after the update - your call.
If you're submitting the code Apple will review it. Just think of it like any other update to an app.
Hope this helps!