Best architectural approaches for building iOS networking applications (REST clients)

Question

I'm an iOS developer with some experience and this question is really interesting to me. I saw a lot of different resources and materials on this topic, but nevertheless I'm still confused. What is the best architecture for an iOS networked application? I mean basic abstract framework, patterns, which will fit every networking application whether it is a small app which only have a few server requests or a complex REST client. Apple recommends to use MVC as a basic architectural approach for all iOS applications, but neither MVC nor the more modern MVVM patterns explain where to put network logic code and how to organize it in general.

Do I need to develop something like MVCS(S for Service) and in this Service layer put all API requests and other networking logic, which in perspective may be really complex? After doing some research I found two basic approaches for this. Here it was recommended to create a separate class for every network request to web-service API (like LoginRequest class or PostCommentRequest class and so on) which all inherits from the base request abstract class AbstractBaseRequest and in addition to create some global network manager which encapsulates common networking code and other preferences (it may be AFNetworking customisation or RestKit tuning, if the we have complex object mappings and persistence, or even an own network communication implementation with standard API). But this approach seems an overhead for me. Another approach is to have some singleton API dispatcher or manager class as in the first approach, but not to create classes for every request and instead to encapsulate every request as an instance public method of this manager class like: fetchContacts, loginUser methods, etc. So, what is the best and correct way? Are there other interesting approaches I don't know yet?

And should I create another layer for all this networking stuff like Service, or NetworkProvider layer or whatever on top of my MVC architecture, or this layer should be integrated (injected) into existing MVC layers e.g. Model?

I know there exists beautiful approaches, or how then such mobile monsters like Facebook client or LinkedIn client deal with exponentially growing complexity of networking logic?

I know there are no exact and formal answer to the problem. The goal of this question is to collect the most interesting approaches from experienced iOS developers. The best suggested approach will be marked as accepted and awarded with a reputation bounty, others will be upvoted. It is mostly a theoretical and research question. I want to understand basic, abstract and correct architectural approach for networking applications in iOS. I hope for detailed explanation from experienced developers.

Solution 1

I want to understand basic, abstract and correct architectural approach for networking applications in iOS

There is no "the best", or "the most correct" approach for building an application architecture. It is a very creative job. You should always choose the most straightforward and extensible architecture, which will be clear for any developer, who begin to work on your project or for other developers in your team, but I agree, that there can be a "good" and a "bad" architecture.

You said:

collect the most interesting approaches from experienced iOS developers

I don't think that my approach is the most interesting or correct, but I've used it in several projects and satisfied with it. It is a hybrid approach of the ones you have mentioned above, and also with improvements from my own research efforts. I'm interesting in the problems of building approaches, which combine several well-known patterns and idioms. I think a lot of Fowler's enterprise patterns can be successfully applied to the mobile applications. Here is a list of the most interesting ones, which we can apply for creating an iOS application architecture (in my opinion): Service Layer, Unit Of Work, Remote Facade, Data Transfer Object, Gateway, Layer Supertype, Special Case, Domain Model. You should always correctly design a model layer and always don't forget about the persistence (it can significantly increase your app's performance). You can use Core Data for this. But you should not forget, that Core Data is not an ORM or a database, but an object graph manager with persistence as a good option of it. So, very often Core Data can be too heavy for your needs and you can look at new solutions such as Realm and Couchbase Lite, or build your own lightweight object mapping/persistence layer, based on raw SQLite or LevelDB. Also I advice you to familiarize yourself with the Domain Driven Design and CQRS.

At first, I think, we should create another layer for networking, because we don't want fat controllers or heavy, overwhelmed models. I don't believe in those fat model, skinny controller things. But I do believe in skinny everything approach, because no class should be fat, ever. All networking can be generally abstracted as business logic, consequently we should have another layer, where we can put it. Service Layer is what we need:

It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

In our MVC realm Service Layer is something like a mediator between domain model and controllers. There is a rather similar variation of this approach called MVCS where a Store is actually our Service layer. Store vends model instances and handles the networking, caching etc. I want to mention that you should not write all your networking and business logic in your service layer. This also can be considered as a bad design. For more info look at the Anemic and Rich domain models. Some service methods and business logic can be handled in the model, so it will be a "rich" (with behaviour) model.

