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.

I also left variable row sizes for table views (via iOS 8’s estimatedRowHeight) out of the book because while it works on the device, the simulator re-lays-out the rows only after a rotation (putting a border on the cell’s layers proved to me this is what was going on), so it doesn’t work for our readers.

My iPad is laggy as heck under iOS 8, and tapping buttons often does nothing for 5-10 seconds after switching apps.

We moved the family to a new shared computer running Yosemite, and my wife is furious that sort-by-date doesn’t work for “All Mailboxes” view.

I do my CocoaConf presentations with Keynote for iPad. After upgrading to iOS 8, in Seattle and Boston the iPad screen locked and blanked the projector during the presentation, because I was using the remote mode from my iPhone to advance slides, and that apparently no longer resets the screen-lock timeout.

Also, I couldn’t post the slides from my Core Image talk, because Keynote’s PDF export (on Mac and iOS) omitted most of the text from most of my code slides, leaving the occasional [self as the only reminder there was ever any content there.

Reminders on my iPad was out of sync, I turned iCloud off and back on, and for a week it crashed at launch.

All of my iTunes LPs have broken, and Neko Case’s The Worse Things Get, the Harder I Fight, the Harder I Fight, the More I Love You has downloaded four copies of its booklet PDF, none of which will open in iTunes.

Also, iTunes will sometimes start splitting up an album into two instances while I’m listening to it, and sometimes fail to rejoin them completely, as with the Green Day album in this figure. Note that this is an album I bought from the iTunes Store.

iTunes mangled album metadata

Xcode 6.1.1 said it eliminated most causes of the “SourceKit service crashed” error when editing Swift code. Maybe so, but whatever’s left still crashes on me at least once an hour.

Oh, and Mobile Safari did this to me yesterday (no, not necessarily a defective page, it cleared up when I reloaded):

What the hell has happened? Remember two years ago when there was such an uproar over Core Data in iCloud not working? It was a hot-button issue, but very limited in scope: Core Data was still a trusted tool when used locally, and even iCloud behaved for most developers using it for documents or simple plists. It was a problem that didn’t involve a lot of collateral damage.

By comparison, what we’ve seen in the last six months is pervasive, if not ubiquitous. It’s in the developer tools, it’s in the operating system, it’s in iLife and iWork. It’s like the floor has utterly dropped out from beneath all Apple software, across the board.

It’s not like Apple lacks for talent — they keep hiring many of the best iOS developers I know. It’s more plausibly a matter of unrealistic scheduling: packing new versions of iOS and OS X, supporting them in Xcode, updates to all the iWork and iLife apps, and oh-by-the-way the first SDK for WatchKit, all into a couple months at the end of the year, looks in hindsight to have been severely over-ambitious.

And the looming release of Apple Watch compounds my concerns. There’s probably little prospect of fixing any of this until Watch 1.0 is out the door this Spring, at which point a new push for OS X 10.11 and iOS 9 will presumably be underway. Marco again:

There’s a cost to this. I recall Marco saying on some episode of ATP this summer (possibly relaying listener feedback?) that some Apple-to-Android switchers cited system updates as the reason for switching: that the new system slowed down their iOS devices, making them worse. I heard the same thing from developer/speaker pal Jeff Kelley yesterday:

Granted, the idea that Android software quality will be better than iOS is probably nuts, but it’s still clear that genuine damage has been done to Apple’s reputation, and it may well be evident in device sales before long.

Will there ever be a chance to just stop and clean up the mess? Apple’s done it before: Mac OS X 10.6, Snow Leopard, was famously pitched as having zero new end-user features. It was a fundamental modernization and fix of all of OS X’s underlying technologies: the Finder was rewritten in Cocoa, QuickTime was replaced under the hood with Core Media technologies, Grand Central Dispatch and OpenCL made their debut, etc. And it’s probably the last version of OS X that I really truly liked.

Could they do that again? We are clearly in need of “Snow” iOS, “Snow” OS X, “Snow” iWork, etc. Take 6-12 months off of the feature binge and just fix stuff. Or stop releasing iOS and OS X in tandem and let their crunch times alternate through the year instead of occurring together. Much as I’d personally like to see a “Snow” development cycle happen, it’s harder and harder to imagine in an Apple without Bertrand Serlet and Scott Forstall, an Apple where engineering reports to marketing and to design. It’s hard to see who’s left there to stand up for “it just works”.

Back to Marco’s point about Apple Watch: I had been planning on getting one, since my analog watch died a year ago, and I’ve been making do with a $10 “waterpark watch” since then. But as flaky as everything from Apple has been lately, I wonder if I’m not better off getting something like a Fitbit Charge to function as both simple watch and fitness band, and check back on Apple Watch in a few years, to wait out the 1.0 and see if they’ve gotten their act together. I’m still thinking about what to do here.

And closing on another personal note… this is the first blog I’ve posted since starting my new job at Rev, and it’s really been a significant culture change. In my contracting work, schedules, deadlines, and hours were always paramount. On my last contracting gig, we actually went pencils-down when they exhausted the allotted hours, mid-day, even with features incomplete and their server not even ready for integration testing.

At Rev, it’s like the total opposite: we own the code forever, and it’s essential for our services, so it’s quality that is the most important factor. This is like only the third time in my career that I’ve done code reviews with any genuine rigor (and the previous instances didn’t last more than a few weeks), and I find my established habits from consulting are working against me now: I’ve been typically unwilling to make fundamental changes, even if it’s the right thing to do, because of how hard it’s going to be (or how long it will take) to put things back together. But when quality is job one, then a willingness to make those kinds of radical changes is an asset, not a liability. Dates are important, but not necessarily at the cost of shipping bugs, or accumulating technical debt.

I’m trying to learn my lesson. Maybe Apple will learn theirs, in time?

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

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”.

Next Page »