views:

539

answers:

6

Don't worry, I'm not trying to hack someone else's app, if that's what you're thinking =).

I want to have 2 versions of my app, a free version and a deluxe version. My plan was to use an in-app purchase to enable the deluxe version by setting a boolean value in the plist file.

My question is: is this secure or is it easily circumvented? And if it is not secure, can someone suggest a simple alternative? I don't want to download additional content, I would rather keep all of the functionality within the app and enable it somehow.

Edit: I don't mean the application plist file, but something like the user defaults file.

+1  A: 

Instead of worrying about the Info.plist file, why not just set a preference? Somewhere in your code, this would give you your boolean value:

[[NSUserDefaults standardUserDefaults] boolForKey:@"someKey"];

If the value doesn't exist, the result will be nil. This code sets the value:

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"someKey"];

Plus, these values will be backed up in iTunes, so if the user moves their backup to a new iPhone or simply restores from backup, the values will be restored.

Jeff Kelley
Yes I meant the standard defaults plist file, not the info.plist file. I've edited the question to clarify. Your suggestion was precisely my idea, I am just wondering how secure this is from piracy.
If someone has jailbroken their phone, it's as easy as modifying that file to change the value. Naturally, that value won't exist if they haven't purchased it, but if word got out about how to circumvent it, it could cause problems.
Jeff Kelley
+1  A: 

I don't have an answer, but it seems that editing your plist file dynamically is not possible, if I trust this subject :

You can not edit you're info.plist file dynamically. When you submit your app to The App Store, your app bundle, which includes info.plist, can't change because the signature created when you compile you app is based on the bundle.

Zed-K
+2  A: 

You should store this in the keychain, this is what I'll do. The keychain is far more secure than a .plist or the user defaults (which are .plists, too, as far as I know). Have a look at SFHFKeychainUtils, you should be able to use this or just implement a better method exactly for the need to save a simple bool.

bddckr
Thanks I will take a look at this
+1  A: 

I would recommend reading up on verifying in-app purchases. It sounds to me like you are trying to roll your own in-app purchase verification system which may be wrought with issues you might not have thought of yet. You have to be careful with your user's purchases that they will behave the same in your application as they will in any other, lest ye lose their trust (and future sales!)

fbrereto
+1  A: 

Any pirate has a jail-broken iPhone Any jail-broken device offers full file system access via tools like PhoneDisk, etc Any file system access allows people to change the values in your applications .plist file

Game over.

Now, its not trivial to wrapper that up for the script kiddies but then again its not that hard either.

Jeff
A: 

Storing state in defaults is no more nor less safe from privacy than having two versions of your app. Pirates will either pirate the deluxe version, or they'll pirate the unified version with the flag set.

quixoto