Not that I’ve been even remotely subtle about it, but with today’s release of iOS 8 and the end of the NDA on its SDK, I can now officially announce iOS 8 SDK Development, now available as a beta book from Pragmatic Programmers:

Here’s the tl;dr:

  • Pretty much completely rewritten from previous edition
  • All code examples use the Swift programming language
  • Works through a single app all the way through the book so readers get experience of evolving a non-trivial app
  • Shows off iOS 8 features, including adaptive sizing strategies for the iPhone 6 and iPhone 6 Plus

Read the rest of this entry…

So, Xcode 6 beta 7 came out today, and with it, lots of changes to the Swift APIs for iOS and OS X. Mostly, it’s the ongoing removal of the ! character from parameters and return types. The bang is an implicitly-unwrapped optional, meaning it’s an optional — a variable that may or may not have a value at all — but since having to check lots of variables against nil and unwrap them would be burdensome, you’re allowed to treat it like a normal non-optional variable. Only downside is that your app crashes if you don’t unwrap and it turns out to be nil.

In the early Xcode 6 betas, nearly every parameter in Apple APIs was a bang, since they had to be optionals (nils were commonplace in Objective-C), but Swift adoption would have been hindered if we’d spent June through August unwrapping them.

For the last few betas, Apple engineers have been doing yeoman’s work, going through all these APIs and identifying what must be an optional, and what doesn’t need to be. So, the bangs are disappearing, replaced by either ? for honest-to-goodness optionals that should be tested against nil, or empty space, indicating the variable will always have a value.

If you’re writing a lot of Swift code — say, for a beginner’s book with 30+ versions of your sample code app — you’re used to each new build breaking your code, and forcing you to do through and make some pretty simple edits to deal with API changes as the bangs disappear.

Swift compiler errors caused by removal of implicitly-unwrapped optionals in Xcode betas

In some cases, it’s making me do unwraps where I’d previously been playing fast and loose with the bang-type. And that brings me to a question. There are two ways to do unwraps, and I’m not exactly in love with either of them.

Here are two examples. In beta 7, all the UIViewController properties for finding parent containers (navigationController, splitViewController, tabBarController) have all become full-on optionals, so a reference to self.splitViewController.delegate no longer works. One way to deal with this is to explicitly test for nil, and then use the bang operator to unwrap inside the if block.


if self.splitViewController != nil {
    self.splitViewController!.delegate = self
}

This is OK, except that when you have a non-trivial number of lines in the block, all the bangs seem dirty. We can avoid this with option #2: casting to a non-optional type in the if:


if let validSplitViewController = self.splitViewController {
    validSplitViewController.delegate = self
}

Fewer bangs, but now I’m burdened with coming up with a name for the non-optional version of the variable. And good variable names are hard to come up with. Heck, what’s even a good convention for this? validFoo? unwrappedFoo? safeFoo? It feels like I’m polluting my code with more variables to keep track of.

Since I’m not pair-programming or working with a lot of people producing Swift code, I’m not sure which is becoming the preferred idiom, and I don’t want to inadvertently write a book of my own idiosyncratic coding style.

Next best thing… a poll! Let me know what you think, and I’ll ack back at some point with the results.

Thanks in advance for your votes, comments, and pre-orders.

RESULTS UPDATE (Sept. 5): After a couple days and 38 votes, results are:

  • 26 votes for Use if let / if var to unwrap to a new variable
  • 5 votes for Test against nil, unwrap with !
  • 7 write-ins, almost all for an optional-chaining alternative I failed to mention: self.splitViewController?.delegate = self

So, I see from Janie Clayton-Hasz’s blog that That Conference managed to deliver a ham-handed and offensive keynote, detailed in blow-by-blow fashion by her tweets (1, 2, 3, 4, 5, 6, 7, 8, 9), the most egregious of which is the seeming equating of Gray’s Anatomy with “girly stuff”, and the unstated but strongly implied premise that “girly stuff is bad”.

FFS, why do we still put up with this?

Actually, it kind of reminds me of a Twitter or App.net exchange that Janie and I had some months back, in which I argued that we really ought to stop using “dude in a dress” as a comedy trope, not just out of fairness to LGBTQs, but out of fairness to women. The premise that men in drag is funny is based on feminine things being weak or inferior, and male things being strong and superior. So a man choosing female traits — whether clothing or Grey’s Anatomy — is therefore ridiculous.

IMO, women who laugh at men in drag are putting themselves down.

Since Janie mentions my love of anime in her blog, I’ll mention here that this is perfectly captured in an anime called Wandering Son, a fairly realistic series about young teenage transgenders, a boy who wants to be a girl and his close friend, a girl who wants to be a boy. The anime series is quite short at 11 episodes, and assumes you know the characters from the manga, as it hops right into a pivotal plotline involving a female upperclassman who gets praised for showing up to school in a boy’s uniform, but when Nitorin wears a girls’ uniform in public, he’s ridiculed so mercilessly he can no longer attend class and has to spend every day in hiding in the school infirmary.

Wandering Son, ep 9 - Nitori attends school in girls uniform

This is because, of course, masculine stuff is good, and feminine stuff is bad. As if the ideas and experiences of half the human race are inherently inferior.

FFS, when do we get to be over this crap?

Just last week, we were at CocoaConf Columbus, where keynoter Mark Dalrymple encouraged attendees to pursue and make the most of their passions and pursuits. This led Janie to an interesting blog about her cross-stitching and a wry metaphor in her Open GL / GPUImage / Metal session that she’s been a human vertex shader for the last 25 years, and that cross-stitching actually makes for a pretty nice, concrete explanation of how to do computer graphics.

One that we wouldn’t have gotten if CocoaConf attendees had a problem with “girly stuff”.

CocoaConf Columbus was last week, and as has been the tradition for the last year or so, I participated in The CocoaConf Game Show, a take off on the BBC Radio panel show Just a Minute, in which panelists have to speak extemporaneously on an arbitrary topic, without pauses, going off-topic, or even repeating words not in the topic itself.

I’m not nearly quick-witted enough for this, certainly not as much so as regular panelists James Dempsey or Josh Smith, but I try to hang in there. Or maybe I’m just always tired at the end of the conference (this time from staying up late the night before with Janie Clayton-Hasz and Laura Hart watching Adolescence of Utena, because anime).

Anyways, point here is that I have to come up with something funny (and not pause or repeat any words) on an arbitrary topic. Turns out it’s better to just do something silly with it, but when you get a topic that really matters to you, that’s another story…
Read the rest of this entry…

Janie Clayton-Hasz and I are working on the unit testing chapter for the still-unannounced book, and we’ve had enough fun that we decided to share a little bit of what we’re up to.

In the previous edition, I wrote a testing chapter based on Bill’s iCloud recipes project, and it was a nightmare for a couple of reasons. First, a completion handler that was supposed to be called from -[UIDocument closeWithCompletionHandler:] wasn’t, at least not in iOS 6. Second, iCloud sucks (c.f., “First”). And finally, the whole idea of testing something that takes an unknown amount of time is an interesting problem, one that OCUnit was not built to handle.

So it was really cool that Janie did the research and came back with promising results about asynchronous unit testing in iOS 8 / Xcode 6. Then we jumped into the chapter and… well, it’s not as pretty as the WWDC video would have you believe. It works, but sometimes you have to play a little dirty to get it there.

Read the rest of this entry…

Next Page »