I always extensively use two libraries: AFNetworking 2.0 and ReactiveCocoa. I think it is a must have for any modern application that interacts with the network and web-services or contains complex UI logic.

ARCHITECTURE

At first I create a general APIClient class, which is a subclass of AFHTTPSessionManager. This is a workhorse of all networking in the application: all service classes delegate actual REST requests to it. It contains all the customizations of HTTP client, which I need in the particular application: SSL pinning, error processing and creating straightforward NSError objects with detailed failure reasons and descriptions of all API and connection errors (in such case controller will be able to show correct messages for the user), setting request and response serializers, http headers and other network-related stuff. Then I logically divide all the API requests into subservices or, more correctly, microservices: UserSerivces, CommonServices, SecurityServices, FriendsServices and so on, accordingly to business logic they implement. Each of these microservices is a separate class. They, together, form a Service Layer. These classes contain methods for each API request, process domain models and always returns a RACSignal with the parsed response model or NSError to the caller.

I want to mention that if you have complex model serialisation logic - then create another layer for it: something like Data Mapper but more general e.g. JSON/XML -> Model mapper. If you have cache: then create it as a separate layer/service too (you shouldn't mix business logic with caching). Why? Because correct caching layer can be quite complex with its own gotchas. People implement complex logic to get valid, predictable caching like e.g. monoidal caching with projections based on profunctors. You can read about this beautiful library called Carlos to understand more. And don't forget that Core Data can really help you with all caching issues and will allow you to write less logic. Also, if you have some logic between NSManagedObjectContext and server requests models, you can use Repository pattern, which separates the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. So, I advice to use Repository pattern even when you have a Core Data based architecture. Repository can abstract things, like NSFetchRequest,NSEntityDescription, NSPredicate and so on to plain methods like get or put.

After all these actions in the Service layer, caller (view controller) can do some complex asynchronous stuff with the response: signal manipulations, chaining, mapping, etc. with the help of ReactiveCocoa primitives , or just subscribe to it and show results in the view. I inject with the Dependency Injection in all these service classes my APIClient, which will translate a particular service call into corresponding GET, POST, PUT, DELETE, etc. request to the REST endpoint. In this case APIClient is passed implicitly to all controllers, you can make this explicit with a parametrised over APIClient service classes. This can make sense if you want to use different customisations of the APIClient for particular service classes, but if you ,for some reasons, don't want extra copies or you are sure that you always will use one particular instance (without customisations) of the APIClient - make it a singleton, but DON'T, please DON'T make service classes as singletons.

Then each view controller again with the DI injects the service class it needs, calls appropriate service methods and composes their results with the UI logic. For dependency injection I like to use BloodMagic or a more powerful framework Typhoon. I never use singletons, God APIManagerWhatever class or other wrong stuff. Because if you call your class WhateverManager, this indicates than you don't know its purpose and it is a bad design choice. Singletons is also an anti-pattern, and in most cases (except rare ones) is a wrong solution. Singleton should be considered only if all three of the following criteria are satisfied:

1. Ownership of the single instance cannot be reasonably assigned;
2. Lazy initialization is desirable;
3. Global access is not otherwise provided for.

In our case ownership of the single instance is not an issue and also we don't need global access after we divided our god manager into services, because now only one or several dedicated controllers need a particular service (e.g. UserProfile controller needs UserServices and so on).

We should always respect S principle in SOLID and use separation of concerns, so don't put all your service methods and networks calls in one class, because it's crazy, especially if you develop a large enterprise application. That's why we should consider dependency injection and services approach. I consider this approach as modern and post-OO. In this case we split our application into two parts: control logic (controllers and events) and parameters.

One kind of parameters would be ordinary “data” parameters. That’s what we pass around functions, manipulate, modify, persist, etc. These are entities, aggregates, collections, case classes. The other kind would be “service” parameters. These are classes which encapsulate business logic, allow communicating with external systems, provide data access.

Here is a general workflow of my architecture by example. Let's suppose we have a FriendsViewController, which displays list of user's friends and we have an option to remove from friends. I create a method in my FriendsServices class called:

- (RACSignal *)removeFriend:(Friend * const)friend

where Friend is a model/domain object (or it can be just a User object if they have similar attributes). Underhood this method parses Friend to NSDictionary of JSON parameters friend_id, name, surname, friend_request_id and so on. I always use Mantle library for this kind of boilerplate and for my model layer (parsing back and forward, managing nested object hierarchies in JSON and so on). After parsing it calls APIClient DELETE method to make an actual REST request and returns Response in RACSignal to the caller (FriendsViewController in our case) to display appropriate message for the user or whatever.

If our application is a very big one, we have to separate our logic even clearer. E.g. it is not *always* good to mix `Repository` or model logic with `Service` one. When I described my approach I had said that `removeFriend` method should be in the `Service` layer, but if we will be more pedantic we can notice that it better belongs to `Repository`. Let's remember what Repository is. Eric Evans gave it a precise description in his book [DDD]:

A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability.

So, a Repository is essentially a facade that uses Collection style semantics (Add, Update, Remove) to supply access to data/objects. That's why when you have something like: getFriendsList, getUserGroups, removeFriend you can place it in the Repository, because collection-like semantics is pretty clear here. And code like:

- (RACSignal *)approveFriendRequest:(FriendRequest * const)request;

is definitely a business logic, because it is beyond basic CRUD operations and connect two domain objects (Friend and Request), that's why it should be placed in the Service layer. Also I want to notice: don't create unnecessary abstractions. Use all these approaches wisely. Because if you will overwhelm your application with abstractions, this will increase its accidental complexity, and complexity causes more problems in software systems than anything else

I describe you an "old" Objective-C example but this approach can be very easy adapted for Swift language with a lot more improvements, because it has more useful features and functional sugar. I highly recommend to use this library: Moya. It allows you to create a more elegant APIClient layer (our workhorse as you remember). Now our APIClient provider will be a value type (enum) with extensions conforming to protocols and leveraging destructuring pattern matching. Swift enums + pattern matching allows us to create algebraic data types as in classic functional programming. Our microservices will use this improved APIClient provider as in usual Objective-C approach. For model layer instead of Mantle you can use ObjectMapper library or I like to use more elegant and functional Argo library.

So, I described my general architectural approach, which can be adapted for any application, I think. There can be a lot more improvements, of course. I advice you to learn functional programming, because you can benefit from it a lot, but don't go too far with it too. Eliminating excessive, shared, global mutable state, creating an immutable domain model or creating pure functions without external side-effects is, generally, a good practice, and new Swift language encourages this. But always remember, that overloading your code with heavy pure functional patterns, category-theoretical approaches is a bad idea, because other developers will read and support your code, and they can be frustrated or scary of the prismatic profunctors and such kind of stuff in your immutable model. The same thing with the ReactiveCocoa: don't RACify your code too much, because it can become unreadable really fast, especially for newbies. Use it when it can really simplify your goals and logic.

So, read a lot, mix, experiment, and try to pick up the best from different architectural approaches. It is the best advice I can give you.

Solution 2

According to the goal of this question, I'd like to describe our architecture approach.

Architecture approach

Our general iOS application’s architecture stands on following patterns: Service layers, MVVM, UI Data Binding, Dependency Injection; and Functional Reactive Programming paradigm.

We can slice a typical consumer facing application into following logical layers:

• Assembly
• Model
• Services
• Storage
• Managers
• Coordinators
• UI
• Infrastructure

Assembly layer is a bootstrap point of our application. It contains a Dependency Injection container and declarations of application’s objects and their dependencies. This layer also might contain application’s configuration (urls, 3rd party services keys and so on). For this purpose we use Typhoon library.

Model layer contains domain models classes, validations, mappings. We use Mantle library for mapping our models: it supports serialization/deserialization into JSON format and NSManagedObject models. For validation and form representation of our models we use FXForms and FXModelValidation libraries.

Services layer declares services which we use for interacting with external systems in order to send or receive data which is represented in our domain model. So usually we have services for communication with server APIs (per entity), messaging services (like PubNub), storage services (like Amazon S3), etc. Basically services wrap objects provided by SDKs (for example PubNub SDK) or implement their own communication logic. For general networking we use AFNetworking library.

Storage layer’s purpose is to organize local data storage on the device. We use Core Data or Realm for this (both have pros and cons, decision of what to use is based on concrete specs). For Core Data setup we use MDMCoreData library and bunch of classes - storages - (similar to services) which provide access to local storage for every entity. For Realm we just use similar storages to have access to local storage.

Managers layer is a place where our abstractions/wrappers live.

In a manager role could be:

• Credentials Manager with its different implementations (keychain, NSDefaults, ...)
• Current Session Manager which knows how to keep and provide current user session
• Capture Pipeline which provides access to media devices (video recording, audio, taking pictures)
• BLE Manager which provides access to bluetooth services and peripherals
• Geo Location Manager
• ...

So, in role of manager could be any object which implements logic of a particular aspect or concern needed for application working.

We try to avoid Singletons, but this layer is a place where they live if they are needed.

Coordinators layer provides objects which depends on objects from other layers (Service, Storage, Model) in order to combine their logic into one sequence of work needed for certain module (feature, screen, user story or user experience). It usually chains asynchronous operations and knows how to react on their success and failure cases. As an example you can imagine a messaging feature and corresponding MessagingCoordinator object. Handling sending message operation might look like this:

1. Validate message (model layer)
2. Save message locally (messages storage)
3. Upload message attachment (amazon s3 service)
4. Update message status and attachments urls and save message locally (messages storage)
5. Serialize message to JSON format (model layer)
6. Publish message to PubNub (PubNub service)
7. Update message status and attributes and save it locally (messages storage)

On each of above steps an error is handled correspondingly.

UI layer consists of following sublayers:

1. ViewModels
2. ViewControllers
3. Views

In order to avoid Massive View Controllers we use MVVM pattern and implement logic needed for UI presentation in ViewModels. A ViewModel usually has coordinators and managers as dependencies. ViewModels used by ViewControllers and some kinds of Views (e.g. table view cells). The glue between ViewControllers and ViewModels is Data Binding and Command pattern. In order to make it possible to have that glue we use ReactiveCocoa library.

We also use ReactiveCocoa and its RACSignal concept as an interface and returning value type of all coordinators, services, storages methods. This allows us to chain operations, run them parallelly or serially, and many other useful things provided by ReactiveCocoa.

We try to implement our UI behavior in declarative way. Data Binding and Auto Layout helps a lot to achieve this goal.

Infrastructure layer contains all the helpers, extensions, utilities needed for application work.

---

This approach works well for us and those types of apps we usually build. But you should understand, that this is just a subjective approach that should be adapted/changed for concrete team's purpose.

Hope this will help you!

Also you can find more information about iOS development process in this blog post iOS Development as a Service

Solution 3

Because all iOS apps are different, I think there are different approaches here to consider, but I usually go this way:
Create a central manager (singleton) class to handle all API requests (usually named APICommunicator) and every instance method is an API call. And there is one central (non-public) method:

-(RACSignal *)sendGetToServerToSubPath:(NSString *)path withParameters:(NSDictionary *)params;

For the record, I use 2 major libraries/frameworks, ReactiveCocoa and AFNetworking. ReactiveCocoa handles async networking responses perfectly, you can do (sendNext:, sendError:, etc.).
This method calls the API, gets the results and sends them through RAC in 'raw' format (like NSArray what AFNetworking returns).
Then a method like getStuffList: which called the above method subscribes to it's signal, parses the raw data into objects (with something like Motis) and sends the objects one by one to the caller (getStuffList: and similar methods also return a signal that the controller can subscribe to).
The subscribed controller receives the objects by subscribeNext:'s block and handles them.

I tried many ways in different apps but this one worked the best out of all so I've been using this in a few apps recently, it fits both small and big projects and it's easy to extend and maintain if something needs to be modified.
Hope this helps, I'd like to hear others' opinions about my approach and maybe how others think this could be maybe improved.

Solution 4

In my situation I'm usually using ResKit library to set up the network layer. It provides easy-to-use parsing. It reduces my effort on setting up the mapping for different responses and stuff.

I only add some code to setup the mapping automatically. I define base class for my models (not protocol because of lot of code to check if some method is implemented or not, and less code in models itself):

MappableEntry.h

@interface MappableEntity : NSObject

+ (NSArray*)pathPatterns;
+ (NSArray*)keyPathes;
+ (NSArray*)fieldsArrayForMapping;
+ (NSDictionary*)fieldsDictionaryForMapping;
+ (NSArray*)relationships;

@end

MappableEntry.m

@implementation MappableEntity

+(NSArray*)pathPatterns {
    return @[];
}

+(NSArray*)keyPathes {
    return nil;
}

+(NSArray*)fieldsArrayForMapping {
    return @[];
}

+(NSDictionary*)fieldsDictionaryForMapping {
    return @{};
}

+(NSArray*)relationships {
    return @[];
}

@end

Relationships are objects which represent nested objects in response:

RelationshipObject.h

@interface RelationshipObject : NSObject

@property (nonatomic,copy) NSString* source;
@property (nonatomic,copy) NSString* destination;
@property (nonatomic) Class mappingClass;

+(RelationshipObject*)relationshipWithKey:(NSString*)key andMappingClass:(Class)mappingClass;
+(RelationshipObject*)relationshipWithSource:(NSString*)source destination:(NSString*)destination andMappingClass:(Class)mappingClass;

@end

RelationshipObject.m

@implementation RelationshipObject

+(RelationshipObject*)relationshipWithKey:(NSString*)key andMappingClass:(Class)mappingClass {
    RelationshipObject* object = [[RelationshipObject alloc] init];
    object.source = key;
    object.destination = key;
    object.mappingClass = mappingClass;
    return object;
}

+(RelationshipObject*)relationshipWithSource:(NSString*)source destination:(NSString*)destination andMappingClass:(Class)mappingClass {
    RelationshipObject* object = [[RelationshipObject alloc] init];
    object.source = source;
    object.destination = destination;
    object.mappingClass = mappingClass;
    return object;
}

@end

Then I'm setting up the mapping for RestKit like this:

ObjectMappingInitializer.h

@interface ObjectMappingInitializer : NSObject

+(void)initializeRKObjectManagerMapping:(RKObjectManager*)objectManager;

@end

ObjectMappingInitializer.m

@interface ObjectMappingInitializer (Private)

+ (NSArray*)mappableClasses;

@end

@implementation ObjectMappingInitializer

+(void)initializeRKObjectManagerMapping:(RKObjectManager*)objectManager {

    NSMutableDictionary *mappingObjects = [NSMutableDictionary dictionary];

    // Creating mappings for classes
    for (Class mappableClass in [self mappableClasses]) {
        RKObjectMapping *newMapping = [RKObjectMapping mappingForClass:mappableClass];
        [newMapping addAttributeMappingsFromArray:[mappableClass fieldsArrayForMapping]];
        [newMapping addAttributeMappingsFromDictionary:[mappableClass fieldsDictionaryForMapping]];
        [mappingObjects setObject:newMapping forKey:[mappableClass description]];
    }

    // Creating relations for mappings
    for (Class mappableClass in [self mappableClasses]) {
        RKObjectMapping *mapping = [mappingObjects objectForKey:[mappableClass description]];
        for (RelationshipObject *relation in [mappableClass relationships]) {
            [mapping addPropertyMapping:[RKRelationshipMapping relationshipMappingFromKeyPath:relation.source toKeyPath:relation.destination withMapping:[mappingObjects objectForKey:[relation.mappingClass description]]]];
        }
    }

    // Creating response descriptors with mappings
    for (Class mappableClass in [self mappableClasses]) {
        for (NSString* pathPattern in [mappableClass pathPatterns]) {
            if ([mappableClass keyPathes]) {
                for (NSString* keyPath in [mappableClass keyPathes]) {
                    [objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[mappingObjects objectForKey:[mappableClass description]] method:RKRequestMethodAny pathPattern:pathPattern keyPath:keyPath statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];
                }
            } else {
                [objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[mappingObjects objectForKey:[mappableClass description]] method:RKRequestMethodAny pathPattern:pathPattern keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];
            }
        }
    }

    // Error Mapping
    RKObjectMapping *errorMapping = [RKObjectMapping mappingForClass:[Error class]];
    [errorMapping addAttributeMappingsFromArray:[Error fieldsArrayForMapping]];
    for (NSString *pathPattern in Error.pathPatterns) {
        [[RKObjectManager sharedManager] addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:errorMapping method:RKRequestMethodAny pathPattern:pathPattern keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassClientError)]];
    }
}

