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?