Best of the first 6 months of Swift by Sundell
Six months ago I set myself a challenge — as someone who could count the number of blog posts I had written in my whole life on a single hand — could I start writing one new post about Swift every week?
Now, 26 posts later, I’m super happy that I decided to accept that challenge. Writing a new post every week has indeed been challenging, but also fun, interesting and very rewarding. I’ve learned a lot — both about Swift & about writing — and I’m very humbled & happy about all the great feedback & questions that I’ve received from the community.
While I’m not planning to stop doing this anytime soon, I want to take a moment and celebrate this milestone — by looking back at the past six months and listing the best content from my first round of posts.
Let’s dive in! 👍
These are the five posts that have been most popular with you — the readers — according to the number of reads & shares:
This is by far the most popular of all of my posts, in which I take a look at various options for dealing with errors in Swift. I split errors up by recoverableand non-recoverable, in order to pick the most suitable technique for handling them.
After making some changes to one of the larger projects I’m working on, I was able to reduce its compile time by over 20%. In this post I share the learnings from doing that, and provide some tips on how to identify code blocks that take an especially long time to compile.
One big adjustment for most developers moving over from Objective-C to Swift was starting to think about variables and parameters as optional and non-optional. In this post, I take a look at some techniques that can help reduce the number of optionals that are not actually optional, which will usually lead to an improved architecture and more stable code.
Dealing with dates is always tricky, especially so in unit testing, when you want to verify code that relies heavily on the current date and time intervals. This post introduces an easy-to-apply technique that lets you quickly provide mock dates to your code, making it possible to “time travel” in your tests.
I love diving deep into frameworks — especially ones that I’ve used for a long time. Grand Central Dispatch (GCD) is one of those, and in this first (of what I think will be many 😉) deep dives — I go beyond the most commonly used APIs and take a look at some really powerful (and not very widely known) features that can help solve many common problems.
It’s really hard to pick favorites from something you created yourself, but let’s just say these are the posts that I’m the most happy with how they turned out:
This one was a close runner-up in the reader favorites, and is definetly one of my favorites as well. It was a lot of fun to write, and I’m very happy both with the way I was able to convey the ideas of this post — and the reaction it received from the community. It’s about how state management code can be made easier, by enforcing single sources of truth and rendering state changes reactively.
I’m a huge fan of testing, so anything I can do to make testing easier and faster is usually something that I’m interested in. While I always try to write my own code in a testable way, a lot of the code that we write on a daily basis interacts with system APIs — and many of those are singleton based. Singletons are usually known for making code impossible to test, but in this post I walk through 3 steps to easily change that.
This is, at the time of writing, my most recent post — and I’m very happy with how it turned out. Futures & promises is a very interesting way to deal with asynchronous code, but it can sometimes be a bit tricky to wrap your head around (especially when it comes to what the difference is between a futureand a promise 🤔). So in this post I wanted to break things down and show how Futures & Promises can be implemented from scratch without a whole lot of code.
This was the first time I tackled a much larger topic — building a declarative animation framework from scratch — in a 2-part post. It was a lot of fun to do it, and it has been really great to hear from many people in the community who either built their own tools based on this post, or have taken a similar approach before. The 2-part post concept will definitely return in the future 👍.
The post that started it all! At the time I wrote this post, I had no idea of whether I would enjoy writing — or whether anyone would be interested in reading my posts 😅. While I think my posts have evolved quite a lot since then, this post will always hold a special place in my heart. It’s about how you can design better APIs by thinking about how errors are handled and what type of errors an API can throw.
Here’s to another 6 months!
Whether you’ve been reading every post, or this is your first time visiting this blog — thank you 🙏! The fact that so many of you are reading, commenting and sharing these posts means a lot to me, and you are what keeps me motivated to keep writing something new every single week.
I’m planning to keep doing this for as long as I can — so now that this milestone has been celebrated — I look forward to another 6 months of weekly posts!
Hope you’ll stay for the ride, and like always, thanks for reading! 🚀