Transition from RestKit to pure AFNetworking 2.0

Question

I'd been using RestKit for the last two years, but recently I've started thinking about transition from these monolith framework as it seems to be really overkill.

Here's my pros for moving forward:

1. There is big need in using NSURLSession for background fetches and RestKit has only experimental branch for transition to AFNetworking 2.0. No actual dates when transition will be finished. (Main Reason)
2. No need for CoreData support in network library as no need for fully functional offline data storage.
3. Having headache with new concept of response/request descriptors as they don't support different parameters in path patterns (ex. access token parameter) and there is no way to create object request operation in one line with custom descriptor. Here I am loosing features of object manager as facade.

I. The biggest loss of RestKit for me in object mapping process. Could you recommend standalone libraries that you use which shows themselves as flexible and stable?

II. And as I sad I need no fully functional storage but I still need some caching support in some places. I've heard that NSURLCache has become useful in last OS release. Did you use it and what's the strategy? Does it return cached API responses when network connection is down?

III. Does anybody faces the same problems? What solutions have you applied? Maybe someone could give some piece of advice about architecture that he or she uses in multiple apps with pure AFNetworking?

Answer 1

I. In agreement with others who have commented, AFNetworking + Mantle is a simple and effective way to interact with a Restful API and to replace RestKit's object mapping process that you miss.

II. To answer the requirements of your caching support is highly dependent on the context. However, I have found for my recent functional requirements that caching a view model for a particular controller's screen and only caching reference data returned by APIs allows me to keep the application logic relatively simple whilst giving the user some continuity. A simple error notification for connectivity issues can be dealt with a cross-cutting manner.

III. One thought on the architecture relevant to this aspect is to ensure that the APIs the app is dependent on provides data according to the app experience. This allows your app to focus on what it is good at (a very slick user-experience) and moves logic into the API's closer to API dependencies such as data. This has a further benefit of reducing the chattiness of the app.