I'm still in the very early stages of a game, and I am saving information using a KeyChain wrapper class someone made. I wanted to ask for some advice early on, since I have time to change my approach.
My game has the potential to persist a fair amount of data about the player and what they've done, such as:
how much gold the player has
what items they've acquired (you can get about 50 items)
what skills, spells, and abilities they've chosen for their character
what experience level they are, max health, stats, etc
The reason I decided to store this in KeyChain was that I was told it's encrypted and much more difficult to tamper with. I felt there were other solutions such as the ones below, but I wrote some potential reasons why that might not be good:
Make everything web-based, and stored in a database somewhere on my server - I want my game to be playable offline
Use a local database (FMDB, let's say) - I could use a tool to edit the values directly, and give myself more health, etc.
Use Core Data - Never used this before, not sure if this is the same ease of tampering as #3?
GameCenter - Never used this before, so not sure what the lift is
NSPreferences - Preferences are more easily tampered with (i've used a tool to change the values pretty quickly)
So I am not sure if i'm completely wrong above, but let's say there is some degree of truth there and KeyChain is a good approach. The problem is now what if I want to then somehow allow the player to pick up a new device and pick up where they left off? How on earth would I serialize all that data I'm saving in keychain? I don't mind creating a giant JSON document of the values, and sending it along somewhere (where? to GameCenter?)
Any advice / pointers in the right direction would be good, especially now since i'm in the early stages and can make changes to step back.
Thanks so much everyone appreciate your time!
A few thoughts based on lessons learned (usually, "the hard way") that may (or may not) be helpful. :)
I see three requirements in your post: offline play (requiring local storage), data security (which is a massive topic in and of itself) and synchronization.
Playable offline:
Thus you need some sort of local storage. Keychain, Core Data, SQL, NSPreferences are all options. I don't know the limitations of the Keychain, so not really sure how suitable it is for continuous read/write of large chunks of data.
Data security:
They keychain protects your secrets when you're not logged in, and partitions them between apps. https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html and http://evgenii.com/blog/sharing-keychain-in-ios/ give more details. That should prevent other tools from modifying other app's content on non-jailbroken devices.
Core Data, SQL, et al will be inside your app's container, which makes it harder for other tools to access on non-jailbroken devices. There's a good description here: https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
NSPreferences doesn't offer any security that I'm aware of. Plus, if they jailbreak the device, they basically have root access on a linux machine and can probably do anything they want.
In today's security world, the mantra is generally, "assume breach." As in, assume if they want in bad enough, they're going to find a way in. Thus you need to think about other layers of defense: partitioning your secrets so compromised secrets have limited value, encryption at rest and encryption in transit. Obfuscating the data before you write it/transmit is therefore another layer of defense (although they may still edit it and you'll have to handle potential garbage values).
You can chase security pretty far down the rabbit hole; you'll have to decide where the cost outweighs the benefit, and/or what risks you intend to defend against.
Synchronization across devices:
Thus you need a syncing solution. the iCloud Keychain syncs between devices, so if the keychain meets your storage needs, this probably will meet your sync needs, too. Again, I'm not sure if there are size or frequency-of-update constraints. I haven't used this, but this SO answer gives more info: https://stackoverflow.com/a/32606371/1641444. Based on Apple's docs (https://support.apple.com/en-us/HT204085) it looks like the user does have to enable syncing for this to work.
Otherwise, Apple provides GameCenter and CloudKit. Or you could explore 3rd party options. I've used GameCenter and CloudKit to sync data across devices. CloudKit wins over GameCenter, IMO, no contest.
With GameCenter, you gain multiplayer matchmaking and channels to share data between users. But, you have to adhere specifically to its structure which is IMO both extremely frustrating to work with and limited in functionality. Check the GameCenter and GKTurnBasedMatch tags here on SO for a taste of the problems.
CloudKit is a lower-level solution. It allows you to store a wide variety of data objects in iCloud and "subscribe" to change notifications. All data is contained within a container for the app, and has a "private" (user-specific) section and a public (shared by all users of the app) section. After watching the introductory WWDC videos on CloudKit, I was successfully sync'ing user settings between devices AND different users on different devices in no time. However, if you want some of the multiplayer features of GameCenter, you'll have to build the data model/subscriptions yourself. Since you support offline play, you'd need to save your data to a local storage solution and periodically upload it to iCloud for sync.
Conclusion (aka TL;DR)
So, my opinion is: none of the tools individually meet all three of your requirements, and you'll end up rolling your own solution for at least 1 req, regardless of which option you go for. In my multiplayer game, I'm trusting in Apple's filesystem (containers) to provide sufficient data security, I'm using a local storage option within the app's container, and I'm periodically writing NSData objects to cloudKit for synchronization across devices. I hit my frustration limit with GameCenter and pulled it from my app.
Star for a good question!!
I'm doing something similar with this. Right now, I'm using UserDefaults for primary storage. When I need to transfer data, I can save it to iCloudKit, or I could export it as a plist or json to use with AlamoFire, email, etc.
As for actually storing the data, I saw you mentioned CoreData.. that is kind of overkill! Look at NSCoder and NSKeyedArchiver.
Personally, I make my own save/load functions that manipulate dictionaries, then toss them into a UserDefaults key.
An example hierarchy of how I store dicts in UserDefaults (there are many ways to go about this)
Key:
Items->Equipment->Weapons->WeaponName
Value:
{ dictionary of data like AP, Cost, etc }
This to me is easier than using NSCoder, and certainly easier than CoreData!! The goal is to turn everything into a dictionary, which you can then easily put into UserDefaults, which allows you to easily create plists or save to the cloud.
With the above key system, you basically just do for loops to find what you need, parsing out each section.. so a function to display all equipment, you just load the entire UserDefaults.standard.dictionaryRepresentation, then search for keys that only have 'Items->Equipment' and so on.
Hope this helps!
I have some functions from my game I could share if you need more tips.
UPDATE:
If you are making this an online game, I would focus on learning the essentials of persistence and cloud usage first, then port it to a more secure platform that uses encryption.
Your best bet will be to create your own servers and transfer data that way. That will give you exactly what you want, when you want it, and with the security that you want.
If you want to use GameCenter, I would use GC as an in-between layer of something custom you created, so that way you can filter out the cheaters' scores / have more flexibility.
I'm looking to develop a game in Swift with the following potential requirements:
It can be played offline
It offers the ability to save and reload from other devices
Boolean data values can be accessed by the game to determine whether the player has unlocked the levels in the game, as well as what they purchased (how much gold they have, items unlocked, etc).
The data cannot be tampered with (I wouldn't want someone to give themselves gold or unlock strong weapons without rightfully purchasing them)
I believe KeyChain is a good approach for this for the following reasons:
I can store data as key/value pairs and access them offline (great for my true/false values for what levels/items are unlocked)
The entire collection of data can be exported as a name/value pair, thus I can send the entire dictionary (in just a few lines of code) to the user's account using CloudKit/GameCenter, and then have it synchronize to other user devices (by importing that data).
It offers very robust security
It feels weird for me to use KeyChain as a poor man's database but for the above reasons I listed I think it could work.
The problem is I could see the name/value pairs being somewhere in the 200-300 range. Would you say storing this many values in KeyChain is a bad decision? It doesn't seem particularly slow (yet).
An alternative to me is to use a database, however many of these values are simply true/false (what levels are unlocked, sword-1 unlocked, armor-3 unlocked, total gold acquired, etc). I suppose the game could grow where it suddenly becomes too robust to manage all of this using KeyChain (and instead I encrypt the database using SQLCipher) but I wanted to ask the community's opinion on storing this many values in KeyChain.
Thanks!
You can just store your info in a plist, csv or database or any other kind of file in the documents directory and encrypt. Store the key in the keychain and use they key to decrypt the file. There are plenty of cryptography pods that will do this part for you so you don't have to deal with the joys of C interop with common crypto.
In my iOS app, I need to keep track of which sequence numbers have already been received from the server and which sequence numbers need to be retrieved. I want to be able to store this in case the app terminates or crashes.
I am trying to decide which storage method I should use: core data, plist etc.
The list of sequence numbers is dynamic and can change a lot. Any pointers on how to decide on storage will be greatly appreciated.
Without more exact details in your question it is hard to give you an accurate answer. However, what can be provided is some insights on the benefits / downfalls of using the storage systems listed above.
I would stay away from using a plist since your data is dynamic and can change a lot. Every time you save to a plist you will need to overwrite the entire file. This means to change a single value you must retrieve all values, make a single change, and save all values back to the plist. This isn't a modular way of doing such saves and can become problematic if you have a lot of information that is changing and needs to be saved all the time. On the up side - setting up a plist save / read write structure is very easy and fast.
NSUserDefaults should be used for just that. Saving user settings and preferences. It is really easy to use NSUserDefaults, but may become very problematic in the long run if you data is very large. Values returned from NSUserDefaults are immutable too. This may or may not be a problem for your needs.
CoreData may be overkill for what you're doing, unless your sequence numbers are very large. Personally, I would go with CoreData knowing how it can handle dynamic values and how fast it is to save objects compared to the plist and NSUserDefaults. The down side is CoreData is a bit of a learning curve. Unless you have used it before, it is easy to go down the wrong path using it.
As far as pointers on which storage option to use, do some research. Make a list of pros and cons of each storage option. Ask yourself how big your data may get, and what is the best solution. You already know the data is dynamic and may change a lot. Look at the performance of each storage solution.
Here are some helpful reading material links straight from Apple:
Plist
NSUserDefaults
CoreData
I'm working on a new iOS game and would like to save the progress online through iCloud. The saving is fairly frequent, but they are mostly doubles and ints with scores, unlocks and NSDate numbers.
Since internet will be required to play the game, I would like to save the game only online, not locally. When the app opens it should download the saved game from the server, and when it's done, launch the game.
Online currency will be sold through IAP, so I want to make sure the progress will not be lost even if the game is deleted and reinstalled, and of course, be available on multiple devices from the same user.
What's the best way to do this? Is it possible through iCloud? Key value seems like a mess because it doesn't sync quickly with iCloud. So Core Data?
I'm not looking for code to copy and paste, but I would like to create a discussion to find out the best solution for this case, if it's iCloud, setting up my own server, etc. Everywhere I look people say different things, but so far I couldn't find the best solution.
Thanks!
In iOS 8, you might want to look at GKSavedGame — it manages saved games associated with a Game Center player and syncs them through iCloud.
Otherwise, direct use of iCloud APIs sounds reasonable for your use case. If you write a small, well-defined set of values, the ubiquitous key-value store is very easy to use. If your save games are more complicated, write out a property list or encode your custom objects with NSKeyedArchiver, then use the NSFileManager APIs for syncing the resulting files through iCloud.
Going for Core Data or CloudKit is also possible, but sounds like it's more complicated than your game needs.
I want to store earned xp and gold, so that my game loads the data whenever the game starts. I am using cocos2d on the iPhone, what would be a safe (doesn't need to be toooo safe) to store such data?
I don't want the user to be able to modify the xp-points too easily. Is that possible with .plists? Or do I have to use a Database like SQL lite? It would be very nice if the user couldn't just change the values of the .plist that easily.
It may be easiest to use NSUserPreferences.
How about storing the information in a dictionary, archiving it, then encrypting the data with one of the many available encryption categories like the one shared by Aquatic?
Nothing you can do would stop a determined and experienced hacker but this would make it difficult / effectively impossible for the average user.