Types aren't just for the compiler and runtime, they're also to communicate intent to other programmers and future instances of self.

As other posters have stated, they're very useful for collection classes. I've had a lot of stupid bugs in Obj-C that would have been caught by the compiler if it could verify that only the right kinds of objects are going into an NSArray, for instance.

The only thing that makes sense is something like categories, as a way to specify an expected set of operations, which Objective-C already has.

This is, in my opinion, the best answer. The dynamic nature of the language is something that allows for great flexibility, especially in passing objects of varying types down the road until it is time for them to be displayed.

For example, if I have a news aggregator that keeps an array of 4-5 types of article objects, I may want to process them differently in a UITableView. I could store them all in the array and then do type checking at the time they should be rendered to determine how each are displayed. Of course, this can be achieved in statically typed languages as well if, say, each article class inherited from a common class, but what if they don't? On that note, does anyone know how this library handles inheritance?

This library would definitely help if you prefer the statically typed languages, but I would be wary of losing the freedom of Objective-C. Instead of binding data containers to types, perhaps good documentation and clearly written code is more the answer.