@end

@implementation ObjectMappingInitializer (Private)

+ (NSArray*)mappableClasses {
    return @[
        [FruiosPaginationResults class],
        [FruioItem class],
        [Pagination class],
        [ContactInfo class],
        [Credentials class],
        [User class]
    ];
}

@end

Some example of MappableEntry implementation:

User.h

@interface User : MappableEntity

@property (nonatomic) long userId;
@property (nonatomic, copy) NSString *username;
@property (nonatomic, copy) NSString *email;
@property (nonatomic, copy) NSString *password;
@property (nonatomic, copy) NSString *token;

- (instancetype)initWithUsername:(NSString*)username email:(NSString*)email password:(NSString*)password;

- (NSDictionary*)registrationData;

@end

User.m

@implementation User

- (instancetype)initWithUsername:(NSString*)username email:(NSString*)email password:(NSString*)password {
    if (self = [super init]) {
        self.username = username;
        self.email = email;
        self.password = password;
    }
    return self;
}

- (NSDictionary*)registrationData {
    return @{
        @"username": self.username,
        @"email": self.email,
        @"password": self.password
    };
}

+ (NSArray*)pathPatterns {
    return @[
        [NSString stringWithFormat:@"/api/%@/users/register", APIVersionString],
        [NSString stringWithFormat:@"/api/%@/users/login", APIVersionString]
    ];
}

