I have an App currently in the App store that I've been adding functionality to. I've never worked with In-App purchases, but from what I have been reading, it looks like the "improvements" offered are code adjustments to add, or unlock features.
For my "improved" version, I actually added an entirely new (additional) VC plus a Master VC to switch between the two (using the storyboard), so it's not just a matter of unlocking code to provide the additional features. Can I still use the In-App purchase to provide access to this version, or would I have to submit it as an entirely new product?
If you are trying to add some kind of "premium" feature that only people who pay X amount will have access to, but are still maintaining a "basic" version of the app for everyone else, then yes, you can create an In App Purchase to do this. Or, if you wanted to, you could create a separate "premium" version of your app. It's really up to you. I wouldn't necessarily say one way is preferred over the other, because I've seen it done both ways.
Even if you wanted to charge for the new features, they are not present in the currently released version of your app, so no matter how you decide to market this, you will have to submit a new version of your app. It can contain an in-app purchase or not, but it will be a new version. It certainly does not have to be a different app; adding functionality, possibly including an in-app purchase, is what a new version is for.
In short: you don't need to add a totally new app in any case unless and until you want one more app to be on app store
Detailed answer: If you are just making changes in the underlying architecture of your app it doesn't make any sense to give it to user as in app purchase( and i guess apple will also reject your in-app products). You should only add in-app purchase if you are adding a new feature or giving the user some bonus stuff.
And as per me you should add new version of the app only if you feel that this is a new app.( for example Badlands and Badlands 2 are similar apps but internally they are different from each other so they uploaded them as badlands 2)
Related
I have an IOS app which is free and it has in app purchase options. But I would like to change it a paid app and cancel all in app purchase options. What will happen to existing downloads?
EDIT: Will they need to pay if they update it?
Absolutely nothing will happen to the existing customers. This will only affect customers going forward. However, should they upgrade, they will also be part of the new customer base that includes the paid and in-app options.
Nothing.
When you change your terms it doesn't affect existing customers.
(that notwithstanding, they won't be able to purchase more of your (potentially important to them) in-app purchase).
Best of luck.
I have an old app on app store that is divided into one free version for both iPhone and iPad and one paid version for both, so four different apps in total. I am going to make a complete new version of it so that it gets easier to handle. I want it, if possible, to be one universal app that maybe can use in-app purchase for customers to get the "premium" content.
However, people have paid for the previous version, is it possible to somehow let them have access to the premium content in the new one?
Or do you think that it is better to make a complete new app with another name? :P
Any suggestions?
They can still use the old one if I remove it from app store right?
This is something that you would need to discuss with Apple, for the most part, they do not like it when potential sales could be lost. After that is all said and done, there are ways for apps to share data with one another.
Have a look at this tutorial, it should give you an idea on how to do it.
http://www.enharmonichq.com/sharing-data-locally-between-ios-apps/
In iOS, is there a way to figure out the version of app the user originally bought from?
For example, what if i want to implement some special behavior only for user who purchased v1.0. one obvious "feature" is disable in-app purchase so they can enjoy the rest without paying? I thought up some ways to do it but unfortunately, it wont survive the test if the user deleted the app and also i didnt user icloud early enough to persist this metadata.
Unfortunately this can't be done. At least not in any perfect manner. There is no API to get any details about the user and their purchase. If your 1.0 version of the app doesn't already persist some meaningful clue, your only solutions would be partial at best.
Your issue is made worse if you already have newer versions of the app out (such as 1.1) and you want to add this new feature to a newer version (1.2 or 2.0). There is no way to know if anyone ever had 1.0.
You basically have two options:
Leave it alone. You can't convert a paid app to a free-with-IAP app without hurting at least some portion of your existing customers. If anything, leave the app paid but add IAP for any new functionality. This way, everyone pays the same for the base app and everyone has the option to pay more, through IAP, for additional features.
Depending on your ethics and the number of existing customers, you could just make the switch and make existing customers pay again for functionality they already paid for. Obviously, this is a bad idea but it is an option.
I have an app in the iTunes store that has full functionality. I attempted to release a Free version which contains half of the functionality, and contains a link to the full version if the user tries to use the other functions.
Apple rejected the app on the basis that rather than having two apps, I ought to have the main app released for free and have the extra functions unlockable using in-app purchasing.
That's fine; I can do this. The only problem is that since I released the full version initially, some people have already paid for and downloaded the full version. When I update this app so that it is free, it will be restricted by default. Those users that have paid for the full version will have lost the functionality they've paid for.
I don't really want to release a second version of the app since I intend on continuing to update the app and managing two release streams would be unwieldy.
Is it possible to somehow offer for free the in-app purchase to those users that have already bought the full version of my app when I update the app to the new (free, in-app supported) version?
Edit: An (unpreferred) alternative would be a way of refunding the purchases to the original buyers, along with a note explaining why. Any ideas how?
What I'd do is add a already paid option within the application itself, and then allow users to enter a license code, or email address depending what you prefer, Which you can automatically issue from their contact details if you have them or ask them to contact you if you don't, which most will as they have paid.
Now as far as the licensing and the verification of these codes you could setup a cheap VPS which verify s the code and only activates with codes that you have entered on the server, meaning you won't fall victim of Keygeners.
Just my 2 cents.
If your app doesn't currently have a username/password registration, I would suggest releasing an update to the paid app that explains to your users on an initial popup view something like:
Thank you for supporting our app. Due to changes in Apple's policies, we will be converting this app into a free app with in-app upgrades. Since you already purchased the full app, you will be awarded all features! Please input an [email_address or username] so that we can provide a painless transition.
If your app has a user login mechanism already in place (username/password), then just store those details and have the user log in later in the "free" app to unlock all of the features.
Obviously, both of these suggestions require a backend for validation, but shouldn't be too difficult to create that.
This is tricky due to section 3.3.3 of the license agreement and Attachment 2. I'm not a lawyer so I'll save my interpretation but, read them.
Another option would be to make the free version a new, different app and leave the original one in the store but unavailable. Then you can still publish updates to it but new users won't see it. Apple would probably allow this considering you are still only presenting one app to new users. The downsides are (1) you have to maintain two versions and (2) you have to start over in terms of reviews etc.
We have two Apps live on the Appstore. One for free, and one full featured version which is offered to buy. The free app has a In-App-Store so the user may update to the full featured version.
Actually I am thinking about stoping development of the full featured App (which is identical
to the free one at code level). We don't want to blame our customers. It would be nice to give them a redemption code for the free app to unlock all features. All features which will be unlocked this way are bound to the redemption code. All customers who did In-App purchases are "registered" by Apple, so the purchase will be remembered for all devices. Finally all In-App customers would have an advantage over the Pro-Version customers, which is not acceptable for us.
Is it possible to have one (hidden) free In-App purchase, which the user could "buy" if the redemption code is working? Maybe a better question is: What is the best practice for putting two similar Apps together without bugging the customers?
Not possible, I'm afraid. There is no good solution as far as I am aware (I still have a paid and a "lite" version for this reason).
You could raise a bug report with Apple (http://bugreporter.apple.com) but there's no saying if of when they'll ever make a change.
How about this idea:
Add a URL scheme to your lite app which, when invoked, enables the full featured version.
In your next update for the paid app add a button to "Enable all features in the lite version" that invokes that URL scheme (UIApplication's openURL:). This will open the lite app which will then enable all features.
One problem: if somebody else figures out what that URL scheme is, he could write a simple little app that just uses that URL scheme to enable the features in your lite app. Which means that person could get all the features without ever buying your paid app.
To prevent this I would implement this URL scheme in such a way that it only works when called with a secret parameter, maybe the hash of the device's MAC address and a salt. (Not sure if this is the best way, but that would be my first idea)