It's a common pattern in Swift (and a really nice one!) to configure constants right when they are initialized in a closure vs later on in a viewDidLoad or another such method... but it can get awkward!

I recently gave a talk on Practical Protocol-Oriented-Programming(POP💥) in Swift. The video is still being processed. Meanwhile, here is the written-up version of the POP View part of the talk for reference (for me and anyone else!).

I recently gave a talk on Practical Protocol-Oriented-Programming (POP💥) in Swift. The video is still being made. Meanwhile, here is the written-up version of the POP Networking part of the talk for reference (for me and anyone else!).

Notice the thing! Since each View Controller would be injected with something specific – it could be text-based or number-based or array-based, anything! I didn’t know how to name the parameter. So thing seemed like the most fitting parameter name.

I read a comment by @cduhn on my I 💖 Storyboards & Nibs blog post that triggered an idea for a slightly better solution for this...

Starting in Swift 3.0, C-style for-loops will be gone from Swift! Last week, I talked to an iOS developer who was upset by this (it is a long-held habit after all!) and was confused by what to use as an alternative. @twostraws did a great write-up on the new Swift 2.2 features and what to use instead, so I’m going to write it down here for my own (and your) reference.

Since I openly declared my love for Storyboards & Nibs earlier this week, I’ve gotten a lot of questions on how I deal with injecting dependencies between View Controllers without using a custom initializer. So I’ll share that now. But first...

I’ve seen Phantom Types before, including in this objc.io article about Phantom Types and in conference talks, but while I like the idea of Phantom Types and think they’re cool and interesting, I haven’t actually used them ever in my own code. Mostly, because it’s not yet natural for me to see a problem and think “Ah, Phantom Types would be the perfect solution!” But this example caught my eye...

Earlier today, I wrote about all the unconventional ways I use extensions in Swift to make my code more readable. This somehow triggered an interesting discussion on Twitter around Swift naming conventions. I won’t go into detail on that here – you can read the full discussion yourself if you’d like. But I did learn something super cool...

When others look at my Swift code, they immediately ask why I use so many extensions. The main reason I use extensions is for readability. Here are the use-cases where I LOVE to use extensions, even though that’s “not what extensions are made for”.