I see two obvious approaches to the architecture for an iOS app which needs to talk to a server to do its job.

Pretend to be a web browser

Under this approach, the app fetches a chunk of data (typically JSON) from the server in response to a user action (navigating to a new view controller, tapping an "Update", whatever), puts up a spinner or some other progress indicator, then updates the view when the request completes. The "model" classes are mapped directly from the incoming JSON and possibly even immutable, and thrown away when the user moves off the screen they were fetched to populate.

Under the "pure" version of this approach you set the appropriate headers on the server and let NSURLSession and friends handle caching.

This works fine if you can assume the user has fast, low-latency network connectivity, and is mostly reading data from the server and not writing.


With the "sync" approach, the app maintains a local Core Data store of model objects to display to the user. It refreshes this either in response to user action or periodically, and updates the UI (via KVO or similar) when the model changes. When the user modifies the model, these changes are sent to the server asynchronously; there must be a mechanism for resolving conflicts.

This approach is more suitable when the app needs to function offline or in high latency/slow network contexts, or where the user is writing a lot of data and they need to see model changes without waiting for a server round-trip.

Is there a third in-between way? What if I have an app which is mostly but not always reads, but where there are writes the user should see those updates reflected in the UI immediately. The app should be usable in low/no network situations (showing any previously cached data until a request to the server has time to respond.)

Can I get the best of both worlds without going full Core-Data-with-sync (which feels heavyweight and is difficult to get right) but without also inadvertently implementing a buggy and incomplete clone of Core Data?

  • 1
    Can you tell us a bit more about what the server actually does? From the description so far, it sounds like it is mostly being used as cloud-style data store and possibly to read some resources. Do many operations need to touch the server in order to work right? Do the resources that get pulled down get updated frequently/ever? Another thing to keep in mind is that security can get trickier the heavier the client side gets.
    – J Trana
    Sep 7, 2014 at 22:43
  • I'm asking in the general sense, I don't have a particular app in mind. I acknowledge in the question that different approaches may be more suited to a read-heavy context vs a write-heavy context (or a high bandwidth, low-latency context vs a low bandwidth, high latency context.) Sep 10, 2014 at 13:21
  • Well, the specific needs often drive the architecture. You seem to be thinking about this with an iOS mindset, but for general architectures, it may be useful to think more generally. So, for different ways to split it. One, send only raster graphical updates to the client and capture input events, like remote desktop. Two, send vector/raster graphics instead. Three, thin client that gets presentation layer objects. Four, thin-ish client that touches services over say JSON. Five, thick client that holds its own service layer and touches other services and data layers.
    – J Trana
    Sep 11, 2014 at 1:13
  • Six, extremely thick client that primarily touches a remote data layer. I would argue the web browser approach is like four or possibly three. The sync version is arguably like five, with a nice twist. These are not necessarily all good approaches, and may not all fit your needs. So what type of app do you want to make so we can get a tailored answer in here?
    – J Trana
    Sep 11, 2014 at 1:18

1 Answer 1


Not from an effort perspective. If you're implementing anything via a sync model, you need to build everything that entails. You can optionally choose to allow - for some feeds - lazy loading on refresh if this is desirable from a performance standpoint (this is a common practice for small and obscure feeds that less than 50% of the userbase will ever navigate to).

But of course, while that's even better than going "one or the other" as above, it does have an issue that you essentially need to build both. It is in my opinion however the most efficient way to handle data loading into a mobile app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.