Any non-trivial mobile app created these days needs to have some sort of server to back it up. If not to drive the logic of the app, a server is need to at least persist data outside of the device itself. Since connectivity & latency over mobile networks vary, this complicates our persistence strategy because we can’t always assume the server will be available, and if available we can’t assume it will deliver the necessary information in time to make the user experience on the phone a good one.

This leads us inevitably to some sort of device-local storage to persist data. In the case of iOS, we would use CoreData to store data that we’d like to query as fast as possible. This is very convenient because not only are we guaranteed to have this data on our local device when the app starts, we also know it is retrievable at orders of magnitude faster than pulling information from the web.

But not everything can live on our device. Eventually we need to sync our device with the server, pull new information from the server, etc. So we are faced with a complicated dilemma of maintaining persistent data in two separate contexts. It’s an interesting problem that have varying patterns to solve. A really great video that explains the problem and a few solutions was delivered at Google I/O 2010. Although it was in the context of Android, its principles can be applied elsewhere. I highly recommend watching it.

In the iOS context we now have CoreData and a server backend we communicate with using HTTP. Newcomers to iOS are often directed to Apple’s official guide to network requests, revolving around the NSURLConnection class. There is a lot of criticism of the utility of this class as is, and often times it just breaks down when dealing with different HTTP cases. I would recommend you read the guide, but don’t write your network code based on it. The open source community has offered a few libraries that both simplify and empower network operations. Two come to mind right now.

ASIHTTPRequest and RestKit are both good libraries that fill in the void left by NSURLConnection. From easy access to headers, cookie management, caching to support of persistent connections and connectivity notifications. I’ve been using ASIHTTPRequest for a while now. I like it for its simplicity, its ability to easily parse through HTTP headers, cookies, status codes and payloads. I also really appreciate the introduction of blocks into its request model. Blocks programming is a big plus in my book, especially since nearly all of your network operations should be asynchronous.

ASIHTTPRequest is a great toolset to use and I highly recommend its use, but its really only meant for network operations. My problem is not just with connectivity, its with persistence as well. So I was contemplating mapping my JSON payloads to CoreData for local-device storage. But then I discovered RestKit. In my opinion, RestKit is weaker than ASIHTTPRequest when it comes to network operation features. However what it lacks in that area, it makes up for in object mapping and CoreData integration. While ASIHTTPRequest utilizes CFNetwork code giving it a closer to the metal feel, RestKit network code is based on NSURLConnection, which is deficient in my opinion. RestKit also does not support blocks programming as of yet.

I’m still getting to know RestKit. I’ve spent a few does reading the source, fixing a few bugs, and adding blocks support. Its been useful to properly sync my server to CoreData with little code on my part. The areas it needs improvement on are to get away from NSURLConnection, provide better support for synchronous operations and introduce blocks as the callback paradigm. This was not meant to persuade one to use one library or the other. Rather it is meant to share, in my experience, when I would choose to use one over the other. Since I haven’t benchmarked the two, its hard to conclude just yet. However, if you are looking to build a CoreData layer that needs to be in close sync with a server backend, you may save yourself a lot of time by trying out RestKit.

My forked version of RestKit with blocks support is up on github if you wanna take a look and contribute.