In essence, it all comes down to one word: flexibility. So, Protocol Conformance or Mapping Functions? Well, as you'll soon discover.

**TDLR; It depends...😉

Imagine you have a set of custom data types representing different types of products in an e-commerce application. Each product type has its own set of properties and behaviors specific to that product. Here's a simplified example of two product types:

struct Book {
    let title: String
    let author: String
    let price: Double
    // Other book-specific properties and methods
}

struct Electronics {
    let name: String
    let brand: String
    let price: Double
    // Other electronics-specific properties and methods
}

Now, you want to display a list of these products in the same UITableView , UICollectionView or a SwiftUI list, and you also want to allow users to add these products to their shopping cart. How would you go about achieving this?

Protocol Conformance

"A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol." - The Swift Programming Language

To go about this using protocol conformance one would first start by defining a protocol. Let's call it ProductConvertible.

protocol ProductConvertible {
    var title: String { get }
    var price: Double { get }
}

Then, you would have your Book and Electronics types conform to this protocol:

struct Book: ProductConvertible {
    let title: String
    let author: String
    let price: Double
}

struct Electronics: ProductConvertible {
    let name: String
    let brand: String
    let price: Double
}

You can then go ahead and create a ViewModel for the view that will display the products or use ProductConvertible directly.

Pros

Polymorphism - When you have a protocol like ProductConvertible, you establish a shared contract that multiple types can conform to. This allows you to treat all conforming types uniformly, providing a consistent interface for working with different data models. In the case of a list or UITableView, you can use a single data source or delegate to handle various model types effortlessly.

let products: [ProductConvertible] = [book, electronics]

Code Reusability - You can create generic functions and components that work with any type conforming to the protocol.

func displayProducts(_ products: [ProductConvertible])

Ease of Extension - When new types need to be displayed in the list or UITableView, you can simply make them conform to the existing protocol.

struct Clothing: ProductConvertible {
    let name: String
    let brand: String
    let price: Double
}

Cons

Tight Coupling - Types conforming to a protocol become tightly coupled to the protocol's requirements. Any changes to the protocol can potentially affect all conforming types.

Shared Protocol Requirements - When using protocol conformance, you need to ensure that the protocol requirements make sense for all conforming types. If some requirements are irrelevant for certain types, you may end up with unused methods or properties in your types. This can lead to unnecessary complexity. Our clean architecture coders out there will recognize this as a violation of the interface-segregation principle.

Mapping Functions

Data mapping is the process of matching fields between two different data sets. It is a crucial step when combining data, since different data sources could have different styles, formatting, or names for the same kinds of data. - Sean Dougherty

In simple terms, a mapping function is a pure function that takes one type of data (the source) and converts it into another type of data (the target). Mapping functions are characterized by their functional purity, which means they produce the same output for the same input and have no side effects. (func(A) -> B)

Pros

Modularization - Using mapping functions, you can encapsulate the transformation logic in separate functions or a dedicated mapper class, promoting modularization and clean code.

Let's add a ProductViewModel that can be used to display items in our list.

struct ProductViewModel {
    let title: String
    let description: String
    let price: String
}

We can then introduce a ProductMapper which can be used to transform/map our initial model items to the desired ProductViewModel.

enum ProductMapper {
    static func mapBookToViewModel(_ book: Book) -> ProductViewModel {
        return ProductViewModel(
            title: book.title,
            description: "Author: \(book.author)",
            price: "$\(book.price)"
        )
    }

    static func mapElectronicsToViewModel(_ electronics: Electronics) -> ProductViewModel {
        return ProductViewModel(
            title: electronics.name,
            description: "Brand: \(electronics.brand)",
            price: "$\(electronics.price)"
        )
    }
}

Now our mapping logic is encapsulated in a separate object with separate functions that can live in isolation.

Testing - Mapping functions can be easily unit-tested to ensure they correctly transform data from one type to another. This can be challenging with protocol conformance, especially if the protocol involves complex behavior. It is good practice to make mapping functions static.

