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.
Related
I want to offer a free trial and the option to BUY (Non-Consumable In-App Purchase) on my ios app. I can see that I can offer a trial and then SUBSCRIBE (Auto-Renewable Subscription), but I personally don't like having to pay over and over for a simple app, but I do want to try it first. Is there a way to achieve the same thing when setting the option to buy? I realize I could track the first usage after download, but this presents a couple of issues:
Will Apple now approve apps for a trial period - previously they have been rejected, but that was before IAP and subscribe was available at all!
How do I prevent the user deleting the app (and any data I might store to know they have activated a trial) and then downloading again?
Or do I have to succumb to the pernicious "subscribe" model or release a "light" version with an upgrade? The last time I went "light", Apple insisted I make so much functionality available, I may well have not bothered with the full version - but that was a while ago.
Apple now allows you to add a free trial for Non-Subscription apps. It's a 0 price plan for fixed days. After this trial expires, you can show the non-subscription plan for purchase. The downside is user need to do a purchase again after trials end. But offering a free trial is a good user experience.
Non-subscription apps may offer a free time-based trial period before
presenting a full unlock option by setting up a Non-Consumable IAP
item at Price Tier 0 that follows the naming convention: "14-day
Trial." Prior to the start of the trial, your app must clearly
identify its duration, the content or services that will no longer be
accessible when the trial ends, and any downstream charges the user
would need to pay for full functionality.
Dont prevent the user from deleting the app. Just store the data online when user hits the trial button, you can store a flag in the web services which can be zero or one based on the user.
One way you could do this if you only care about iOS 11 is using the new DeviceCheck API. It's pretty limited in functionality (it lets you track 2 bits, or 4 cases, total) but should persist between install.
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.
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.
I have an my app on appstore and currently it's free. I want to make future releases not free but remain this app free for those users who downloaded it before, is there way to make this? Can I check when user downloaded specific app at first and if date is before certain date it remains free otherwise user requested to pay for using this app.
If a user downloads an app and it's free, it will remain free for them in subsequent future updates. Going free-to-paid is fine, for this reason. Generally, going paid-to-free tends to upset the people that paid for your app.
To change the price of your app, you can manage this in iTunes Connect.
If it was free users that already downloaded it own it at all effect.
Setting a price won't affect previous downloads, they'll be able to download future versions as updates without having to pay anything.
Once a user has purchased an app, all updates for that app are free. You can change the price to whatever you'd like, and all existing users will continue to have updates available to them.
It appears that no work is required for you to get the effect you want.
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!