Rss

Archives for : swift

Late 2017 Speaking Update

[Notice how I said “Late 2017” and not “Fall 2017”? You’re welcome, southern hemisphere.]

So I just have one speaking spot lined up for the rest of the year, at least as far as developer talks go(*). I’ll be at the all-new Swift by Northwest, the new conference by the CocoaConf folks, in Seattle in late October.

(* – as for anime talks, I’m wait-listed for Crunchyroll Expo in Santa Clara in August, and need to send in a proposal for Youmacon in Detroit in November)

Continue Reading >>

Render Unto C-sar

A few weeks back, I did a presentation at Forward Swift, the idea of which to explore how the media frameworks reveal some really interesting pain points in using Swift, and what this tells us about the language.

Slides are already up on Slideshare, and can be viewed here:



I’ll be doing this talk again at CocoaConf Chicago and an NDA event that will probably be announced next week. Forward Swift usually posts its videos eventually, and I’ll blog here once mine is available.

But I want to dig into one of the key points of the talk, because it came up again earlier this week…

Continue Reading >>

RxNot

A few weeks back, I tweeted:


The stealth message here was that there’d been a mass layoff, and as such, I’m no longer at MathElf. (Aside: which means, for the moment at least, I’m available for contract work: cadamson@subfurther.com).

While I’m not about to slam my ex-employer, I do want to get in a word about a key technology we used that left me cold. As the tweet indicates, this is gonna be about RxSwift.

Continue Reading >>

iOS 9 SDK Development now available

New book alert: iOS 9 SDK Development, now available as a beta ebook from Pragmatic Programmers.

Cover of iOS 9 SDK Development

So 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, it’s previously been the case that we’d more or less completely rewrite the whole thing, then not do anything with the title for two or three years. And at that point, we’d find it was so out of date, we either had to do a ground-up rewrite, or pull it out of print. Not to mention that the sales in years 2 and 3 were pretty much zero; nobody wants an iOS 6 book once iOS 7 comes out.

So, new idea: instead of rewriting 100% of the book every three years, how about we rewrite 33% of the book every year? Could that be a sustainable pace? That’s what we set out to try with this edition.

Continue Reading >>

Social Swift Style Survey #1

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.

[iframe src=”https://docs.google.com/forms/d/1YD2bQ4-KUJzZzB2nkKqu2TsCedVIlC8Viqwrys04TME/viewform?embedded=true” width=”500″ height=”400″ frameborder=”0″ marginheight=”0″ marginwidth=”0″ Loading…]

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

Asynchronous Unit Testing in Swift: The Good, Ugly The Bad, And The

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.

Continue Reading >>

Best CocoaConf Fall Tour Ever

In previous years, planning for Q3 speaking dates has been an enormous hassle, thanks to the Apple NDA: you can’t talk about any of the stuff coming in the new version of iOS, so you have to deliberately pick older topics, with a possible eye to getting new stuff ready to go depending on when Apple announces and releases the new bits, and whether that lines up with your conference dates.

Last year, I just threw up my hands and did evergreen topics that were largely outside the Apple sphere of influence: A/V encoding and Audiobus.

[iframe src=”https://www.flickr.com/photos/cocoaconf/12999333684/player/” width=”500″ height=”333″ frameborder=”0″ allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen]

This year, thanks to Apple backing off the NDA, speakers are free to dig into the new stuff introduced at WWDC. This suddenly transforms August’s CocoaConf Columbus from having old, crusty, but NDA-safe material, to instead being one of the first conferences that can dig into the iOS 8 technologies.

Continue Reading >>

Swift and the Last Mile

So the initial thrill of Swift is over, and lots of us are digging in. So far, there haven’t been any screaming denunciations that I’ve heard, but surely they’re coming… if there aren’t, then we’re all too easy to please.

The best thing I can say about Swift is that it’s deeply pragmatic. Rather than set about creating some beautiful, “perfect” language (or identifying one that already exists), Swift’s highest priorities include reconciling C and Objective-C and the entirety of the existing frameworks for iOS and OS X. Having to rework all those frameworks to suit some other language is presumably a non-starter, as Apple’s tried that without success three times now (the Cocoa bridges from Java, Ruby, and Python).

As I rework our iOS intro book for Swift — no, it won’t be formally announced until the publisher is convinced it’s a go, but anyone following me on Twitter knows I’ve been working hard on it for the last week — much of what Swift does for beginners pleases me. To the degree that it unifies the conventions of C and Obj-C under the guise of global functions and methods respectively, it certainly saves me from having to tell beginners “square brace idiom here, but parentheses here, because history.” And Swift’s closure syntax is far more memorable than blocks ever were; I’m already writing them by hand without resorting to the cheat sheet.

But the fact that the frameworks were programmatically adapted for Swift rather than carefully combed over introduces some new pain points.

Continue Reading >>

Dub Dub Disclosure Conference

Interesting development coming out of WWDC this year. When we all logged into the dev center to get the new iOS 8 / Mac OS X 10.10 / Xcode 6 bits, there was a new developer agreement to acknowledge. One of the few people to actually read it, Ole Begemann, noticed that it has a surprising new provision:

Further, Apple agrees that You will not be bound by the foregoing confidentiality terms with regard to technical information about pre-release Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers Conference), except that You may not post screen shots, write public reviews or redistribute any pre-release Apple Software or services

In the past, all of us developers have had to tip-toe around the new SDKs, APIs, and tools until they’re officially released, which leads to embarrassing situations like WWDC recap sessions at CocoaHeads where we say “well, if they were going to put an Obj-C wrapper around Core Audio, they might…”. This new change in policy would seem to indicate that we’re no longer compelled to engage in such silly antics.

Fry: Not sure if NDA is still on, or if I just broke it

Continue Reading >>