Modern iOS Network Architecture: Leveraging HTTP/2 and NSURLSession

Introduction

HTTP/2, the first major update to the HTTP protocol since its release, was approved on February 17, 2015 and brings performance‑boosting techniques such as multiplexed connections and header compression. Apple announced support for HTTP/2 in iOS 9 at WWDC 2015.

Network Layer Design Principles

Architecture must be driven by business needs and remain extensible for future changes. Two main API design styles are presented:

Centralized API Design

A single or few functions encapsulate common network calls, e.g.:

+ (void)networkTransferWithURLString:(NSString *)urlString
   andParameters:(NSDictionary *)parameters
   isPOST:(BOOL)isPost
   transferType:(NETWORK_TRANSFER_TYPE)transferType
   andSuccessHandler:(void (^)(id responseObject))successHandler
   andFailureHandler:(void (^)(NSError *error))failureHandler { /* AFNetworking wrapper */ }

Distributed API Design

Each API is represented by its own subclass of a base API class, allowing per‑API configuration and custom RPC handling.

Choosing NSURLSession

Since HTTP/2 is only available through NSURLSession, NSURLConnection must be deprecated. AFNetworking 3.0 already provides an NSURLSession‑based implementation, making migration straightforward.

Implementation Details

Base API and RPC Protocol

A generic DRDBaseAPI defines request/response serializer types, request method, and lifecycle methods ( start, cancel). An DRDRPCProtocol abstracts request URL, parameters, and response reforming, enabling both RESTful and JSON‑RPC styles.

@protocol DRDRPCProtocol <NSObject>
- (nullable NSString *)rpcRequestUrlWithAPI:(DRDBaseAPI *)api;
- (nullable id)rpcRequestParamsWithAPI:(DRDBaseAPI *)api;
- (nullable id)rpcResponseObjReformer:(id)responseObject withAPI:(DRDBaseAPI *)api;
- (nullable id)rpcResultWithFormattedResponse:(id)formattedResponseObj withAPI:(DRDBaseAPI *)api;
- (NSError *)rpcErrorWithFormattedResponse:(id)formattedResponseObj withAPI:(DRDBaseAPI *)api;
@end

Configuration and Session Management

All configured API instances are handed to a shared APIManager that owns a single NSURLSession, allowing connection reuse and controlled concurrency. Switching the underlying networking library later requires no changes to the API layer.

Data Input, Callback, and Conversion

Input is either a centralized function call or a distributed API object. Callbacks can be implemented via Notification, Delegate, or Block; the author prefers Block + Notification for most cases. Data conversion is left to the upper layer via a customizable apiResponseObjReformer block.

- (nullable id)apiResponseObjReformer:(id)responseObject andError:(NSError * _Nullable)error;

Security Considerations

HTTPS is the baseline security measure. For stronger protection against man‑in‑the‑middle attacks, SSL pinning is applied using AFNetworking’s security policy:

Instantiate a DRDSecurityPolicy and set DRDSSLPinningMode to PublicKey or Certificate.

Assign the policy to the API’s apiSecurityPolicy.

Include the server’s public‑key certificate in the app bundle.

Batch Requests

A DRDAPIBatchAPIRequests class aggregates multiple DRDBaseAPI objects, starts them concurrently using a dispatch_group, and notifies a delegate when all finish.

@interface DRDAPIBatchAPIRequests : NSObject
@property (nonatomic, strong, readonly, nullable) NSMutableSet *apiRequestsSet;
- (void)addAPIRequest:(nonnull DRDBaseAPI *)api;
- (void)start;
@end

Conclusion

Adopting HTTP/2 on iOS requires moving to NSURLSession, redesigning the network layer for extensibility, and handling security with SSL pinning. The presented architecture balances centralized convenience with distributed flexibility, supports various data handling patterns, and includes a batch request solution.