Rss

Announcing iOS 8 SDK Development

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



Backstory

Bill Dudney and I worked on two previous iPhone books for Pragmatic Programmers: iPhone SDK Development in 2009, targeting iPhone OS 3, and iOS SDK Development in 2012, targeting iOS 6. Between the two, Bill did a two-year stint at Apple, which prevented him from writing books, and in mid-2013, he went back to Apple, thereby taking him out of working on an update to the second edition.

I tried to do that update myself, pulling in things like autolayout, about which we had to hastily add four pages for the second edition when Apple plopped that into the Xcode 4 GM with no prior warning (in order to accommodate the iPhone 5) and that I wanted to cover better. Then there were storyboards, which were treated as an option in our existing book, but which are practically mandatory for Xcode 5 iOS projects. But, distracted by client work, I fell behind far enough that it was late 2013 with no end in sight, and the market for an iOS 7 book already sated, so we called it a day on that update.

In the Spring, we started talking again about an update to the book, and whether it would make sense to bring in a co-author. At first I was resistant, because Bill and I had a pretty good working relationship — since we both know our stuff, we pretty much could run in parallel. But I also thought, “I’ve let down the Prags once, what will be different the second time?” So I started considering possible co-authors, people who knew their stuff, and would be able to deliver.

And a really unconventional idea hit me: my CocoaConf-loving friend Janie Clayton-Hasz had been eager to do her first book for a long time, but couldn’t break in. With me sitting on a half-finished book, she could do half of what was left, which would get her published, and take enough of the load off me to actually finish this time. What could go wrong?


A Change of Plan

Well, for one thing, Apple could introduce an entirely new programming language.

The introduction of Swift immediately obsoleted the 150 pages I’d written, but it was a great opportunity too: get one of the first substantial books out there on using the iOS SDKs with Swift, and we’d make a lot of people really happy.

So, starting on the Friday of WWDC, I started porting all the code examples I’d written for the first six chapters over to Swift. And then Janie and I divvied up the material not yet written or coded at all and got to work. As of today, we’ve made 306 commits to the book’s repository since then.

Is it safe to go all Swift? Should we hedge our bets and mix Obj-C and Swift, or maybe just do an Obj-C book with a Swift chapter? I think development for the Apple platforms is going to rapidly move to Swift, and Obj-C will hang around mostly for maintaining legacy codebases (of which there are many), and low-level stuff (most of my Core Audio stuff can’t port to Swift yet). I didn’t want to get into a situation where we treat a technology as an option only to see it become mandatory, as happened with storyboards in the previous edition. I also recalled the experience of the early Java books, where all the 1.0 books were filled with C++ comparisons (which did me no good, since I knew C but not C++), and then all the C++ stuff disappeared with the Java 1.1 books as the language stood on its own and asserted itself as its own thing. There’s no reason to think that Swift won’t live up to its potential, so for a newcomer to the platform, why make them learn two languages? It’s already bad enough that we’ve had to mingle C and Obj-C, and that I’ve spent years teaching “square braces here, parentheses here, because history”. Swift cleans up a lot of crud and I think developers coming over from other platforms — our target audience for the book — are really going to enjoy it.

Of course, Apple could always end this argument real quick by, say, only supporting Swift for Apple Watch development. I’d give 50-50 odds on that happening.


I’ve Never Had a Valet. You Can Try It For Tonight. I’ll Most Likely Kill You in the Morning

Janie and I had actually gotten started in the Spring, prior to WWDC. She had already been tech-reviewing other iOS titles for the Prags, and is a really good writer, so she didn’t have any trouble passing editorial muster, and officially came on board right before we met up at Anime Central in Chicago. Instead of waiting in the rain for tickets the first day for a Final Fantasy concert, we convened around a laptop and I showed her how the Prags build system works, probably marking the first time a Prags book kickoff meeting has been held in cosplay (she cosplayed as Yuri from Angel Beats!; my cosplay didn’t show up in time because China was temporarily out of purple). The selfie below is us waiting for the Wake Up, Girls! concert.

Chris & Janie at ACen 2014 Wake Up Girls concert

I’ve tried to adjust my voice to more closely match hers, to make the book more seamless between our chapters. Janie uses a lot of analogy and personal or pop culture stories to illustrate conceptual stuff, which I’ve adopted for this book, and I’m really happy with the results. A lot of times, I put on blinders and grind out chapters to get them done, and stepping back to think of how to take the ideas out of iOS and square them with a friendlier concept really helps. There’s an analogy to kick off each of the closure chapters that I think will help people get a grasp of queues and closures.