+ (NSArray*)fieldsArrayForMapping {
    return @[ @"username", @"email", @"password", @"token" ];
}

+ (NSDictionary*)fieldsDictionaryForMapping {
    return @{ @"id": @"userId" };
}

@end

---

Now about the Requests wrapping:

I have header file with blocks definition, to reduce line length in all APIRequest classes:

APICallbacks.h

typedef void(^SuccessCallback)();
typedef void(^SuccessCallbackWithObjects)(NSArray *objects);
typedef void(^ErrorCallback)(NSError *error);
typedef void(^ProgressBlock)(float progress);

And Example of my APIRequest class that I'm using:

LoginAPI.h

@interface LoginAPI : NSObject

- (void)loginWithCredentials:(Credentials*)credentials onSuccess:(SuccessCallbackWithObjects)onSuccess onError:(ErrorCallback)onError;

@end

LoginAPI.m

@implementation LoginAPI

- (void)loginWithCredentials:(Credentials*)credentials onSuccess:(SuccessCallbackWithObjects)onSuccess onError:(ErrorCallback)onError {
    [[RKObjectManager sharedManager] postObject:nil path:[NSString stringWithFormat:@"/api/%@/users/login", APIVersionString] parameters:[credentials credentialsData] success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) {
        onSuccess(mappingResult.array);
    } failure:^(RKObjectRequestOperation *operation, NSError *error) {
        onError(error);
    }];
}

