We’re so close to finally having iOS 8 SDK Development out the door! We just got the index back on Friday, and it looks great. I spent some time last night going over it, looking for either missing topics or things that didn’t really need to be in there, and it all looked great. If anything, I came away thinking “did we really write all that?”

Clipping from iOS 8 SDK Development index

And yet I’m kind of wondering: do books even need indexes anymore?
Read the rest of this entry…

I’m not the first to say this. Chances are you saw Marco Arment tweeting about it earlier in the week:

The latter half of 2014 has been a disaster in terms of quality of Apple software. As I was finishing up the book, I kept an index card of all the bugs I needed to file. I ran out of room.

List of bugs to file

Some of these have caused real pain, such as the Xcode 6.1 iOS Simulator not supporting internationalization — horrible for us when the third chapter of our iOS 8 SDK Development book walks through an i18n example, and a later chapter shows how to make a third-party keyboard extension, which doesn’t work because the simulator now only supports the US English and emoji keyboards.
Read the rest of this entry…

tl;dr: I’m starting a full-time job today doing iOS development at rev.com. I’m not moving out to California. I’ll still be talking at conferences and possibly doing more books.
Read the rest of this entry…

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
Next Page »