Code Reusability - Mapping functions can be reused across different parts of your application. For example, you might need to convert your custom types to different standardized representations for different use cases. A single mapping function can serve multiple purposes. This is not possible when using protocol conformance as you can only have one conformance to a protocol.

struct BookMapper {
    static func mapBookToViewModel(_ book: Book) -> ProductViewModel {
        ProductViewModel(
            title: book.title,
            author: book.author,
            price: "$\(book.price)"
        )
    }

    static func mapDiscountedBookToViewModel(_ book: Book,
                                             discountPercentage: Double) -> ProductViewModel {
        let discountedPrice = book.price * (1.0 - discountPercentage / 100.0)
        return ProductViewModel(
            title: book.title,
            author: book.author,
            price: "$\(discountedPrice)"
        )
    }
}

We now have two different conversions on the same model but our mapping functions give us extra functionality.

Flexibility - If you introduce a new type, such as Clothing, you can easily create a new mapping function without modifying existing code.

struct Clothing { /* ... */ }

static func mapClothingToViewModel(_ clothing: Clothing) -> ProductViewModel {
    // Transformation logic here
}

Performance - In some cases, mapping functions can be more performant than protocol conformance, especially if the mapping involves complex calculations or data manipulation. You have more control over when and how the mapping occurs.

Let's say we need to perform complex calculations when mapping our models we can use caching and memoization to store the results of specific inputs and prevent unnecessary recalculations. We could also perform these operations over multiple threads in parallel.

This is not possible with protocol conformance as in Swift, when objects conform to a protocol, the conformance often involves an eager transformation. This means that the transformation logic specified in the protocol's methods is executed when the object is created or when the protocol methods are invoked.

For more on the performance of protocol conformance...

Loose Coupling - When you use a mapping function, the mapping logic is external to your types. Changes to your types won't directly impact the mapping function, and vice versa. However, if you introduce a new type that needs to be mapped to the target representation (ProductCellViewModel ), you will need to create a new mapping function for that type. While this does couple the mapping function to the new type, it doesn't necessarily affect the existing types.

In both cases, there is a level of coupling, but the key difference is where that coupling occurs:

• With protocol conformance, the coupling is within the types themselves. Changes to the protocol can affect all conforming types.

• With a mapping function, the coupling occurs when you create a new mapping function for a specific type. Existing types don't need to change when a new type is introduced.

Cons

Mapping Calls - You need to explicitly call the mapping functions when populating the list, which can lead to additional code for type checks and mappings.

let productViewModel: ProductViewModel
if let book = product as? Book {
    productViewModel = ProductMapper.mapBookToViewModel(book)
} else if let electronics = product as? Electronics {
    productViewModel = ProductMapper.mapElectronicsToViewModel(electronics)
}

Boilerplate Code - Mapping functions can introduce unnecessary boilerplate code, especially in the case of simple one-to-one mappings. In such cases, protocol conformance would be better suited. Could also be seen as an unneeded abstraction layer by some.

Code Duplication - This can lead to code duplication if similar mapping logic is implemented in multiple places. This can make it harder to maintain consistency and make updates.

Conclusion

It's essential to carefully assess your specific project requirements and consider the trade-offs when deciding whether to use mapping functions or other approaches like protocol conformance or direct property mapping. Mapping functions can be a powerful tool for complex data transformations, but they should be used with good judgment to avoid introducing unnecessary complexity into your codebase.

Next time...

Now that we've examined various methods of data transformation, a new challenge emerges. Consider this scenario: You want to trigger different actions when an item in our list is tapped. Have you ever grappled with the casting pyramid of doom?

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    let selectedProduct = products[indexPath.row]
    if let book = selectedProduct as? Book {
        // Perform action for Book
        performActionForBook(book)
    } else if let electronics = selectedProduct as? Electronics {
        // Perform action for Electronics
        performActionForElectronics(electronics)
    }
}

But what happens when we introduce more types? Do we simply keep adding more if let statements? There must be a more elegant solution. That's precisely what we'll delve into in our next post!

Thank you for reading. If you found this article insightful, please consider leaving a like and sharing it. 👏🏾🚀

