Sure, it‘s a bit more verbose, but I feel like it‘s a better expression of the program‘s meaning.

When a programming language gives you multiple ways of expressing the same idea, the expression the programmer chooses will highlight a specific aspect of that approach. Here, the map expression is effectively a choice to emphasize the definition of a function whose domain is the possible return values of the NSFileHandle initializer. Because the domain of a function is a set, the reader is suddenly concerned that there is a collection of NSFileHandles being mapped into FileHandles!

Understanding what this function actually does requires two pieces of background information: that NSFileHandle.init(forReadingAtPath:) returns an Optional (so it may return nil if given a bad path), and that Optional<T>.map exists to treat a non-nil Optional as if it were a one-element set. Then it becomes apparent that the writer‘s intent is to transform only vaild NSFileHandles into FileHandle<Read>s.

Surely programmers cannot be absolved from having some knowledge of the framework and the standard library they are using, but let’s contrast this approach with the alternative. The if-let formulation emphasizes the specific elements for which execution is defined. It also specifically highlights that one of those elements is nil, and thus it‘s fairly apparent to the reader that the purpose of the construct is to define correct behavior for success and failure cases. No need to have memorized whether NSFileHandle has a failable initializer. No need to know that the Optional<T>.map shortcut exists.

That said, we do lose the assurance that all possible cases are covered, which map provides. We could gain that back with a (never-executed) else clause, or we can rely on the explicitness of the nil test to assure the reader that only two possible cases exist and that both are covered. Percentage-wise, we also gain a fair bit of verbosity, but in absolute terms it‘s not so much. In fact, I‘d argue that the map version is actually compressing too much information into too few characters.

Fortunately, we can combine if-let‘s readability with map‘s terseness and assurance of having defined a total function by defining a function-pipelining operator |->? like this:

One can imagine that this operator is the sibling of a |-> which does not deal in Optionals. The trailing ? makes the behavior of this operator clear to the reader by analogy to the ?. (optional-chaining) and ?? (nil-coalescing) operators.

Of course, we could convert the anonymous closure into a named function, perhaps named something like makeReadHandle. That minimizes the complexity of each element of the pipeline. Here, it might not be that big of an advantage, but if I stuck another step on the end of the pipeline, I‘d consider it rather strongly.

UIScrollView.contentInset is conceptually a very simple API: it extends the scrollable range beyond that implied by the contentSize property. (The objc.io magazine has a great article on UIScrollView that explains contentInset in terms of simple arithmetic.) Its two main use cases are avoiding the keyboard and correctly underlapping iOS 7+’s translucent bars. But if you want to get more complicated than a navbar and a keyboard, the simple nature of contentInset makes things difficult.

Yesterday I wrote some code to hide the Trash location in our document picker when it’s empty. Today, I got a bug report that attempting to add or remove a cloud storage location in the document picker would now crash with an exception thrown by UITableView. These didn’t sound all that related other than timing and both involving the document picker.

And at first, all the evidence told me they were not related. But thanks to a combination of overlapping bugs it took me over an hour, a fair bit of disassembly, and some moral support from my coworker Jake to track down the origin of the bug.

Updated: It turns out that UIKit likes to set the first responder to nil. At that point, my technique for finding the first responder winds up returning the UIApplication instance, which nullifies the technique. I’ve rolled back this change from our codebase; I’ll leave the blog post here, but I can’t advise anyone adopt this technique.

One of the best patterns that UIKit inherited from its older brother is the responder chain. It is a fantastic way to decouple UI controls from their targets and enables the same control to perform its function even as the user interface or controller layer changes around it.

On iOS, like on the Mac, UIApplication plays a central role in dispatching events to the responder chain: -[UIApplication sendAction:to:from:forEvent:] starts with the first responder and walks up the chain to find an object that can handle the provided action. But what if you just need to know whether such a responder exists, or you need to ask it further questions before you dispatch the action?

iOS 8 brings a new and welcome class to UIKit: UIPresentationController, which reifies the presentation of view controllers in a configurable object whose lifetime can also be used to more cleanly manage auxiliary UI elements associated with that presentation.

Conceptually, popovers are a form of presentation, so they are now managed via a subclass of UIPresentationController, logically named UIPopoverPresentationController. Unfortunately, the actual API design surrounding this class leaves a lot to be desired.

The new -[UIViewController targetViewControllerForAction:sender:] method (and its related methods, -showViewController:sender: and -showDetailViewController:sender:) in iOS 8 takes a clever responder chain-based approach to showing view controllers in a size-class-adaptable way.

Basically, all UIViewController instances respond to -showViewController:sender: and -showDetailViewController:sender:, but their implementations use -targetViewControllerForAction:sender: to find the appropriate view controller to actually do the showing. In the case of -showViewController:sender:, this is likely an enclosing UINavigationController, and in the case of -showDetailViewController:sender:, this is likely an enclosing UISplitViewController.

I just sent an e-mail to Tim Cook about his company’s decision to include a series of Christian holidays on their built-in “U.S. Holidays” calendar, and to configure them with alerts to ensure their visibility:

If you’re going to WWDC, and prefer to avoid chain restaurants, Irish pubs, and Starbucks coffee, I’ve assembled a Foursquare list of personal recommendations. I might add to this list over time, so saving the list to your own Foursquare account will keep it up to date.

And if I personally know you, please friend me on Foursquare and share your suggestions with me. I’ll add your recommendations to my list of suggestions from others!