iOS update core data file from a remote source - core-data

Question

I have an iOS 7 app with a static (not editable by the user) coredata file. Once in a while this file has to be updated. Like updating a recipe in a cookbook or a phone number in an address book.
The app itself (the binary file) remains unchanged.
I have never done something like this. I am looking for a starting point (a guide or google search terms) for learning rather than concrete solutions.
Which frameworks should I use for this?
Do I need my own webserver?
How can I ensure that the correct datafile is received by the app?
Similarly, how can I ensure that only my app is requesting the data?
How should I handle security? How do I know it's me sending the update?
Probably I have to send a notification to the app telling it to download data from somewhere? Should I hardcode a server address in the app from where to download data?

Answer 1

I'm using a simple web site for this. I have a text file with a version number (or date) in the web site. My code simply downloads the file, checks the version or date with the version field in my database. If it is newer, it activates the download button.
The download button downloads a zip file (doesn't have to be zip), extracts them and replaces the existing core data files with new onen. It has been working without any problems so far (since 2012).
Although the recommended way is to delete all the data in core database one by one and update just the data using a remote source, I'm using my approach of simply replacing the core database's sqlite file and related files. Here's the code snippet: -
//removing the core data files
NSString *finalPath = [NSHomeDirectory()
stringByAppendingPathComponent:#"Documents/NTTimeTable.sqlite"];
[[NSFileManager defaultManager] removeItemAtPath:finalPath error:nil];
finalPath = [NSHomeDirectory()
stringByAppendingPathComponent:#"Documents/NTTimeTable.momd/NTTimeTable.mom"];
[[NSFileManager defaultManager] removeItemAtPath:finalPath error:nil];
finalPath = [NSHomeDirectory()
stringByAppendingPathComponent:#"Documents/NTTimeTable.momd/NTTimeTable.omo"];
[[NSFileManager defaultManager] removeItemAtPath:finalPath error:nil];
finalPath = [NSHomeDirectory()
stringByAppendingPathComponent:#"Documents/NTTimeTable.momd/VersionInfo.plist"];
[[NSFileManager defaultManager] removeItemAtPath:finalPath error:nil];
// Unzipping downloaded file
finalPath = [NSHomeDirectory()
stringByAppendingPathComponent:#"Documents"];
[SSZipArchive unzipFileAtPath:tempFilePath toDestination:finalPath];
[[NSFileManager defaultManager] removeItemAtPath:tempFilePath error:nil];
Let me know if you need more info. Please note that I've moved my core database files to the Documents directory because I didn't have permissions to replace them when they were in their original location.
Q/A
As I showed above, I'm just using a web server and leaving an update file on my website.
I think it's better to have your own webserver. You can get a cheap one on the internet. You could use free ones but you have to think about speed, bandwidth, availability, etc.
You could use a checksum to verify the file is intact. To ensure the file is correct, you could do checks like reading the file size, contents, etc. In my case, I'm not doing anything as I've hardcoded the file url. It depends on how sensitive your data is. Mine was pretty much like a public thing.
In order to ensure that only your app requests the data, you could use some simple authentication. Maybe getting the app to make a post request with a username and/or password/hash, and getting the web server check them will do. I would use a small php file in the server as most of the cheap web hosting providers support php. I would hard code the username and password/hash in the php file in web server. If you are really serious, you might want to look at authentication mechanisms such as asymmetric cryptography.
This is a hard part. Even if you hard code the download url in the app, people can still make a fake webserver to send the files/data by changing DNS or doing all sorts of things. At the end of the day, you will only be making things harder to break into, not 100% secure.