I recently wrote about why I prefer not to use default implementations in Swift protocols. Here is how you can still optimize using a default implementation without the unintended side-effects...

Why I decided against a nice refactor...

One thing I’ve noticed recently in my code-base is that I tend to default to guard vs if. In fact, whenever I write an if statement, I facepalm myself and change it to a guard without thinking much. But that’s become a problem. There is in fact a difference between guard and if and thought does need to be put into which one to use.

A few months ago, I gave a talk titled Build Features, Not Apps at iOS Conf SG – you can view the full talk here. It was clearer than ever to me after WWDC 2016 that the future of apps is a web of distributed features instead of one concentrated app. Think of Apple Watch, Today’s Widget, Rich Notifications, App Search, iMessage Stickers, and the list goes on…

I've been trying to figure out how to reuse the same interface controller code for all my interface controllers in a watchOS paging navigation, and finally did. But this solution comes at a price...

The try! Swift app runs on both iOS and watchOS, and I’d like to expand it to support fancy extensions and possibly something with iMessage. While I was ok duplicating the Model layer between the two platforms initially, as more extensions and platforms are something I want to code quickly on, it was time to move that code out into a framework.

I’ve been upgrading the try! Swift app to Swift 3.0 for what feels like 3 days now. But anyway, this morning my BUILD SUCCEEDED!! And although the process was definitely frustrating, a lot of the things that needed fixing were very repetitive and a good opportunity to refactor...

This blog post is more of a general architecture overview of CloudKit for a use-case where it came in handy...

I recently gave a talk about Protocols with Associated Types (PATs) – I was worried that my audience would already know everything about PATs, but turns out the opposite is true. So here is an explanation...

I keep having a hard time remembering how Implicitly Unwrapped Optionals (IUOs) work in Swift 3, so I went back and watched that part of the What’s New in Swift WWDC16 talk again. This time, I want to write it down as a reference to myself and for anyone else who needs it.