@end

And all you need to do in code, simply initialize API object and call it whenever you need it:

SomeViewController.m

@implementation SomeViewController {
    LoginAPI *_loginAPI;
    // ...
}

- (void)viewDidLoad {
    [super viewDidLoad];

    _loginAPI = [[LoginAPI alloc] init];
    // ...
}

// ...

- (IBAction)signIn:(id)sender {
    [_loginAPI loginWithCredentials:_credentials onSuccess:^(NSArray *objects) {
        // Success Block
    } onError:^(NSError *error) {
        // Error Block
    }];
}

// ...

@end

My code isn't perfect, but it's easy to set once and use for different projects. If it's interesting to anyone, mb I could spend some time and make a universal solution for it somewhere on GitHub and CocoaPods.

Solution 5

To my mind all software architecture is driven by need. If this is for learning or personal purposes, then decide the primary goal and have that drive the architecture. If this is a work for hire, then the business need is paramount. The trick is to not let shiny things distract you from the real needs. I find this hard to do. There are always new shiny things appearing in this business and lots of them are not useful, but you can't always tell that up front. Focus on the need and be willing to abandon bad choices if you can.

For example, I recently did a quick prototype of a photo sharing app for a local business. Since the business need was to do something quick and dirty, the architecture ended up being some iOS code to pop up a camera and some network code attached to a Send Button that uploaded the image to a S3 store and wrote to a SimpleDB domain. The code was trivial and the cost minimal and the client has an scalable photo collection accessible over the web with REST calls. Cheap and dumb, the app had lots of flaws and would lock the UI on occasion, but it would be a waste to do more for a prototype and it allows them to deploy to their staff and generate thousands of test images easily without performance or scalability concerns. Crappy architecture, but it fit the need and cost perfectly.

