Nice mustache! Here's some other Foundation classes/methods which are very useful but lesser known:

NSCountedSet - and NSMutableSet that keeps counts of objects added

NSValueTransformer - More of a design pattern for generically converting objects

NSArgumentDomain in NSUserDefaults - command line arguments of -key value become user defaults

NSXMLNode nodesForXPath:error:/objectsForXQuery:error: - run XPath or XQuery against XML... even better, subclass NSXMLNode and then use XPath and XQuery on any hierarchical data you have

NSObject's performSelectorOnMainThread:withObject:waitUntilDone: - use NO for waitUntilDone and the method will be called at the end of the event loop (I've seen many people use the afterDelay variant instead)

NSNotificationQueue - use NSNotificationCoalescingOnName to batch up NSNotifications to send a single one at the end of the event loop, though there's lots of gotchyas for using it correctly

NSOrthography - Okay, even I didn't know about this before re-glancing at the foundation reference :)

It's interesting how much of the Foundation consists of patterns for overcoming the awkwardness of Objective-C.

For example, in most modern languages, NSCountedSet is crazy trivial; you just use a hash of numbers. But since Obj-C doesn't have autoboxing (well, it kinda sorta does nowadays, but anyway), having a built in implementation is nice.

NSValueTransformer is a similar workaround for a lack of language features, which will look particularly alien if you're used to languages with proper closures and autoboxing. They are a boilerplate nightmare, and Apple would have done well to provide some simple implementation that could be controlled from the interface builder years ago (based on JavaScript expressions, for example).

Anyway, a fun exercise with NSValueTransformers is to build a subclass for chaining them together (bonus points for automatic reversing), and then a subclass of simple primitive operations that you can compose into more complex transformers. This can actually be pretty useful if, for example, you have a number of log-scale sliders and text fields that require slightly different transformation parameters.

I think my above comment may have come across as unnecessarily harsh against Objective-C. I like Obj-C and I was actually trying to make a broader point: you can often learn a lot about a language's weaknesses and quirks by digging into its standard library.

Oh my god, NSValueTransformer. Why has this not been in my life the past two weeks. Same goes for performSelectorOnMainThread. Thankyou.

A journal of the "overlooked bits in Objective-C" should begin (and possibly end) with the C standard library.

Snark aside, fun!

Just a note: NSCache is dangerously busted (as of Mountain Lion GM, 10.8 (12A269), including 10.7), and tends to deadlock rather easily. Particularly, when the system sends a "memory pressure" notification, such that the cache is supposed to evict things. Stay away, for now.

http://openradar.appspot.com/10916098

Other overlooked things; objc_getAssociatedObject and class_copyPropertyList wrapped beautifully into objective-c by Mike Ash here: https://github.com/mikeash/MAObjCRuntime

Nice!

Sure wish this had an RSS feed. Who's going to visit every week to see what's changed?

Oh, wait, it does--just have to use the source. Can you make a feed icon somewhere? Chrome and Safari no longer show the feed availability visually; I guess RSS has dropped out of the mainstream, sadly.

I always wondered what the relationship was between how NSIndexSet and CFBitVector work behind the scenes. Their typical use cases are somewhat different, but they are conceptually very similar, and it would be fairly trivial to implement all of the functionality of either by wrapping the other.

Here's hoping they have a piece on Swizzling!

This sounds like a maintenance programmers worst nightmare. Although I'm coming from a Java background so naturally I have accrued an unhealthy amount of bias.

Anybody from the more dynamic languages have any war stories about debugging/maintaining this sort of thing?

You must use it really, really, really sparingly. There are cases where it's useful, but they're pretty rare. When you do it, you need to document the crap out of it.

I've been lucky never to hit any code where someone did this kind of thing without taking that into consideration, so I can't say how bad it gets when it's screwed up. Used sparingly it can be pretty nice, but you have to be really sure you're not just overcomplicating things for no good reason.

Duly noted. Post on Swizzling and the new Objective-C literals are forthcoming :)

When you do, please recommend one of the techniques/libraries that properly generate super calls.

Does swizzling really have a place in well-designed software today?

(edit: changed everything. ;-)

I only use it in cases where an underlying framework does not expose or provide the functionality I need (and subclassing is not an option). I wouldn't necessarily say it means these frameworks are not well-designed though.

Yes, at least in unit tests.

Sometimes you need to call stuff which you cannot work around so it is required to patch calls.

It's also useful for developing developer tools (for the same effect as interposing).