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.
Related
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 paid app at the App Store. I want to convert this app to a free app that offers some content with in-app purchase that the paid app used to contain. How do I ensure that the price change happens at the same time as the version change (that includes the in-app functionality)?
I know that I can specify both the date for version release and the date for price change but if they don't happen at the same time, I'll end up with customers that either:
1) Get the new version and have to pay for it and then pay even more when unlocking features with in-app purchase
or
2) Get the old version for free and don't have to pay for anything since the old version doesn't have in-app purchase for the features. Then people who don't get all for free will be sad and say "how come he got all for free and I have to pay for the same features?"
You will probably just have to monitor the approval process. Take notice when the app goes into review and set the app to be free a day or two after. Otherwise, you are basically taking a shot in the dark unfortunately.
There are several things I wish that Apple would do differently with App Submission, this is now also added to my list.
Actually there is a better way. Set you update to 'developer release'. Then when it's passed review, release it. It will change status to 'Processing for App Store'. Go in to the Rights and Pricing menu and set the availability date to some time in the future, so you're app is no longer available. Then, when the update changes state to 'Ready for Sale' go back in to Rights and Pricing, set the price tier to Free and make it available any time in the past. That way there's no risk of anyone getting screwed over.
If you download the iTunes Connect app, you'll also get a message when the update changes status from 'Processing for App Store' to 'Ready for Sale'. Easy :)
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.
I have an app that I was going to release as a free (lite) version with some of the total functionality and a paid full version with advanced functionality. Now, with in app purchase for free apps I am thinking of going that route with the ability to unlock features as needed. I'm not talking about a trial version that expires.I want people to be able to try out the app and get an idea of the interface and functionality before deciding to purchase the full functionality of each major section of the app, basically.
Here's an analogy of what my app would be like. Let's say you have a cooking app that teaches you to cook in different styles. There could be major section for French, Italian, and Chinese. Each section could have some rudiments unlocked in the free app so users can see the UI and basics of the functionality. Then, the user could decide to purchase each major section (or not) individually with in app purchase or buy the full versioned app (with the free/paid model).
One concern I have with offering a free app with in app purchase would be with feedback. I would be very clear in my description in the app store that there is in app purchase for full features but I'm worried that less serious users could/would leave negative feedback. I suppose that's always a risk but curious about any experience with this.
It also seems that it could be a whole lot more complicated keeping track of what portions of the app are locked and unlocked with in app purchase. I know I'd have to have all the code for the full functionality and "lock" the portions that haven't been purchased. How do people usually lock portions of their code? I'm not talking about the process of purchasing (I've read the In App Purchase Programming Guide) but after the purchase has been made. Would I just keep track of what the user has purchased and put conditionals on the sections that are initially locked? Or is there another way to do this as well?
My instinct is for the in app purchase (particularly since users could purchase the major sections that they want individually).
I would highly recommend using the in-app purchasing over having different versions available.
If you have different versions, users need to re-download the whole thing if they want to upgrade. This means they need to have twice the storage space and use up twice the network bandwidth to upgrade.
I don't think your review concerns are founded. If your application is well made and users like it, you'll get positive reviews. To avoid having users be confused, make sure the application clearly states what can be purchased. Also, some people just dislike everything and will give you one star. These users are unavoidable, but if your app is good, there should be enough good reviews to balance them out.
You're correct in your assumption that you would have to have conditionals for locked/unlocked content. However, this shouldn't be an enormous issue. Just persist what the user's purchased in a plist (suggested by Apple) or other persistent storage and make a class that you can query to find out if a particular feature has been purchased.
I suppose it makes sense to have lite app (with unlockable content via IAP) and full paid app. I'm saying this basing on own experience of selling apps on the AppStore. If interested you may want to look at my post in our company blog about IAP vs paid app.
http://bees4honey.com/blog/marketing/in-app-purchase-vs-paid-app/
In two words - having lite version with IAP and paid version will increase a total revenue in comparison with having only lite with IAP or lite+paid.