This is a highly opinionated piece and I am very aware that some might have opposing opinions hence - hot take.

Hot Take (noun) - a piece of writing or speech, especially on the internet, giving someone's personal opinions about a topic, usually strong opinions that have not been carefully thought about and that many people are likely to disagree with Cambridge Dictionary

Let's talk about cross-platform development

Have you ever downloaded an app, opened it, browsed through it, and think something just does not feel right? Ever wondered why an app is not smooth and why some elements seem out of place? It could be that the app in question was developed using a cross-platform framework.

The promise of cross-platform development is "code once, deploy everywhere". Whilst frameworks like React-Native and Flutter do really well to deliver on this promise there are some caveats that raise concern. User Interface and latest platform features is an area in which I feel like these frameworks fall short. In practice, this may not be the fault of the framework but rather that of the engineer not taking the time to ensure that the final result conforms to specific platform standards.

To make a good cross-platform application one has to be conscious of platform differences and cater to them. iOS has its Human Interface Guidelines and Android has Material Design. For your app to feel at home on a device it is crucial that you adhere to the platform principles.

This leads to one have to write code for each platform somewhat creating a nuisance in the development process. "I was promised write once, deploy everywhere. But to make it look nice and work properly I still have to code twice?" Eventually, you could end up in the not ideal situation of having a codebase that has so many if or switch statements to cater for platform-specific code.

Kotlin Multiplatform Mobile - What is it?

Kotlin Multiplatform Mobile allows you to use a single codebase for the business logic of iOS and Android apps. You only need to write platform-specific code where it’s necessary, for example, to implement a native UI or when working with platform-specific APIs. - Kotlin.org

KMM is a relatively new framework (Alpha released Aug. 2020) to the cross-platform world that enables you to share common code between your Android and iOS Applications. This is done by creating a shared module written in Kotlin that is then compiled to bytecode and native iOS.

Unlike other cross-platform frameworks, KMM gives you the choice to decide what aspects of your code you want to share. You can decide to share as little code as possible or do the opposite. The shared code module can be included in existing projects using Cocoapods and SPM.

KMM does not currently have a UI component this allows you to keep your UI native. No need to learn a new language for UI. You also get the benefit of being able to use all the latest platform features like SwiftUI and JetPack Compose.

I must say that I have been thoroughly impressed with the documentation and resources the JetBrains team has been creating for KMM. Take a look at the Youtube Channel and the official documentation for yourself. ⭐️

My Key takeaways

• Flexibility, only share the code you want to share.
• Compiled to bytecode, does not increase binary size like other cross-platform frameworks.
• Native UI, you can use UIKit and SwiftUI.

Common iOS Engineer questions

1. Do I have to learn Kotlin?

Yes. To contribute to the shared code module you will have to learn some Kotlin. This might be a big learning curve but most of the things we as iOS Engineers love about Swift are also true for Kotlin. Type-safety, optionals, and clean syntax are all present in Kotlin.

2. Will I have to code in Android Studio?

Yes. No. Probably. To be a contributor on the app's shared code you will probably have to use Android studio but for all other native code, you can still use Xcode.

3. How will I debug Kotlin code?

With Android Studio.

4. Libraries, Cocoapods, and Swift Packages?

You can use libraries, Cocoapods, and packages as normal in your iOS project.

5. How does KMM handle concurrency?

Using Kotlin/Native. Please read this post from JetBrains on Kotlin/Native Memory Management Roadmap for a more detailed explanation.

More questions? See the Frequently Asked Questions page on Kotlin.org

The Cons

Now let's be honest there is no such thing as a silver bullet for cross-platform development. Let's take a look at the cons:

1. No shared UI

While some may see this as a con I on the other hand see it like a pro. I don't want to have a shared UI. I would rather have two targets one in SwiftUI and the other in Jetpack Compose. KMM does not currently provide a way to have shared UI components. I hope they keep it this way so that apps can maintain their native feel. If you do want to have shared UI components then ReactNative or Flutter is best suited.

2. Production readiness

