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.
Related
TL;DR: Is there a way to verify that a user has purchased another app (of mine) from the Mac App Store?
In a brief, I want to completely rebrand one of my applications on the Mac App Store. The current version is very buggy and has a user base of nearly 90% pirates. I want to shut down the old application and completely rebrand it as a new product.
However, I don't want to completely screw over my current, legitimate customer base. I am hoping there is a solution to this. The way I was hoping to go about this was to:
Create a new application – completely rebranded
Make it free
Have an In-App Purchase that unlocks the Pro version
Allow customers of my previous app to "restore their purchase" to unlock the Pro version
The new app will have extensive anti-piracy measures. Furthermore, the current application requires a connection to one of my servers. When I release the rebranded app, I will shut down the current app.
I realize the forcing users to migrate may cause some backlash; however, I am hoping that, by providing the new and improved version 100% free, the backlash will pass.
Look for the old app using NSBundle bundleWithIdentifier
get the receipt of this bundle using appStoreReceiptURL
validate the receipt
unlock functionality
Bare in mind that the terms and conditions of Apple say something along the line of "only appstore IAP should be used to unlock features; don't roll your own license mechanism"
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
The scenario is:
I created a free iOS app that had in-app purchases for premium content
I now want to convert the app into a paid only version of it and remove all IAP stuff
My questions are:
Will the AppStore let all current customers download the app again without double-charging them? (i.e. forcing them to pay for an app that used to be free)
As long as I keep the bundle identifier (i.e. com.yourcompanyname.appname) the same, it will just overwrite the old app like a normal upgrade, correct?
You're correct: if it's the same app -- same bundle id, submitted as an update -- then existing customers will be able to download it for free forever, like any upgrade.
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.
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.