# Architecting an iOS networking layer: Part 1

DevFeed: [Architecting an iOS networking layer: Part 1](<https://devfeed.tech/articles/architecting-an-ios-networking-layer-part-1-24561.md>)

Original publisher: [Read original article](<https://medium.com/bleeding-edge/architecting-an-ios-networking-layer-part-1-f2ad8417a6ce?source=rss----d8ebe85cdc0f---4>)

Author: Martin Höller

Published: 2019-04-01T10:01:29Z

Content type: tutorial

Language: en

Sources: [Bleeding Edge - Medium](<https://devfeed.tech/sources/bleeding-edge-medium.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Mocking](<https://devfeed.tech/topics/mocking.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [App](<https://devfeed.tech/topics/app.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backend](<https://devfeed.tech/tags/backend.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [decoupling](<https://devfeed.tech/tags/decoupling.md>), [interface](<https://devfeed.tech/tags/interface.md>), [ios](<https://devfeed.tech/tags/ios.md>), [mocking](<https://devfeed.tech/tags/mocking.md>), [networking](<https://devfeed.tech/tags/networking.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [swift](<https://devfeed.tech/tags/swift.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

This tutorial explains how Clue redesigned its iOS app's networking layer from a singleton-based implementation into a more modular architecture. It describes the limitations of the old design and introduces HTTPClient, protocols, request classes, separation of concerns, and improved testability.

## Source excerpt

Cleaner and more modular building blocksIllustration by Marta Pucci In this two part series, we will go through the networking layer we use in our iOS app at Clue. Part 1 covers how we moved our networking layer to a cleaner more modular architecture 🤓 Part 2 includes a demo project on how we use it to make our network requests 🥳 Let's get started! Our iOS app makes use of a third-party library to handle the finer details of the networking requests to our server. Our interface to this library used to be a singleton class, through which all our service calls would be executed and handled. Whilst this worked and was "okay" for one or two service calls, it very quickly got out of control as our app grew and we needed something better! Let's see why this old implementation was so limiting and what we wanted to achieve with the new architecture. Limitations of the old implementation The singleton class had too many responsibilities. It needed to construct each service call with the endpoint, body and parameters as well as handle the success and failure of each call. It lacked separation of concerns between the networking and the business logic layer. It lacked testability as it required mocking of the backend and extensive test case setups. It was tightly coupled with a third party library, making it harder to replace if needed. Goals of the new architecture Move away from the singleton class anti-pattern. Instead of having a singleton class for all the requests, each request is a class of its own and builds up its networking stack. Improved testability. Increased decoupling between the networking and the business layer by separating the response handling from the network requests implementation. Easy to use interface to create a network request. Let's now go through the main building blocks of the new architecture. HTTPClient The HTTPClient class is responsible for performing the actual network request and conforms to the HTTPClientProviding protocol. We abstract this i