KMM is a fairly new player to the cross-platform world and is still considered to be in development. Some features are still in the alpha/experimental phase of development. I don't think that this is cause for alarm to not use it. There are teams from Netflix and CashApp already using KMM in production. The development team is very good at communicating the stability of components and there's a dedicated page for this.

3. New build tools

As an iOS developer, I have become accustomed to Xcode and its quirks like having to clear derived data religiously. Having to learn how to use Android Studio and Gradle will be a major hurdle. Shared code needs to be debugged in Android Studio. For an iOS Engineer, you will now need two IDEs to develop whilst Android Engineers can achieve everything from Android Studio. I think the new tools will be the biggest challenge for an iOS developer.

4. Networking

While there is support for networking using the Ktor library development for networking with GraphQL is still in the experimental phase. I could not find any solutions for networking with gRPC. These limitations write off KMM for teams that use these technologies.

4. Complexity

Introducing KMM or any cross-platform framework introduces complexity to app development. There are more aspects involved in the development life cycle. KMM is still in its infancy there will definitely be some pains experienced. With the community still being small there might not be enough resources online to help resolve some of the issues one might run into.

With that said if introducing KMM to a team that already has experienced Android Engineers, I'm sure the learning curve will be accelerated as they can assist you with any errors you may encounter with Android studio or Gradle.

I know the chances of this happening are close to impossible but it would be really awesome if Xcode had a KMM plugin.

There are some other downsides to using KMM for app development but in the spirit of keeping this post short and concise, we won't discuss them. I have included a list of resources that go into detail about some of the other cons like ObjC-interoperability, memory handling, and multi-threading below.

An argument for shared code

Scenario: You work on a team with dedicated iOS and Android teams. You're working on a new feature. The feature's business logic is designed and ready for development. Both teams go their separate ways and code the feature. Time for testing comes and QA reports that the feature works fine on Android but there is something wrong on iOS or vice-versa.

This is a situation many have been in. Having a shared codebase may be the solution to the situation above. Having a single source of truth for an application's business logic introduces predictability and stability.

Conclusion

My favorite aspect about Kotlin Multiplatform Mobile is its flexibility. You only have to share what you decide to share. Rather than UI components being bridged, they remain native. Code is compiled to bytecode.

These reasons are why I think KMM should be welcomed by the iOS community. It creates an environment for collaboration between communities and introduces the challenge of learning a new language and tools. 🤖 🤝🍏

I develop to solve problems that help people. The people that download our apps usually don't care about the technology used to make the app. What users want are good products and if KMM provides teams a way to deliver earlier then it's a win. 🚀

I'm looking forward to all the new features in KMM and the growth of this community. Thanks for reading my hot take on why I as an iOS Engineer like KMM! What's your opinion on Kotlin Multiplatform Mobile?

Resources

1. Kotlin Multiplatform Documentation
2. The Dos and Dont's of Mobile Development with Kotlin Multiplatform
3. Kotlin Multiplatform – A remedy for all mobile app development?
4. Kotlin Multiplatform — A panacea for mobile app development?
5. We asked an iOS developer his thoughts after working with Kotlin/Multiplatform Mobile

A little about me: I'm an iOS engineer in Cape Town, South Africa 🏝👋🏾. I have been developing iOS applications for over 5 years now in FinTech and E-commerce. I love building products that impact people's lives and I think in Swift ⚡️😉.

My aim to make this an annual inclusion on my blog. This list will summarize my learnings each year and a way to share new things. It will be interesting to see how this list changes from year to year.

iOS Development in 2021

It is a very exciting time to be an iOS developer. #WWDC21 & #WWDC20 were full of so many new and interesting things which we can now use to build applications. Whilst some can not be used immediately due to lack of backward compatibility with iOS versions I see this as an opportunity to learn. Between now and the time your team is ready to drop support for previous iOS versions you can use the time to learn things like SwiftUI, Combine, and async-await.

Since most of the apps I work on can't use some of these latest features Apple has released you will not see them included in the list.

