iOS persistant storage with update function

| | August 6, 2015

im developing a game which has different levels and i need to store all levels and its elements (position, image, sounds,..) into a file/database. The levels will be updated so i need a function that checks online for a update and downloads a database dump and additional files.

I was planing to store all the persistent data into a SQLLite database, but not quite sure how to do the update part – to pack the database dump and the files together (in a .zip or with a xml). Can this be done any other way (as secure as possible)?


3 Responses to “iOS persistant storage with update function”

  1. Parse library [1] addresses exactly the problem of data persistence in mobile apps. It frees you from the “burden” of mantaining and query a database efficiently, and it should be quite easy to use since it is JSON friendly. Pricing allows you not to pay anything for trying it, or as long as your app becomes is not popular yet. Maybe it can really help you.


  2. I would recommend using your own binary format if you want efficient storage.

    Creating and packaging deltas for levels should be done on the server side. The clients should be able to only read the deltas and apply them.

    If you are comfortable with SQL and sqlite storage is good and efficient enough for you, there is no reason why not use it. You can package the deltas in any fashion you like and after retrieval apply them to the DB. This process could even be simplified if the server uses a similar database to store the levels.

    For each entry you can store a “level validity start version id” and “level validity end version id”. On the server side you can then simply use the version the client sends, pack the changes and apply them on the client.

    Using sql commands directly in the exchange protocol is not a good idea. If one of the versions of the client application end-up using a different version of sqlite or if you need to change the storage system you will end-up with a bag of hurt. Use your own format.

    If you need to secure the transfer you can use any encryption available to you.

  3. Seems that your game doesn’t need to store much data. I recommend that your save data can be easily converted to an NSDictionary (you can easily convert it to XML/plist). This way you won’t have to worry about exporting the data elsewhere (in your case in a server).

    In my projects, I have a protocol where you can do these:
    – Get the NSDictionary representation of the class (for exporting)
    – Update the class’ instance variables with an NSDictionary
    – Instantiate a class using an NSDictionary.

    It works like NSCoding where you can do it in hierarchy. This may add a bit of complexity but will offer you lots of flexibility.

    I always make it so that I’ll have full control on how my data is being stored and processed. (That’s why I’m not fond of using CoreData)

    Just a question, why do you need to store images and sounds? Isn’t that part of your assets/resources? I recommend you save what only really needs to persist.

Leave a Reply