Another project involved implementing a local secure database which synchronizes with the company system in the background when the network is available. I created a background synchronizer that used RestKit as it seemed to have everything I needed. But I had to write so much custom code for RestKit to deal with idiosyncratic JSON that I could have done it all quicker by writing my own JSON to CoreData transformations. However, the customer wanted to bring this app in house and I felt that RestKit would be similar to the frameworks that they used on other platforms. I waiting to see if that was a good decision.

Again, the issue to me is to focus on the need and let that determine the architecture. I try like hell to avoid using third party packages as they bring costs that only appears after the app has been in the field for a while. I try to avoid making class hierarchies as they rarely pay off. If I can write something in a reasonable period of time instead of adopting a package that doesn't fit perfectly, then I do it. My code is well structured for debugging and appropriately commented, but third party packages rarely are. With that said, I find AF Networking too useful to ignore and well structured, well commented, and maintained and I use it a lot! RestKit covers a lot of common cases, but I feel like I've been in a fight when I use it, and most of the data sources I encounter are full of quirks and issues that are best handled with custom code. In my last few apps I just use the built in JSON converters and write a few utility methods.

One pattern I always use is to get the network calls off the main thread. The last 4-5 apps I've done set up a background timer task using dispatch_source_create that wakes up every so often and does network tasks as needed. You need to do some thread safety work and make sure that UI modifying code gets sent to the main thread. It also helps to do your onboarding/initialization in such a way that the user doesn't feel burdened or delayed. So far this has been working rather well. I suggest looking into these things.