TL;DR (Too long; didn't read)

• Fastlane
• GitHub
• CI / CD - GitHub Actions
• SwiftLint
• SwiftGen
• RxSwift
• MVVM
• UIKit
• Quick & Nimble
• Blogs
• YouTube

Dev Tools

These are the tools that I make use of for CI (Continuous Integration) & CD (Continuous Delivery)

• Xcode

It's close to impossible if not impossible to be an iOS Developer and not use Xcode. Our beloved IDE has improved drastically over the years. The team at Apple has released many awesome features to make our lives as developers easier. Personally, I really love the source control integrations and can't wait to try out Xcode Cloud.

• Fastlane

I use Fastlane to automate everything! Releases, release notes, changelogs, TestFlight and AppStore builds are amongst some of the things that I automate with Fastlane.

• GitHub

Not only do I use Github for source control but also have recently started using GitHub Actions for CI/CD. Having my code and CI/CD in one location is a major win for me 💯.

Code Tools

• SwiftLint & SwiftGen

Every iOS project in my opinion should have these tools set up. SwiftLint ensures that code style and syntax are adhered to and consistent. SwiftGen generates code for all your resources to make them type-safe. All iOS Developers love type-safety and clean code ❤️.

• Swift Package Manager & CocoaPods

I have started moving libraries from CocoaPods and using SPM for dependency management as more libraries add support for it.

Architecture

The topic of architecture and design patterns will always be a hot topic for the iOS community. I would like to believe I have found an architecture that works for me. This section could possibly be a series of posts on its own.

• MVVM (Model-View-ViewModel)
• RxSwift
• Coordinator pattern
• SQLite for persistence
• gRPC
• Quick & Nimble for unit tests

I am very fond of the MVVM pattern. It does not have too much boilerplate code which makes it clear to understand and is testable. In tandem with MVVM I like to use RxSwift for binding properties to views. Apple has endorsed Function Reactive Programming with Combine. I look forward to when I can replace RxSwift with Combine in the future.

I have included gRPC even though this is usually dependent on the backend. Working with gRPC is such a delight. I don't know why more teams do not use gRPC. It is lightweight, type-safe, and has built-in code generation for most languages. You can read more here.

#UI

I won't go too much into detail here but will include links to resources that discuss the topics listed. Leave a comment if you'd like me to write on any of the topics more in detail and discuss my specific implementations.

• Styleable views

• Composable & Reusable protocols

• StackViews

• ScrollStackViewControllers

• Compositional Layout

• DiffableDatasource

• KingFisher

I have to mention these two libraries DiffableDataSource & KingFisher 🌟. DiffableDataSource is a backport of Apple's diffable data source available to use from iOS 9 and above. So you can use compositional layouts and diffable data sources without dropping support for previous iOS versions.

KingFisher is the image cache king. If your app downloads images take a look at this library. It adds support for caching, loading states, placeholder images, and other image rendering-related features.

Knowledge Base

It's important to always keep abreast with the latest technology and keep improving your skills. Below is a list of resources that I use to achieve this.

Community

• Github
• Twitter
• Colleagues
• Stackoverflow

The iOS developer community is such an awesome community. There are so many people freely sharing their knowledge with others. Over the years I have learned so much from this community.

How to best utilize the community:

1. Be active! create a Twitter profile, follow other iOS developers, attend iOS Dev Happy hour.
2. Read docs, read code on Github, find public repos, try to understand the code.
3. Use Stackoverflow, don't just copy-paste, understand then copy-paste.
4. Learn from your colleagues and your seniors. Don't be afraid to ask questions and challenge the status quo.

Blogs

• SwiftBySundell
• Hacking with Swift
• SwiftWithMajid
• Swift Discovery by Khoa
• SwiftLee
• Lickability
• FiveStars
• Vadim Bulavin
• Medium
• Hashnode

YouTube

• TundsDev
• KavSoft
• Peter Friese

Books

• Donny Wals
• Swiftjectivec
• Raywenderlich

NewsLetters

• Infinum iOS Cocoa Treats
• iOSGoodies

"Be the senior engineer you needed as a junior." - Anon

Thank you for reading my post, leave a comment with tools that you love ✌🏾. Keep thinking in Swift ⚡️!

Pre-requisites

• Xcode 11
• Basic understanding of Swift & Networking

API Design

Things I like to keep in mind when designing an API are syntax and style. Syntax defines whether the API is declarative (which defines the computational logic i.e the "what") or imperative (defines state changes i.e the "how") whereas style defines whether the design paradigm is concrete or abstracted with generics and protocols.

The goal of this network layer is to design an API that is easy to use whilst being powerful and easily customizable. To achieve this we need to set some requirements for the framework:

• Generic
• Typesafe
• Declarative
• Single source of truth
• Abstracts implementation details

With the requirements set out what I usually do is dive straight in Xcode and try to imagine what using this framework would look like.

To start we’ll create a new Xcode project and add the following line to ViewController.swift.

let publisher = client.request([User].self, from: .users)

With the line above we have set a clear goal for what we aim to achieve. One thing I love the most about Swift is the language "readability". When designing an API I aim to have it read like a normal English sentence.

Reading the above line of code: "Client request list of User from users”.

Not exactly everyday language but it’s close enough to give an idea of what that line of code does without any prior knowledge of the implementation.

Let’s break down our initial line of code even further and look at each component

• publisher: hints to the use some publisher-subscriber pattern
• client: is able to perform requests
• User: is some model representing a user
• .users: is some enum encapsulating a resource from which Users can be requested

The client is requesting a list of type User from users and the response will be published to the publisher.

Right now Xcode should be throwing a couple of errors. Xcode is unable to resolve what the client and User are. The next task is to get rid of the errors we currently have and make Xcode happy. This approach to development lends itself well to TDD (Test Driven Development). Whilst we won’t be writing unit tests in this section we will be following a similar pattern of RED, GREEN, REFACTOR found in TDD. I like to call this approach something more sinister like “Error Driven Development” 😅.

Code

Folder Structure

User

For part one, we will be making use of the JSON Placeholder API. If you go to https://jsonplaceholder.typicode.com/users in your browser you will see a JSON response containing an array of users. Our User model will be a representation of this response. Add the code below to a file of your liking Network.swift or ViewController.swift.

• One error down, on to the next one 👉

struct User: Decodable {
    let id: Int
    let name: String
    let username: String
    let email: String 
}

Client

The next error we have to address is the unresolved identifier client. In Client.swift add the following code

final class Client { }

Now where you declared your publisher above go ahead and create a new instance of Client.

let client = Client()

At this point, you should have the following error in Xcode:

In understandable English, the first error thrown here is telling us that Xcode is unable to infer what we mean by .users.

The second error is easier to understand, there is no method named request on the client.

Let’s address the easier of the two errors by declaring our request method on the client.

ClientType

In Client.swift add the following protocol and implementation:

import Combine
import Foundation

protocol HTTPClient {
    associatedtype Route: RouteProvider
    func request<T: Decodable>(_ model: T.Type,
                               from route: Route,
                               urlSession: URLSession) -> AnyPublisher<HTTPResponse<T>, HTTPError>
}

final class Client<Route: RouteProvider>: HTTPClient {

    func request<T>(_ model: T.Type,
                    from route: Route,
                    urlSession: URLSession = .shared) -> AnyPublisher<HTTPResponse<T>, HTTPError> {
        fatalError("Not implemented yet")
    }

}

We declare a HTTPClient protocol which will serve as the blueprint for our client. First, we provide the protocol with an associatedtype of RouteProvider.

… An associated type gives a placeholder name to a type that is used as part of the protocol. The actual type to use for that associated type isn’t specified until the protocol is adopted. Associated types are specified with the associatedtype keyword.

Declare the request function which takes in a model parameter that will represent the response object we want to decode from the request. The route parameter will represent the HTTP route to fetch the expected response object. The last argument is the URLSession which will allow us to pass in a URLSession to use with the request. The function returns a publisher with a generic HTTPResponse on our model object and an HTTPError.

Create the Client class which will implement the HTTPClient protocol. For now, we will leave the implementation empty. I’ve added a fatalError message to ensure that we get back to it. In the code above we made RouteProvider, HTTPResponse, and HTTPError which are types we will declare next.

RouteProvider

This is what I would call the star of the show. RouteProvider defines a protocol for which we can build requests. By using a protocol we can give flexibility to how requests are formed. We can decide to implement the RouteProvider with a class, struct, or enum. I’ve decided to go with the enum approach. This provides users with a single source of truth. We know every time that a request is made to a specific endpoint it will be built using the same parameters.

protocol RouteProvider {
    var baseURL: URL { get }
    var path: String { get }
    var method: HTTPMethod { get }
    var headers: [String: String] { get }
}

PlaceHolderRoute

Declare a Route which will implement the RouteProvider protocol. I’ve made use of the JSONPlaceholder API and added a single case to get users to demonstrate.

enum PlaceHolderRoute {
    case users
}

extension PlaceHolderRoute: RouteProvider {
    var baseURL: URL {
        guard let url = URL(string: "https://jsonplaceholder.typicode.com") else {
            fatalError("Base URL could not be configured.")
        }
        return url
    }

    var path: String {
        switch self {
        case .users: return "/users"
        }
    }

    var method: HTTPMethod {
        switch self {
        case .users: return .get(nil)
        }
    }

    var headers: [String : String] {
        return [:]
    }
}

HTTPMethod

The HTTPMethod enum will be used to state which HTTP method to use for the request. We will only be supporting the most common HTTP method types in our framework. The HTTP spec does not limit the number of HTTP method types, in fact, there are other spec implementations that use methods like “COPY” and “LOCK” but you don’t come across such often.

enum HTTPMethod {
    case get([String: String]? = nil)
    case put(HTTPContentType)
    case post(HTTPContentType)
    case patch(HTTPContentType)
    case delete

    public var rawValue: String {
        switch self {
        case .get: return "GET"
        case .put: return "PUT"
        case .post: return "POST"
        case .patch: return "PATCH"
        case .delete: return "DELETE"
        }
    }
}

We once again make use of associated values in our enums to enable us to pass in values to the HTTPMethod.

The GET case will enable us to pass in URL query parameters with our request. We can construct use .get(["page": 2]) to construct a URL like: http://api.test.com/content?page=2

For PUT, POST and, PATCH we make use of HTTPContentType. This type will enable us to post encoded JSON or even an encoded dictionary in the body of the request.

HTTPContentType

enum HTTPContentType {
    case json(Encodable?)
    case urlEncoded(EncodableDictionary)

    var headerValue: String {
        switch self {
        case .json: return "application/json"
        case .urlEncoded: return "application/x-www-form-urlencoded"
        }
    }
}

By setting the headerValue here we can tightly couple the expected header to the type being sent. This will ensure that we always send the right headers.

EncodableDictionary

This protocol URL encodes Dictionary keys and values and returns them as Data. Input: [“Name”: “Malcolm K”, “Emoji”: “🍩”]
Output: Name=Malcolm%20K&Emoji=%F0%9F%8D%A9 (string representation of data)

protocol EncodableDictionary {
    var asURLEncodedString: String? { get }
    var asURLEncodedData: Data? { get }
}

extension Dictionary: EncodableDictionary {

    var asURLEncodedString: String? {
        var pairs: [String] = []
        for (key, value) in self {
            pairs.append("\(key)=\(value)")
        }
        return pairs
            .joined(separator: "&")
            .addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)
    }

    var asURLEncodedData: Data? { asURLEncodedString?.data(using: .utf8) }
}

