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/
Related
I have to restrict a Free app from being downloaded or installed for a 2nd time on an iOS device, as I would like to user to purchase the paid version of the same. A first time user of the free App can download the Free App and install it on their iOS device, but after using the Free App for certain number of times, the Free App will work with limited functionality as I would like to promote my paid version, so I prompt the user to buy my Paid version of the App. At this time the user can delete my Free App and Re-Install the same from either the iTunes store or the iTunes on their computer or iCloud backup.
Question is how can I restrict the user from re-installing the same Free App on their iOS device a 2nd time ?
Is there any way to tell the iOS on the user's device to stop the 2nd time install of the same Free app ?
Or is there any other way to achieve the same results ?
Thank you.
You're unlikely to reliably get past Apple's review process with these restrictions.
Free/lite apps are supposed to be fully usable apps in their own right. So, using a todo app as an example:
You could limit it to ten TODO items
But you'd get into trouble if it stopped working after ten days
Clearly you can also limit in terms of what functionality you offer. My apps, for example, only allow editing in the paid version; the free one is read-only.
I'm not sure that you can reliably do what you want. (What about if I have to wipe my phone and restore from a backup? Does that count as reinstallation?) But even if you could, it wouldn't necessarily be a good idea.
i think the recommended way is to use in-app purchase. You can enable a full Version to the user when he buys it. So there is no reinstall needed.
I'm not sure why you have the requirements you do, but this does not fit the model of the App Store. You are likely to have your application rejected, even if you were to find a way to do this.
If you (or your stakeholder) are insistent in this approach, maybe the App Store is not for you.
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
So I already have 2 versions out on appstore..
One app is a free but limited version.
The other is a paid unlimited. The basic layout..
I have had questions from companies wanting to buy the app and give to their employees. So they don't have to buy the app with their personal accounts..
So I was thinking of releasing a 3rd version that prompts the user for a license key on first start, if the key is valid the app starts and works until reinstalled or w/e. If the key is invalid the app just keeps prompting for a valid license.
Now I remembered reading somewhere that apple wouldn't allow apps that had no public function or something like that. Which this app wont have unless u have a valid license..
But since I do also provide a valid public version of the app, will this one get accepted? Or have they removed theese rules?
Any insight in the matter would be helpful!
Edit:
Forgot to mention that the reason im looking to use the license is because i have the same app for android and want the companies to be able to buy for both device types, not just apple devices.
Thanks
I believe you should use the B2B functionality in ITunes Connect: http://developer.apple.com/support/ios/volume-purchase-program.html
Also check: https://developer.apple.com/appstore/resources/volume/
I did something very similar to this some time ago, they seemed ok with it (then at least), they just asked for a license key in the complementary info (during the app submission) to go through all their usual validation tests.
Klassmating has an app in the app store that has no public functionality unless you are a student at a specific university. So it seems like you can have apps like that.
Without knowing exactly, I would assume Apple would reject such an app from the store (mainly because it would allow you to sell applications "behind their back" - i.e. sell licence keys and not using in-app purchase) :-)
However, there are two possible solutions to your problem that come to my mind:
Create and distribute gift codes (would be a problem if you had to give out too many of them).
Do an ad-hoc distribution of your app to the companies. Basically they would need your application bundle and an ad-hoc mobile provision file. Then they can simply install your application by dragging it to iTunes.
There are different official iPhone application distribution methods.
In which for your current requirement,I suppose you can use the Custom B2B Apps,where you can deliver apps directly to your business customers who have a Volume Purchase Program account.You can get more information from the link provided above.
cheers!
Yes, I too have had an app in the app store which works like this. You have to provide them with a key/licence to access the app functionality so they can test it fully.
I've had an app rejected for this very reason - required a username and password, not a licence key, but was free. They said in contravened the licence terms regarding in app purchases.
Mine allowed time limited free trials from within the app, but full functionality was restricted to purchases outside the app. Apple wanted their 30% cut of the subscription cost so it was no dice for us.
On the other hand, the app store review process is seemingly entirely random, so who knows.
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 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.