Here's to the crazy ones. The misfits. The troublemakers. The Swifters.

Viewing entries tagged

Hipster Swift: Demystifying the Mysterious

This is a pretty cool article on things you probably didn't know in Swift. Or maybe things you've seen in Swift code that gave you a "WTF does that mean?" moment. Or maybe you feel like being a hipster. Or maybe you want to be able to say, "Oh, I knew about that thing in Swift before it was cool!". Or maybe, just maybe, you love me and support me by reading my posts. So what are you waiting for? Hurry up and click the link already!

Auto Layout Magic: Content Sizing Priorities

Auto Layout can be a bit of a pain sometimes. Luckily enough, there are a few of us who can more or less deal with it when we need to. Constraints are easy enough to understand but what about the other things? What the hell is Content Hugging and Content Compression Resistance Priorites? Here I'm going to take a stab at it and see if I can learn you a little somethin'.

The Right Way To Write a Singleton

Due to the nature of a beta language, Swift didn't have all the right things it needed when it first started out. For instance, Singletons, over the course of the development of Swift from 1.0 to 1.2, gained several different implementations. Unfortunately, the proper way to write a singleton hasn't been propagated amongst the community yet due to the lack of documentation outlining how to write a singleton. What does "by virtue of let" mean anyways? How do we know our current implementation of a one line singleton satisfies the rules of being a singleton?

If You're Subclassing, You're Doing It Wrong.

Subclassing can suck. There are so many ways to get it wrong and it's so easy to fall into anti-patterns when you create such a tight coupling between two classes. Most of the time, the need for subclassing can actually be replaced by abstraction through protocol-oriented, value-oriented, and functional programming. In fact, I may even argue that doing it that way can far outweigh the "benefits" of subclassing the majority of the time.

How to Highlight Your TODOs, FIXMEs, & ERRORs In Xcode

Quite often we find ourselves marking our code with TODOs, FIXMEs, and ERRORs only to find some of them forgotten about and left by the wayside. In Objective-C, it was easy to mark these tags and have them show up in the Issue Navigator but since the introduction of Swift, we haven't gotten an equivalent to compiler directives that can do the equivalent. Until now.