HTTPError

When communicating with a server via internet errors are expected. Errors can happen due to poor internet connectivity or the server is down. We need a way to handle these errors gracefully. Create and HTTPError struct with a nested Code enum with all the errors you wish to handle.

HTTPURLResponse provides us with an error message given a status code. We will leverage this functionality to display an appropriate message.

print(HTTPURLResponse.localizedString(forStatusCode: 400)) // prints “bad request”

We can decide to either make use of the system provided message or use the Code enum to provide a custom error message as seen below.

struct HTTPError: Error {
    private enum Code: Int {
        case unknown                        = -1
        case networkUnreachable             = 0
        case unableToParseResponse          = 1
        case badRequest                     = 400
        case internalServerError            = 500
    }

    let route: RouteProvider?
    let response: HTTPURLResponse?
    let error: Error?

    var message: String {
        switch Code(rawValue: response?.statusCode ?? -1) {
        case .unknown:
            return "Something went wrong"
        case .networkUnreachable:
            return "Please check your internet connectivity"
        default:
            return systemMessage
        }
    }

    private var systemMessage: String {
        HTTPURLResponse.localizedString(forStatusCode: response?.statusCode ?? 0)
    }

}

Here we store a few properties: code, route, response and, error. This gives us flexibility as to how to handle the error. We can decide to show a toast with a message in the response. If needed we can retry the request as we have the route. We can also log an error to a logger or analytics service.