That said, we’re still true to the major goals that Bill and I set out in the previous edition: to serve as both a prerequisite to other iOS books (from the Prags or other publishers) and to square with our real-world experiences. One of our cornerstones was the idea that many (most?) iOS developers will need to get data from the network and put it in the GUI and to do that, you absolutely must understand Grand Central Dispatch, and its little dance of putting work onto to the main queue (since your network callback is typically on a non-main queue). In Swift and iOS 8, touching UIKit from a non-main queue seems to just be a 10-second penalty instead of the crash we used to get, but it’s still something you absolutely have to understand and get right. We’ve gotten pushback over the years about why we’re digging into something so hard in an introductory book, and we have been resolute in our response that it is essential for writing non-trivial iOS apps to be comfortable with asynchronicity and concurrency. It helps that the Swift closure is so much cleaner than C “blocks”: we don’t really need f’ing block syntax dot com anymore, as the Swift recipe for a closure is easy to write off the top of your head: (Type1 arg1, Type2, arg2…) -> ReturnType in { … }. It’s basically a function definition, minus the function name and plus the word in. Not surprising, perhaps, since in Swift, functions and methods are actually just special cases of closures.

It’s been encouraging watching Janie develop this year. She did her first conference talk back at CocoaConf Chicago in the Spring, and now she’s doing 2-3 per conference, taking on stuff like 3D graphics (it helps that she now works with Brad Larson of GPUImage fame). She’s already doing graphics talks with math that scares me, so that’s pretty cool. Plus, when we’re both fried from writing, she’s a worthy opponent for Tanto Cuore on Game Center.

Rare victory over @redqueencoder on Tanto Cuore


Best Bits

There’s a lot in the book I’m happy with. We’ve split up some of the long and involved parts into smaller and more manageable pieces, like taking two chapters for the many uses of closures, and a long look at navigating through multiple view controllers. For that, we make use of iOS 8’s nifty trick of supporting both iPad and iPhone with the UISplitViewController, with iPhone turning it into a two-screen pseudo-navigation thing.

We also jumped in on last week’s iPhone 6 and iPhone 6 Plus announcement to get in an section in the so-called “Big Screens” chapter showing how to revert the UISplitViewController back to side-by-side mode if you decide the screen is big enough:

iPhone 6 Plus simulator showing UISplitViewController in side-by-side layout

Throughout the book, we build up a single sample app, a Twitter client, using the built-in Social and Accounts frameworks. This saves us a ton of writing drudgery, not having to walk through creating new projects and new storyboard layouts over and over again (the worst of it is in the navigation chapter when we add two new scenes). We thought it was important to develop skills like refactoring (even though automated refactoring of Swift code is not yet available), collecting your classes into groups, and fearlessly reworking and reconnecting stuff in storyboards.

Related to this, another major decision we made was to treat iPhone and iPad as equals. Previous editions were explicitly iPhone books, back when we could refer readers to Daniel Steinberg’s iPad book for the delta when it comes to tablets. Now that his book is out of print — c’mon, it was written for iOS 3.2 — we decided it was time to bring all iOS form factors into the fold.

Speaking of Daniel, he’s written what to my mind is the only serious and thoughtful book on the Swift language I’ve found so far, A Swift Kickstart. Our book is unapologetically an API book, with just enough Swift to make calls and get return values (or callback parameters). His goes deeply into the patterns and values of the language itself, and it will be helpful for anyone trying to evolve beyond the “just throw syntax at the compiler until it stops complaining” stage of Swift coding.


Wrapping Up

The beta of iOS 8 SDK Development has 11 of 15 chapters in place, weighing in at 235 pages (we’ll probably hit 300 when we’re done). Janie’s debugging chapter is nearly ready, but we didn’t want to abuse our editor by making her edit an entire new chapter during the crunch between last week’s Apple event and today, when we were already pushing to get everything else done. So that should appear as an update shortly. And it’ll cover watchpoints, which is cool because I never remember to use them. After returning from CocoaConf Las Vegas this weekend — come talk to Janie and I if you’re there — I expect to get the chapter on backgrounding and extensions done next week, leaving Photos for Janie and Publishing for me (an update from the previous edition, covering source control, App Store submission, and crash reports).

Plus we’ll be handling comments on the forums and errata. We have a bunch of screenshots from various Xcode betas that will have to be redone… I fully expect to just reshoot every image in the book, and hopefully Yosemite will come out before we ship 1.0, so I only have to do it once. I’ll also have to rebuild every sample code project in the downloads to handle the new bits that appeared for the first time in the Xcode 6 GM, such as the LaunchImage.xib file, which includes the lovely bug that your project won’t build if you have an ampersand in your company name. Jeez, as the President of Subequently & Furthermore, Inc., I hope that gets fixed soon, but I haven’t gotten a response to my Radar yet.

And once this is shipped… well, there are other things going on this fall, but those will wait for another blog entry.

Comment (1)

  1. […] what’s new and different? Well, the big one is, it hasn’t been three years since the previous edition. In the history of the basic iOS book from Pragmatic Programmers, between me, Bill, and Janie, […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.