I am in a tricky spot and I am trying to figure out the best way to proceed. I released an app a few months ago and have charged a few hundred people $.99 for it. I am now interested in making the app free with in-app purchases. How can I make it so that whoever has already paid for it, doesn't need to pay again? Can I programmatically "white list" them? And then just charge future users?
I have integrated with Game Center so I was toying around with the idea of checking for users on the leader boards already?
I can't make a separate app, I just was wondering if there was any API or route I could use to achieve this.
Thanks!
Here's a potential strategy:
1) Make your in-app purchase essentially a toggle that enables access to some features or resources in your app.
2) Change the name or location of some key file. The database would be easiest (if you have one), but also look for user defaults or other saved files.
3) On launch of your new version, check to see if that older thing exists - if so, save a marker key into the keychain for the app (and if you renamed the database move the old version to the new name/location!). The keychain is a nice place to put this as it persists between app installs. I'm not sure if iCloud backs it up though.
4) Now when checking for a feature look for that marker key in the keychain in addition to asking Storekit if they have purchased the items you want unlocked for them.
5) In the UI block purchase and indicate they have already paid.
That's about the best you can do, they may have deleted the app altogether and in that case there's nothing you can do to help them... you may want to also make some kind of one-time use code that could unlock the feature in the same way (except that the code would be verified by your app against your server so that it could only be used when you allowed it), that way that you could help out individuals contacting you saying they had purchased the app before. There's no way to verify that but it's just good customer service to let them have the upgrade anyway.
Related
I'm thinking about building a series of iOS apps.
Each app will be purchased individually but I'd like in-app purchases within any of the apps to be universal. ie, pay for it in one app of the series, it's available in any other apps installed to use too.
Is this possible without forcing the user to create an account of any sort?
Many thanks
Answer is NO, Reason is all your IAP are identified by the bundle identifier and that is unique for each application, as all the IAP's are specific to the bundle identifier you can not share those.
There is another way of achieving what you asking for, I don't know all your requirements still I would NOT follow this solution, still I am writing to know some options.
You can sharing the keychain across the applications and keep track of purchases across apps.
Keychain data is not deleted on deletion of the app
If user resets/restore phone keychain data can get deleted and you will be at dead end, as user has to restore the content from your 1st application to use in 2nd application... (yeah confusing.. right ?)
There may be some other complications I am missing right now.. good luck
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 am trying to submit my first iPhone app that has in-app purchasing features. Needless to say, I have been banging my head against the wall for a while. I have read through several tutorials, such as: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ and http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/ but it seems these are outdated? For instance, I can't find where the developer is to reject the submission on iTunes connect.
Additionally, I am submitting the app the in-app purchase features included in the bundle(I don't have them stored on the server- I just want to unlock the code when the user purchases the feature). What is the best way to do this?
Thanks!
Some of the information in the linked tutorials is in fact outdated: I could create in app items in iTunes connect without having to submit (and reject) a binary first. Just be sure NOT to submit your items for review while you are testing. Also changes to the items (e.g. price tier) have been processed almost immediately and I did not had to wait 24 hours.
To unlock your feature, you may use storing and retrieving the purchased status in NSUserDefaults . But this could easily be tempered with by users with jailbreak or acces to the apps folder. Have a look at http://maniacdev.com/2011/08/open-source-ios-keychain-wrapper-for-easily-securing-user-data-for-your-app/ . This offers a simple way to store data in the keychain. Still this will not prevent someone to 'hack' your app and enable the purchased feature without actual purchase, but it's not that easy...
In-App Purchase development is definitely a pain point in iOS development - their sandboxing model for this is ridiculous.
Needless to say - the articles you're reading are still up to date. The developer reject is definitely the way to go (I think can do from within the binary details). One thing to remember is that you need to have accepted the appropriate contracts and tax schedules also - if you haven't then the store "just doesn't work".
One thing that caught me: when you submit your final version of the app - make sure you tick the in-app purchases to be included; else the in-app purchases won't be reviewed (and accepted)!
Update: Although it's pretty long... you may want to flick through this: https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf
Explains how to developer reject etc.
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.
We have an app on the app store that we need to remove. As such we have a new version to upload as a completely new app with a new app SKU and Id but we want to offer a free upgrade for those who have purchased the original version.
Is there a way to do this?
But if you're willing to give new App for free for everybody who's got an old one why do you create a new application and not just update old one? You can change anything you want about app except SKU# as I understand. Do you have anything tied to old SKU# or you have other reasons to create a new app?
I agree with the other posters. Apple does not have a mechanism to do this.
What you can do:
-make a black and white or very washed out icon for the old app
- change the app description to say that this is an old version / no longer supported / deprecated and to search for the new version.
- Make sure the new app title show something like NEW, 2.0 or some signifier to draw attention
I have not heard or seen anything about it. Only thing that comes to my mind is to give a promotion code. This of course opens up some other questions:
How to communicate that to your customers?
How to secure that it is not explored by users who have not bought the first app?
Don't have any good answers to that (time limited offer?) but maybe it could lead you to some new ideas.
Good luck!
Unfortunately there's no real way to do this. Apple intentionally keeps information about the users of your old app private.
Well, there's one way I can think of, but it requires some forethought (and I'm not certain it would be ok by Apple) and it would cost you a bit: When your old app runs it contacts a server of yours with the device's UDID, which you save on the server. Then you show an alert in the old app that tells existing users to contact you via email with their UDID (you could make it easy on the user by putting together the email in-app with the UDID in the subject or body). You then send a gift of the new app (via iTunes) to every user that emailed you that way.
You'd take a 30% hit (Apple's cut) but the rest of the gift price would end up back in your bank account. People who pirated the app would get the offer, too, and there's no way you could tell a pirating user from a valid user. But it would more-or-less work.