HTTPResponse

Finally, we have HTTPResponse which is a generic type constrained to Decodable. We constrain to Decodable as we expect JSON back from the server which we will decode to a model object.

struct HTTPResponse<T: Decodable> {
    let route: RouteProvider
    let response: HTTPURLResponse?
    let data: Data?

    var decoded: T? {
        guard let data = data else { return nil }
        return try? JSONDecoder().decode(T.self, from: data)
    }
}

Conclusion

That brings us to the end of part one! Our goal was to design a generic, typesafe and, declarative API for our networking library. We started with this line of code giving us some errors.

let publisher = client.request([User].self, from: .users)

No more errors. 👍 Well done on getting this far! 🥳 But, wait when we build and run nothing is happening yet? 🤔

See you in part two where we will start building our URLRequests using Combine and handle server responses!

Thanks to Mpendulo Ndlovu for his editorial work on this post.

Resources

• Swift Enum Documentation
• HTTP in Swift by Dave DeLong
• URLs in Swift by Antoine van der Lee
• Why Swift enums with associated values can’t have a rawValue by Mischa Hildebrand

In this series, we will be covering how we can code our own declarative protocol-orientated networking layer using our beloved Swift.

Knowing how to communicate with a server and present the response data to a user is a vital skill every iOS developer should have. Over the years Apple has made enhancements to URLSession that make our lives as developers easier which have eradicated the need for third-party dependencies for trivial tasks.

