I have a free App that I am about to update. After the update it will not be free anymore.
People who got my App while it was free - will they have to pay in order to get the new paid version?
Thanks.
No, only initial app installation can be paid - all updates are free. The possible option to introduce paying in your app is to use in-app purchase functionality.
As long as it's the same app (not published as a separate one) then I believe it will still be free. iTunes will still consider those people to own the app, so changing the price wouldn't affect them.
Related
I developed an app that charges user €3 for the download. But the sale number is way too low.
Currently I hope to change the sale model to a free-trial with in-app-purchase one. The problem is how to compensate the users who already purchased it? I prefer to upgrade all the paid users with all the in-app-purchases automatically.
Does anyone has such experience to share? Thanks!
It really depends of your mobile service structure but assuming you do not have a backend with user information stored it gets a bit more complicated.
One solution would be , in the release with In App Purchases to check if the user upgrades or if it is a fresh install. A reasonable solution can be found here https://stackoverflow.com/a/22174089/3979236
If is a fresh install simply unlock the feature that would have been unlocked by the in app purchase (you cannot offer an In App purchase).
Nicolas
My company currently has two applications in the app store: a full, paid version that includes two ebooks, and a "lite" version that does not include both books. We've just developed a new version of the app that instead implements the two books as IAPs, with the intention of merging the two apps into one. I'm at the point where I'd like to submit the app, and I'm not sure of the best way to proceed.
Current plan:
Update free app to the new version with the IAP books.
Rename the free version, removing the "Lite".
Delete the existing paid version from the app store.
Potential problems with this plan:
Those who've already paid for the existing full version might feel ripped off, since their version won't be receiving any of the other updates in this new version.
There will be a name conflict, since we want the new app to take the name of the old paid one (removing the typical "- Lite" signifier). This won't be much of an issue in the App Store if we immediately remove the paid version from the store, but can make for a confusing user experience if a user downloads the new version alongside the old paid version.
Along the same lines, if we delete the old paid version as soon as we upload the new free version (with the same name as the old paid version), it's easy to imagine some confused users of the old paid version deleting their existing paid version and downloading the new free version, only to realize they'd lost the books they'd already paid for, with no way of re-downloading the old paid version.
My questions:
From a real high level, are we handling this the wrong way? I've Googled and Googled, but I haven't been able to find much guidance on how to combine paid and free version of apps into one.
Is there any way for me to determine who's already purchased the paid version, and "gift" them the book IAPs in the new free version? If we thought this threw sooner we could've logged the unique IDs of all of those paid versions, but I do believe that's against the rules now anyway, correct?
What other sorts of issues might arise by giving the "- Lite" version the same name as the old full version?
Thanks in advance for any and all assistance or feedback.
We just did that with our FileApp Pro and the free FileApp. We got rid of FileApp Pro and now the new FileApp has In-App Purchases. However we wanted to have all users that bought FileApp Pro to have all In-App purchases of FileApp for free.
Here is the method we used:
We are sharing flags between FileApp and FileApp Pro using the iOS’ “Keychain sharing entitlement” which allows two apps to share the same keychain data. This allows FileApp to know that FileApp Pro is installed. Then we wanted to make sure that FileApp Pro privileges remain available in FileApp through the iTunes account of the user so we used a free In-App purchase to do that. The FileApp Pro user when launching FileApp for the first time is asked to purchase a free In-App purchase so all his privileges remains across devices even if he reinstall FileApp.
You will find a complete article on our bog describing the method:
http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
Edit: Here's the archive link to the above post that doesn't seem to be available now: https://web.archive.org/web/20160309135133/http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
I would think it might be best to turn the paid version to the free so at least your original paid customers are taken care of the most. Depending on your user base you could even ensure the original paid users aren't shown any ads or other restrictions by doing an intermediate release to have those users save something to user defaults. Then you could provide an update to the free version with a UIAlertView that asks them if they want the full version for free and direct them to the app store to download it. I assume you have many more free users but you would probably upset less people with this path.
I know two apps that did something very similar. The Economist, and USAToday app, which literally alerted the user to ditch the current app and download the new one. (Not sure why they had to do it that way though). So I am quite sure you are not the first one thinking of doing this.
If there is an option for you to provide account+sync capabilities, that'd be the best way to merge both the apps. One of my favorite apps, Gas Cubby, handled this pretty well. Gas Cubby has a free and a paid version. If you want to upgrade your from free Gas Cubby to paid one, you download a different app, and then sync data.
For your worries about how to restore content for the paid customers in your Lite app, you can use a URL scheme in the Lite app, which, when called by the current paid app, will enable those books for free.
As #rooster117 says, its best to turn the paid version free, and ask the lite version people to move to the paid-turned-free version. Of course put hard stop date in the app that you'll discontinue, so that all those who use it will move to the one app of your interest.
Your Problems:
This is going to happen regardless, you can't make everyone happy
I would go with removing the Free version of the App although, but before you do send a push notification to all the "Lite" version holds saying support for this app will be discontinued and direct them to the paid version
To continue on from #2 if possible, before discontinuing the "Lite" version if you have an account system setup to a server of yours release an update for both versions that syncs all of their books with your own server (not iCloud). This way when they download the new version (after the Lite is discontinued), the app will automatically sync the books back to the device.
Your questions:
As you relise there is no real way to merge two apps, from what I've seen from games to utilities is to remove the "lite" version as some point all together and if the user wants future content updates then they have to download the app still on the App store.
Refer to my Answer to Problem #3
I believe it will be out right rejected by the App Store review process, primarily due to the fact that they both perform the same function, i would suggest to remove the free one altogether
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I have a few specific questions concerning paid applications in the App Store, along with promo codes and updates. I've done my research, but I either haven't found answers, or have found very outdated "I think this is how it works..." answers.
I issue a promo code for version 1.0.0 of a $0.99 app, so the customer gets it for free. When that customer updates to version 1.0.1, will he have to pay? (Does it matter if he updates before the 4-week expiration date of the promo code?)
I release an app that's "free for a limited time," at version 1.0.0. For version 1.0.1, I change the price to $0.99. New customers obviously pay the $0.99, but what about the customers who purchased within the "limited time" window? Do they have to pay when upgrading?
I've heard rumors that the answer to the above question is "Yes, existing customers have to pay when upgrading" only if it is a major version change. Eg. The customer got 1.2.0 for free, and will get the 1.3.0 update for free and 1.4.0 update for free, but will have to pay for the 2.0.0 update.
Thanks!
No, the user doesn't have to pay for an update. Redeeming a promo code is exactly like buying the app.
"Limited time" price offers on the App Store are just marketing words, they have no technical effect. No one ever has to pay when updating to a later version of the same app.
No, users never, ever have to pay for an update of an existing app. A few companies have decided that when they come out with a major upgrade they abandon the previous app and literally come out with a new app. This means that the customers who paid for the previous app have no upgrade path and would have to buy the new app for the full price. Without noting whether or not I think this is a good or fair decision on the part of the developer, a lot of existing users end up pretty unhappy with the discontinuation of updates to the old app.
To sum up the key point: updates to apps are always, always free, no matter what version you bought or how you paid for it (including redeeming a promo code).
As a matter of opinion, this fact is unfortunate. If developers could charge for updates then users would be able to choose whether or not to accept the update. If they did pay for the update, the data from the old version would continue to work just fine in the new version. A major problem with the scenario I outlined in #3, where the developer abandons the old app and the "update" is really an all new app submitted to the store is that data on the device is associated with the unique app identifier it was created with, making it difficult or impossible to transfer to the new version (depending on how the developer handles it).
The ability to offer time- or use-limited free trials and to charge for updates would allow for pricing plans that would usually be much better for consumers while making it better for developers, too.
Although updates are free, and there does not appear to be a vehicle in iTunes Connect to have a developer charge for them, you can do it on a subscription basis. So, you could sell an annual subscription. Another possibility is to add some code in your app to store the app version number in NSUserDefaults, then you can check to see if the current version matches the last version launched - and if so, then do an In-App Purchase. Frankly, I don't think it's fair to have forever-free updates. Maybe that should be left up to the developer to decide - they could allow 3 free updates, then have to pay every 3rd, etc. But allowing us to come up with a policy means we can not only create a renewing revenue stream, but it translates the value the customer gets into support for ongoing development.
For now, I'd say you have to program in some In-App Purchase scheme.
My app has been free since the beginning, I uploaded a new version and set it to Teir 1 pricing.
People who updated got it for free for some reason, only new downloads by new users were charged.
Did I miss something in my main bundle to ensure that upgrades are not free?
It seems you cannot charge users for updates, so if they have downloaded your app once for free they will be able to update it also.
I think the only option to introduce payments in free apps is to include in-app purchase in them.