Swift Network Layer Series

Subscribe to my newsletter and never miss my upcoming articles

Welcome to the Swift Network Layer Series! 👋🏾

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.

carbon (1).png

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. 👋🏾

Comments (2)

AndroidSagger Sir's photo

Sounds good, As long as it going to have generic approach and flexible .

Malcolm's photo

Most definitely. Working on part one as we speak should be out in the coming week.