Finally, I think that as we work more and as the OS evolves, we tend to develop better solutions. It has taken me years to get over my belief that I have to follow patterns and designs that other people claim are mandatory. If I am working in a context where that is part of the local religion, ahem, I mean the departmental best engineering practices, then I follow the customs to the letter, that's what they are paying me for. But I rarely find that following older designs and patterns is the optimal solution. I always try to look at the solution through the prism of the business needs and build the architecture to match it and keep things as simple as they can be. When I feel like there isn't enough there, but everything works correctly, then I'm on the right track.

View more solutions

Comments

[Fattie]

For me this is the best and clearest answer, cheers. "It's that simple". @martin, personally we just use NSMutableURLRequest all the time; is there any real reason to use AFNetworking?

[Martin]

AFNetworking is just convenient really. For me success and fail blocks make if worth while as it makes the code easier to manage. I agree that it is total overkill sometimes though.

[Fattie]

A superb point on the blocks, thanks for that. I guess, the specific nature of this will all change with Swift.

[jsadler]

I like a variation on this approach - I use a central API manager which takes care of the mechanics of communicating with the API. However I try to make all of the functionality exposed on my model objects. Models will provide methods like + (void)getAllUsersWithSuccess:(void(^)(NSArray*))success failure:(void(^)(NSError*))failure; and - (void)postWithSuccess:(void(^)(instancetype))success failure:(void(^)(NSError*))failure; which do the necessary preparations and then call through to the API manager.

