Expose .sqlite-files to the user in iOS - best practice?

Question

So I'm working on this application in iOS which uses sqlite in the bottom. I want to implement a export/import function that basically copies the .sqlite file created by Core Data to the Documents directory where the user can access it via iTunes. (The import function will obviously work the other way around.)

I want to hear some pro and con arguments. Letting a user get a hold of the .sqlite file revels my data model. Not that it is a trade secret or so, but anyway... There are many relations in the database, so exporting it to a tab delimited file (for example) is not convenient.

I also see that it might be problems with the import function and .sqlite files. What if the .sqlite was created from an older data model. What if the user manually updated the .sqlite in some way so the data model isn't valid. I guess that I have to do a lot of validation in the import function.

Any suggestions?

Answer 1

Don't worry about your data model. Anyone who wants to know what it looks like can find out anyway. Using an app like iExplorer will let them find out all kinds of things about your app without even needing to jailbreak the phone-- including SQLite files that are not available via iTunes and the Core Data model file itself. The details of your data model are already not going to be secure.

As for different versions-- Core Data includes a migration system that detects version conflicts and offers various migration options to update a data store to the latest version. As long as you're using model migration techniques when updating the model, you won't have any problems with the user copying an old version in-- you'll just end up migrating it as if the user had just upgraded to the new version of the app.

Answer 2

I followed an article in raywanderlich.com but it uses email for import and export.

I actually implemented export by zipping my .sqlite file and renaming the extension of the file with .abc ( use extension unique to your app ). By this way user doesn't knows the extension, so the chances of getting corrupted by editing this file may be low. And for the import i just unzip the file and replace the existing model. Note here i just replace my existing data with the imported file. I have used it in one app. And no complaints. People rarely edit if the extension is unknown.

Regarding Older data model, AFAIK if you have handled the core data migration, then the old model should be migrated to new model.

Regarding validating the file during the import, I think you cannot validate the .sqlite file? I mean to validate, you need to open the .sqlite file and read it, and to read it, it must match the schema. If it is corrupted it will not match and the app will crash. All you can do is catch the exception and throw error message.

Another ways

1. Rename the .sqlite file to something like .db so user may not try to open it with any .sqlite viewer.
2. Export as xml or json. By this way you can validate the import file and it will be easy if you are not just replacing the existing data during the import.

Pros 1. Simple way, you don't need any zipping library or any extra methods for converting to and from xml or json.

Cons

1. And if you are not just replacing the existing data during the import, then you got to do a lot. You have to copy all the entities from this .sqlite to another one. In that case i would be simply emport the data to json and rename the file extension. During the import i just parse the json and create / update managed object context. In this json case i would be creating UUID to uniquely identify each record.

Core data generated .sqlite is not the normal .sqlite file so the user will have some surprises if he tries to open it with sqllite viewer.

Once the file the goes out of app. We cannot control how it is being used. All we can do is throw some error message, if the user imports the corrupted file.

hope this helps.