Swift in Seattle

I had the pleasure tonight of attending the very first meeting of the SwiftSeattle meetup group. If you live in the Seattle area and you're reading this blog, you should be at this group. I got to chat with a bunch of other developers in town, some further along than me in their Swift knowledge, and some who are just getting started.

A quick note for any Seattle Swift enthusiasts, I'll be teaching a 2-day Swift intensive with Brad Johnson and a few other learnswift contributors next weekend (June 28/29). We'll have hands-on Swift learning labs and sessions on the Swift language as well as teaching you how to use Swift with the latest stuff in cocoa / cocoa touch. If you're interested, checkout the info and signup page: link

Swift isn't perfect yet, but neither is Objective-C, Java, C# or your favorite language, becuase programming languages are software, and software is typically a journey that doesn't end untill you either run out of money or relevance.

Swift is, however, pretty great. It's as close to a spiritual successor of Objective-C that we'll likely ever see. It's attractive to absolute beginners to programming because of things like Playgrounds, but also to self-proclaimed language geeks becuase of features like type inference and tuples. It's an exciting time to be able to learn and shape a language together, rather than simply memorize the accepted patterns and practices of a language older than many of the people who program with it.

There's an excitement around Swift that I haven't felt since I first heard about Ruby on Rails in 2006. Rails had been released the previous year, and by the time I heard about it, it had gained a rediculous amount of traction and developer support. I had read all of the quotes and blurbs about how easy it was to write web applications in Rails, so I set out to find tutorials, screencasts and books to teach myself how. I was not a developer by trade at the time, and was trying to learn web development in my spare time, and after about 3 months of a couple hours a night, I realized it was super hard. I ended up getting into Objective-C about 2 years later (right after the release of the first Cocoa Touch SDK), not because Objective-C is an easy language to learn than Ruby, but because I could write a few lines of code, run it on my phone and see the changes relatively quickly, and Xcode would give me an error when my code was just flat-out wrong.

A couple years later, I decided to give Rails another go, and found that it was about 100x easier for me to learn than when I had tried the first time. Sure, Rails made a lot of improvements between version releases, but it was more about me being ready to learn. I had learned that it's ok for something to be hard, and it's ok to do something even when you feel like you're bad at it. I think most developers experience this to some extent. I'm not talking about what's often called 'imposter syndrome' but really just that sensation of getting stuck and feeling dumb.

I got stuck the other day trying to implement an AVFoundation sampleBufferDelegate, which I've done a dozen times before in Objective-C, but in Swift I spent about an hour or two longer writing it. My gut reaction was, "I'm just gonna write this in Objective-C, Swift's not ready for prime-time." At the end of the exercise, however, I realized I'd been the one making mistakes, not the Swift compiler. I managed to get it working and learned alot about the difference between pointers and refs.

My mantra for learning Swift for the next few months is

We're all just starting out, we're all gonna get better

Developers have a hard job, but don't forget that developers enjoy the luxury of a job where you're forced to learn new things every day.

Using NSNotificationCenter in Swift

I'm working on a full post for later this week, but as I sat down to write some code this afternoon, I needed to implement an NSNotification observer on a text field (namely, UITextFieldTextDidChangeNotification) and stopped for a moment to think about whether I should implement it the same way I would have in Objective-C, or if their was a more Swift way of doing things.

My initial thought was to use my go-to method for notifications, addObserver:selector:name:object: but that looked like this:

let notificationCenter = NSNotificationCenter.defaultCenter()
    selector: "textFieldTextChanged:",
    object: nil
func textFieldTextChanged(sender : AnyObject) {
    sendButton.enabled = messageField.text.utf16count > 0

and the thought of typing out a selector name in an un-checked string scares the U+1F4A9/U+E05A out of me, so I decided on the method I'm less familiar with, but the block based approach of addObserverForName:object:queue:usingBlock: seemed much more in-line with where I want to be thinking as a Swift developer.

let notificationCenter = NSNotificationCenter.defaultCenter()
let mainQueue = NSOperationQueue.mainQueue()
var observer = notificationCenter.addObserverForName(UITextFieldTextDidChangeNotification, object: nil, queue: mainQueue) { _ in
        self.sendButton.enabled = self.messageField.text.utf16count > 0

Now I'm no longer dependent on spelling the selector correctly, and I'm writing trailing closures rather than transposing the Objective-C way of doing things to a new Swift context.  

Prefer one over the other? Leave a comment and keep the discussion going. 

Back to Work

As I sit in the SFO airport waiting for my flight home to Seattle, I'm starting to come up for air, so to speak, after what has been the biggest series of changes to iOS/Mac developers since I started learning Cocoa.

The vibe at WWDC this year was a healthy mixture of feeling needed and loved on by Apple while feeling overwhelmed by Swift and the addition of all of he new features and APIs added to the Apple platforms. Many of the devs I chatted with this week are excited about swift and learning how to start transposing their existing cocoa knowledge to a new language. But because for most iOS devs, their day-to-day work is on a couple of large apps that won't be migrating to swift anytime soon, Swift is more of a long-term roadmap rather than an immediate call to action.

Read More

Custom initializers in Swift

A custom initializer saves you time and also helps you follow the MVC design pattern by allowing your model classes to encapsulate the logic needed to initialize and configure an object with some initial property values passed in as arguments, rather than returning a generic object that still needs to have its properties set before it's actually useful, like this:

Read More