For the past several iterations of Xcode, Apple has quietly but steadily improved the quality of the backing toolchain. In particular, the clang static analyzer has gotten quite a few improvements; however, LLVM hasn’t been neglected.

Far from it. In Xcode 5.1, Apple shipped an updated version of LLVM that included upstream revision 196314. The summary of that change is brief – “Introduce attribute objc_designated_initializer” – but the potential implications are wide-ranging. But first: what are they even talking about?

Over the years, Apple has provided a few handy tricks here and there about debugging Mac and iOS apps. Sometimes, these tricks take the form of private methods implemented by framework classes; if you know the right selector, you can get your objects to dump all kind of debugging information. (Of course, none of these selectors are suitable for use in released apps, but they can prove really handy during the development cycle.)

Since none of these are really documented, though, it’s easy to confuse which private methods are available on which classes. For example: if I have a UIView, should I use -_subtreeDescription or -recursiveDescription to log out its subview hierarchy? And is that really where that underscore goes, or did I get it backwards?

After some nudging from coworkers, I took some time and scraped together all the various private methods I could find (as well as a few suggested on Twitter) and combined them into one debugging cheat sheet, which I’m making available right here. Download it today, and suggest more!

Update: @monowerker put together a Dash version of this cheat sheet, which you can find on GitHub here. Thanks!

A year after my first talk on UICollectionView, I had the chance to return to Seattle Xcoders to discuss UIViewController containment in iOS 8. The slides, code, and video are all available online.

Note: this post is part of a series about the Swift programming language, introduced at WWDC 2014. I’m no more experienced in Swift than anyone else outside Apple, but I learn best by coding and talking through a problem. If there’s a better way to approach some of these topics, get in touch on Twitter!

We’ve had a little over two weeks to play with the Swift programming language now, and one sharp edge that keeps coming up is the language’s inclusion of what they call “optional types”. The vast majority of Objective-C developers are familiar with the use of nil to indicate a nonexistent value, but communicating that kind of information through a variable’s type is a bit more foreign.

In this post, we’ll have an introductory discussion about how Swift provides optional types, go over a couple of implementation details, and point out a few tough spots in the optional system.

Note: this post begins a new series about the Swift programming language, introduced at WWDC 2014. I’m no more experienced in Swift than anyone else outside Apple, but I learn best by coding and talking through a problem. If there’s a better way to approach some of these topics, get in touch on Twitter!

An ordered dictionary is a useful data structure that combines attributes of an array and a dictionary. Like an array, it stores elements in the order they’re added, and enumeration happens in the same fixed order every time. It also satisfies the basic idea of a dictionary: it stores key-value pairs, and can look up values by key.

Ordered dictionaries are incredibly useful tools for all kinds of development. To crib an example from the Swift book, an ordered dictionary might help an app display people and their ages: you might use names for keys, ages for values, and use the order to provide data in table cells by index path (and support user-driven reordering, to boot).

In this article, we’ll build an ordered dictionary atop the two primitive collection types already in Swift: an Array and a Dictionary. Let’s go!