Notes from Swift Summit SF‘15

Some of my takeaways from the awesome talks at Swift Summit. The videos will be posted on, so you can check out all the talks when they are available.

Feet in Both Worlds: from Objective-C to Swift

Andy Matuschak (@andy_matuschak)

Prior to the talk I didn’t think it would be relevant to me. I haven’t touched Objective-C since Swift was introduced, and my project at work is 99.9% Swift. However, Swift still uses the same Objective-C runtime, and there are design decisions in Swift that are there to make interop possible. It still makes sense to understand how Swift and Objective-C interoperate.

  • @NSManaged on an NSManagedObject allows Core Data to dynamically provides its implementation at runtime, based on the associated entity description
  • @NSCopying give a property similar behavior to Objective-C’s “copy” property
  • @objc marks a declaration in Swift so that it can be used in Objective-C code

Lessons Learned: Dealing with Swift and CocoaPods

Hector (@allonsykraken) talked about his experience with Swift and CocoaPods along with some helpful tips.

  • Use dynamic library instead of static ones in Swift
  • Swift standard library is not copied when a pure Objective-C project is built. Set “Embedded Content Contains Swift Code” to true in Build Settings to prevent a runtime crash when one of your pod contains Swift code
  • With frameworks, use NSBundle(forClass: self.dynamicType) to get the bundle of that framework.

Simple Asynchronous Swift Code with ReactiveCocoa 4

Javier Soto (@Javi)

This is one of my favorite talks. My project involves a lot of interaction with sensors and servers, so I’m very interested in learning the best way to deal with asynchronous code. Futures and Promises have been great to work with, but ReactiveCocoa has been something I’ve wanted to get a feel for.

Asynchronous code is hard. We’d often want to —

  • cancel a task
  • throttle a task
  • handle error
  • retry a task
  • handle threading

iOS developers deal with these operations using very different APIs —

  • Delegates
  • Callback
  • NSNotification
  • Grand Central Dispatch
  • Key-Value Observation

ReactiveCocoa offers a unified system to work with async code because they can be represented in the same way using “event streams”. Operating on event streams with ReactiveCocoa’s declarative APIs let’s developer focus on “what” tasks are done vs. “how” tasks are done.

There’s definitely risk in adopting a paradigm that is foreign to the native iOS API, but I’ve had good experience with futures and promises. There is definitely value in these abstractions. Javier’s talk is great for introducing the benefits of adopting an abstraction to deal with asynchrony.

Working with Binary Data in Swift

Thomas Hanning (@hanning_thomas)

Great introduction on the new try-catch error syntax introduced in Swift 2.

Error Handling in Swift 2

Nick O'Neill (@nickoneill)

Quick step by step coding session that abstracts away the boilerplate code involved in storing structs persistently. Check it out on Github.

How to Build a More Compelling Watch App

Kristina Thai (@kristinathai) Slides

These quotes sum it up

Find a good use case, or don’t build it one at all


They’re like diet versions of the full smartphone app, and they make no sense on the watch — Steve Kovach

Simpler Tables with Values, Enums, & Protocols

Sam Soffes (@soffes)

Static is a wrapper that makes it a lot easier to create static table views. It seems like there’s a recurring theme of rethinking Cocoa APIs by taking advantage of new features in Swift. Table views are used so much that it totally makes sense to start there. It gets me thinking — what are some frequently used components that can be abstracted away so that we can focus more on what we want to do instead of how to do it.

Emerging Best Practices in Swift

Ash Furrow (@ashfurrow)

Another one of my favorite talks. The philosophical talk is a nice break from the code and frameworks.

Learning new languages is always fun. I really appreciate CS242: Programming Studio at UIUC for training me to be good at picking up new language/framework/paradigms. Over the course of the semester we worked on 4 different types of projects — chess game in Java, CLI in Ruby, web application in NodeJS, an iOS app as a final project. I had zero experience with Ruby or Node at that time, but I learned to efficiently pick up the syntax, tools, and best practices. To Ash’s point — don’t just stick with one language. Look a other languages. What are their best practices? Do they makes sense in Swift? Try it out and see if it feels right!

What the 55 Swift Standard Library Protocols Taught Me

Greg Heo (@gregheo)

Crusty” would be happy. Greg goes through the Swift standard library protocols and breaks them down to three categories:

  • “Can-do” protocols usually end in “-able”. Like Hashable. Describe things that the type can do or have done to it.
  • “Is-a” protocols usually end in “Type”. Like CollectionType. Describes an identity and feels like a typical class.
  • “Can-be” protocols usually end in “Convertible”. Like CustomStringConvertible. Describe the kind of transformation that can be done to the type.

Protocol seems very powerful that it becomes tricky to decide what to use it for. With these categories as a baseline I now have a better idea of when to use protocols.

Exploring Apple Pay with Swift

Wendy Lu (@wendyluwho)

Using Apple Pay as a user has been a great experience for me so far. I wished more apps would support Apple Pay so that I don’t have to type in my credit card information for every single app. It seems pretty straight forward to use Apple Pay in your app if it’s already using a payment solution.

You can find me @__simonlee__. Let me know what you think, and point out any errors in the article!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.