22

I have existing users of a paid for app on the App Store. I'd like to transition the app to a free app with unlock-able features. Is there a way to roll my existing users into this new free version that allows a paid "upgrade" so the existing users are treated as if they've already paid for this upgrade? OR, as I expect, must we maintain two separate code bases as app development moves forward - in lieu of angering our existing customers by forcing them to purchase again?

I'm aware that initially there prolly won't be many authoritative answers to this question as Apple has only today started allowing support for In-App Purchases from within free apps...

Meltemi
  • 37,979
  • 50
  • 195
  • 293
  • Not currently, just like there's no regular upgrade. Would love to have an answer. – fearmint Oct 16 '09 at 01:15
  • @Meltemi: So, finally what have implemented for your above issue. I am also at same stage for one of my app. Please let us know. – pratik Feb 08 '10 at 06:13
  • Is it possible that we can access the purchase history for the app through code and based on the date stamp take a decision? – HariKJ Feb 29 '12 at 13:35
  • I have to say this is all a bit of a bummer. I had been hoping to give my beta testers free access to the IAP's for the production released app. Sounds like I'll have to give them iTunes gift certificates :(. – Chris Prince Feb 27 '14 at 21:47

5 Answers5

6

is there's some way you can tell if your app has been run before? (like settings you write on exit, data files created, date stamp of first run?)

if so, you could put code in your upgrade like:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
if (nil == [defaults objectForKey:@"app_v2_has_been_run"]) {
    if (nil == [defaults objectForKey:@"some_key_v1_makes"] {
         // they never had v1 of your app
    } else {
         // they had v1 of your app, so unlock some stuff for them
    }
    [defaults setObject:[NSDate date] forKey:@"app_v2_has_been_run"]; // or whatever
}
David Maymudes
  • 5,664
  • 31
  • 34
  • Sounds like a good option, surprised you've not had comments in favour or against. Have a +1 – Gordon Dove Feb 04 '14 at 23:28
  • 1
    Caveat here is that if the user reinstalls (for any reason) or adds a new device, they won't have this default. Storing this in iCloud might be able to get around it, but that's the best you can do. – Ben Lachman Aug 16 '14 at 15:14
5

One possible solution might be to place code in a new update of your paid application that would flip whatever switch you'd use to identify paid customers (be it in a property list or other form). If you give your existing paid customers enough time to upgrade, they should be marked as having paid. Then, make your paid version the free / paid upgrade version and remove your existing "Lite" version from the store. New customers will have to use the in-app purchase to unlock the full version, but existing customers will be acknowledged as having already paid.

A problem with this is how to get all of your existing customers to upgrade to the intermediate version that flips the "paid" switch in time to migrate the application to the free / paid upgrade model.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
  • 4
    I thought about this but realised that if someone deleted your app and reinstalled it they'd revert back to the "lite" version. Maybe this happens infrequently but I'd be annoyed if it happened to me. – Stephen Darlington Oct 16 '09 at 09:26
  • Yes, I think you'd probably want to have a server-side component to this, as well. That way, some sort of unique ID would be logged with a server for the previously paid customer, and the free application could also check this if the local copy hasn't been marked as paid. You wouldn't want to just use a device ID for the unique identifier, though, because you want the paid version to transition across to a new device that a user may upgrade to in the future. It's a tricky problem. – Brad Larson Oct 16 '09 at 16:08
2

You shouldn't need two separate code bases - use conditional compilation and build two targets.

Community
  • 1
  • 1
Cade Roux
  • 88,164
  • 40
  • 182
  • 265
  • 2
    I would add to this, and make it a marketing opportunity - use one code base with two outputs, but include some kind of bling or special feature for the people that bought the app outright that doesn't even get unlocked from the free version. That would make the people that already bought feel special instead of suddenly being the unwanted stepchild. – Kendall Helmstetter Gelner Oct 16 '09 at 05:28
2

For me, maintain two separate code bases won't be a good solution, because you will need to maintain 2 in app purchase (worse with in app purchase with a server), maybe 2 game center, and separate your download (and so less visible) because maybe some new user will directly buy the pay app.

But to change pay app to free app, I have no good way to do it, for the main reason if you upgrade your device, and so clean it, you won't have something to don't get free app to the first users to pay for it, and to have really angry users.

The best way will be to be able to ask an apple database to know when the user buy the application or something like that. If someone know a tricks to do that, I will love he shares it ;)

Damien
  • 21
  • 1
1

The most robust solution is to do receipt validation. If you do not have a server that your app is communicating with, you can do it on the device with the help of OpenSSL. (Check the WWDC videos on receipt validation for details.) The key point is that the receipt has an attribute that tells you at which version the user has originally purchased your app. Based on this information you can then unlock features for existing customers.

Jekapa
  • 169
  • 15