[Danyal Aytekin]

Would definitely be interested in reading about this approach in more detail in a blog post.

[Kevin]

This approach is straightforward, but as the number of API is growing, it becomes harder to maintain the singleton API manager. And every new added API will relate to the manager, no matter which module this API belongs to. Try using github.com/kevin0571/STNetTaskQueue to manage the API requests.

[Rickye]

Other than the point of why are you advertising your library which is as far as possible from my solution and much more complicated, I've tried this approach on countless projects both small and big ones as mentioned and I've been using it exactly the same ever since I wrote this answer. With clever naming conventions it's not hard at all to maintain.

[darksider]

Hi @alexander thanks for your answer. Are your microservices (CommonServices, UserServices...) static classes, singleton or do you instantiate one each time you need to call a network request?

[Oleksandr Karaberov]

@darksider As I've already wrote in my answer: "` I never use singletons, God APIManagerWhatever class or other wrong stuff, because singleton is an anti-pattern, and in most cases (except rare ones) is a wrong solution.". I don't like singletons. I have an opinion that if you decided to use singletons in your project you should have at least three criteria why you do this (I edited my answer). So I inject them (lazy of course and not each time, but once`) in every controller.

[Luca Torella]

So you have only one instance of APIClient that you are injecting to your services. Since APIClient is not a singleton, is you APIClient instance a property of the AppDelegate or is it passed around overtime you create a new UIViewController?

[Oleksandr Karaberov]

@LucaTorella It is passed implicitly, you can make this explicit with a parametrised over APIClient service classes, or if you ,for some reason, don't want extra copies, or you are sure that you always will use one particular instance (without customisations) of the APIClient - make it a singleton, but DON'T, please DON'T make service classes as singletons.

[Luca Torella]

something like: '''protocol APIClient { ... } // just a protocol so that I can swap the real implementation with one for testing class MyAPIClient: APICLient { ... } // it uses Alamofire let myDefaultAPIClient = MyAPIClient() struct MyService { init(client: APICLient = myDefaultAPIClient) { ... } // default is myDefaultAPIClient func fetchSomething() { ... } } '''

[Denis]

Hi @alexander. Do you have any example projects on GitHub? You describe very interesting approach. Thanks. But I'm a beginner in Objective-C development. And for me is difficult to understand some aspects. Maybe you can upload some test project on GitHub and give a link?

[meteors]

Hello @AlexanderKaraberov, I'm bit confused regarding the Store explanation you gave. Suppose I have 5 models, for each I have 2 classes, one which maintains networking and other caching of objects. Now should I have separate Store class for each model which call function of networking and cache class or a single Store class which has all function for each model, so the controller always access single file for data.

[João Nunes]

With Swift I replaced your Libraries with: 1. ObjectMapper 2. PromiseKit .

[Balazs Nemeth]

Started to like this architecture a few month ago, thanks Alex for sharing it! I would like to try it with RxSwift in the near future!

[Yetispapa]

Can someone explain me where the communication to the repository happen. Does the controller call methods like update, remove etc.. on it or does the service has a reference to a repository?

[Oleksandr Karaberov]

@StephanHofmann I edited my answer. Repository is a layer between service (business logic) and model (Core Data, etc.). Service is a dispatcher between UI (view models, controller), model and repositories. But this is actual if your app's architecture is really complex. Don't do overengineering.

[GeRyCh]

" Now our APIClient provider will be a value type (enum) with extensions conforming to protocols and leveraging destructuring pattern matching." Can anybody explain which enum cases it will include? As I understood from explanation of using Moya library, every micro service has to be enum itself, then it passed to MoyaProvider. Thank you

[Admin]

@icodebuster this demo project has been helping me understand many of the concepts outlined here: github.com/darthpelo/NetworkLayerExample

[hariszaman]

Hello, I have a question that if view controller injects a service with DI injects the service class it needs. But then that service has to maintain a global state what should be done in that case?