Why? 🤷🏼‍♀️

So why would one write their own network layer when there are already so many good networking libraries out there?

Because it is time to break up with that networking library in favor of your own custom-built network layer 😎. It's time to understand what "magic" that library does, remove unnecessary dependencies from your project, gain full control, and level up your skills.

In 2018 I wrote my first Network Layer blog post - Writing a Network Layer in Swift: Protocol-Oriented Approach. The post garnered a lot of engagement from the community so I feel like it's time for an update. While my previous post covers some key concepts that are still relevant today, a lot has changed in Swift since 2018. Result has been added to the standard library, Enums can now have default associated values 😁, and with iOS 13 Apple gave us Combine which enables us to use functional reactive programming.

Topics 📝

The series will be covering some key concepts of networking in Swift. Some of the topics we will be covering are listed below:

1. Designing the API 🤓
2. Building requests with Combine 🧬
3. Authentication 👮🏽‍♀️
4. Download Tasks 👇
5. Upload Tasks ☝️
6. Chaining Requests ⛓
7. Working with Protobufs 🤝

What to expect 🕶

At the end of the series, you should feel comfortable working with URLSession and be able to code your network layer.

During the series, I will implement things in my style and I encourage you to use your style wherever you see fit. The beauty of programming is that there are many ways to achieve the same task and we all have our own approaches.

I will share a link to the Github repo at the end of the series.

Code snippet 💻

Let's take a quick look at what we will attempt to achieve. Below you will see an example of how the what we will be building can be used. This example demonstrates a call to the JSON Placeholder API to fetch a list of users. The request is type-safe and the response is decoded to a User model. Client defines the API we will be using make requests and UserEndPoint is an Enum conforming to a protocol that defines requests.

See you soon 🚀

If I have piqued your interest make sure to subscribe to my blog, follow me on Twitter, and let me know!

See you in the first post of the series where we cover how we can define our API. 👋🏾