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!
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.
For an app that is yet to be first-released, it is easy to figure out how to detect first-launch: look for absence of a "wasLaunched" Bool, or a version number, in the UserDefaults. And then set its value. This is asked-and-answered in several places on StackOverflow.
But... I am updating an already-existing app that did not save any UserDefaults info (of any kind) in its first version. Is there any way to detect, on launch of the new version, that a previous version has existed and run? I can't think of one, but that doesn't prove much.
This is important because the new version charges money for some features that used to be free. I would prefer that earlier users not be suddenly faced with loss of fuctionality.
This was also previously asked (Detecting the first launch of an app with previous versions) but all the answers missed the point of the app already existing.
Note that writing to UserDefaults is not foolproof either. If a user deletes the app before re-installing or upgrading, the UserDefaults will vanish. However, that's an edge case I would be OK with ignoring.
Based on your answer to the first few questions in the comments, the question you posted really should be rewritten to something like:
I currently have a free app. In the next update I wish to make some of the currently free functionality into paid functionality using in-app purchases. However, I don't wish for any existing users of the app to have to pay for the functionality they have been using already. Only new users of the app starting with this update should have to pay for the in-app purchase. How can implement my updated app so that downloaders of the previous version of the app do not have to pay?
Given this, your question has nothing to do with any sort of "first launch" detections. Your need is to see if the user "purchased" (or downloaded) the previous version of your app.
This can be accomplished by performing receipt validation. Once you obtain and verify the receipt, you can inspect the receipt and obtain an original purchase date and original purchase version. If that version is a version prior to adding the paid in-app purchase, treat the user as if they have made the in-app purchase already and show them the paid functionality of your app. Otherwise, check the receipt to see if it includes data on the in-app purchase and give user access as appropriate.
Currently my is a paid app, now I am planning to make it free with limited functionality, after in-app purchase user can have full functionality. I want to know the people who have purchased previously can directly restore purchase so they don't have to buy again.
Apple doesn't allow to make this automatically. You must do this in your code. For example check your apps version, like version < x.y.z means that it was paid before, version >= x.y.z means this is a new user which should make the in-app-payment to unlock the full version.
No. There is no way to get such things from Apple. But, you can do one things.
If you're having login feature then you can manage same things from date. So, for old registered need to show all features while new users need to show specific features only.
Is there a way to verify with the apple servers when a user first installed an app?
Let's say you have a payed app and want to make it free with ads but not send ads to those who previously bought.
Since it's not an IAP i assume Store Kit is out of the question.
Later edit: My problem being the ones that buy, delete and reinstall.
Nope, you can't do that! The best way is to remove your current app from the App Store and relaunch using a different Bundle ID. People who bought it previously can keep it how it is, although they won't get any updates.
A possible workaround
Here's a workaround I just thought of. When you send out your next update, set a flag in NSUserDefaults to mark everyone who has it now as paid user. That would be for your next update only; you would remove that code right after the update. Then, when you send out your version with ads, check that flag to determine if you should display them. The only problem is that if a paid user ever re-installed the app, they would see ads from then on.
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.