Category Archives: Swift

Property Lists And User Defaults in Swift

I have written a bit about some of the work I am doing right now. Sadly, for most of this calendar year I have worked with Swift very little. I spent a lot of time working with some old open-source C libraries. Trying to yank my brain from the C precipice and trying to force it back into thinking in Swift.

My boss Brad Larson has been diving into the deep end of the Swift pool and bringing a bunch of treasures up from the bottom that I never would have considered. I am taking one of these treasures and examining how it works and what issues in our code it solves. I am hoping that by taking an elegant solution that many of us might not have thought of that we can all start thinking outside the OOP box.

The first part of this blog post is talking about some Cocoa concepts you probably are familiar with if you are not a new developer. Since I am a new developer, this stuff was new to me and interesting, so if you’ve been programming a while, you can probably skim this first section.

NSCoding, Property Lists, and Objective-C

The main piece of software we utilize at my company is SonoGuide. This is a piece of software that controls our robotics systems. Our systems print very minute amounts of liquid on a very small scale. Our positioner systems must be very precise. Our systems are rated to be accurate down to five microns. For those who haven’t worked with measurements for a while, that is 0.005 millimeters. You know, those super tiny increments on the ruler that are smaller than the tip of your pencil. So we are dealing with things that are incredibly small.

One of the pieces of functionality that we want our users to have is to be able to save coordinates. Since our systems are so precise and measure such small distances, it would be rather annoying for them to have to remember where their solution wells are in relation to the substrate they are printing on. We would like these positions to persist even if the user turns off the computer for the day and comes back next week.

It makes the most sense to keep these locations in the NSUserDefaults, which is a Property List. Property Lists, or plists, are NSDictionaries that contain different types of data. They can include arrays, strings, numbers, and even other NSDictionaries.

So we need an array of coordinate objects that we want to store in the NSUserDefaults that we are able to store and retrieve when necessary.

The way we, and everyone else, accomplished this back in the before time was as follows:

Serialization and NSCoder

While we’re still in the Way Back machine, do you remember that there was a period of time where if you looked at crash logs, you got weird hexadecimal values for where your app crashed rather than a nice, neat, human readable line of code?

The process of turning that value into a line of code is called “serialization.” The best mental explanation I have for serialization is the explanation that Mike Teevee uses to explain what television is in Willy Wonka and the Chocolate Factory:

You photograph something, and then the photograph is split up into millions of tiny pieces, and they go whizzing through the air down to your TV set where they’re all put together again in the right order.

Except instead of a photograph, you are using data and instead of it whizzing through the air, it’s whizzing through your hard drive in an area where it can be persisted and reproduced accurately.

We used the archiving functionality built into Cocoa to do our data serialization. Our persistence needs were not large enough to justify using Core Data and I think it’s possible that Core Data didn’t exist when the project was created. For a good background on choosing how to persist data, read Mattt Thompson’s post on the topic.

Archiving functionality has a few pieces. It has NSKeyedArchiver and NSKeyedUnarchiver for pushing and pulling the data. It also has NSCoder, which is where we, as the programmer, specify how to encode and decode our data.

NSCoding is a protocol that requires two methods to be written to conform to the protocol: encodeWithCoder and initWithCoder.

We implement the initialization protocol in our Coordinate class:

#pragma mark -
#pragma mark NSCoding protocol methods

- (void)encodeWithCoder:(NSCoder *)coder;
    if (name != nil) {
        [coder encodeObject:name forKey:@"name"];
        [coder encodeInteger:x forKey:@"x"];
        [coder encodeInteger:y forKey:@"y"];
        [coder encodeInteger:z forKey:@"z"];

- (id)initWithCoder:(NSCoder *)coder;
    self = [self initWithX:[coder decodeIntForKey:@"x"] 
                      andY:[coder decodeIntForKey:@"y"] 
                      andZ:[coder decodeIntForKey:@"z"]];
    if (self != nil)
    { = [coder decodeObjectForKey:@"name"];

    return self;

With this code we are simply encoding the name of our coordinate object as a key and then adding the x, y, and z locations as values.

This takes care of our issues with serializing our coordinates. The coordinates are converted into NSData, making it nice and easy for us to move it from one place to another.

So cool, we have encoded our coordinate and we can extract it by decoding it. Huzzah.

So how do we decode our coordinate?

Our coordinate is stored as NSData. We have to reach out to our NSUserDefaults, look for anything encoded with the key “savedPositions”, decode it, and bring it back here.

NSData *dataRepresentingSavedPositions = [[NSUserDefaults standardUserDefaults]
if (dataRepresentingSavedPositions != nil)
    NSArray *oldSavedPositions = [NSKeyedUnarchiver unarchiveObjectWithData:dataRepresentingSavedPositions];

If you are interested in learning more about the NSCoding process, read this amazing blog post by Mike Ash.

Problems With This Approach

If you have learned anything about archiving data, this is the method you were probably taught. I did this myself while I was working through the Big Nerd Ranch guide to iOS programming. This is the standard. What is wrong with it.

Quite a bit, actually.

NSData isn’t inherently safe.

NSData is basically grey goo. It is a large clump of bits and bytes that have things fed into it and pulled out of it.

In our dataRepresentingSavedPositions we are simply pulling out any values associated with the key savedPositions. We are trusting that the data we are pulling is the kind that we want. It’s possible that our users have gone into the defaults property list and changed something. It’s possible that a hacker has gone and replaced one of our coordinates with a malicious executable file. We don’t know. There are no safety checks to ensure that none of these situations occur because when we serialized our data, we lost its type information. We’re living on a prayer here.

NSCoder can only be applied to an object inheriting from NSObject.

The way we structured our Swift code, we take advantage of the enhanced features of structs and enums. Our structs cannot comply to the NSCoder protocol because the only things that can are objects that inherit from NSObject.

In Mike’s article about implementing NSCoding, he mentions that if you want to encode a struct, you can’t encode it directly because it breaks. You need to break a struct down into its base components if you want to store and serialize them.

Since Apple has made it rather clear at this most recent WWDC that they would like us to start moving away from making everything an object, it doesn’t make a lot of sense for us to completely rewrite our code to start making our coordinates objects rather than structs.

Basically, NSCoder is build around the idea that you will only work with and encode objects, which is not how many of us program anymore.

A Swift Approach

Since we can’t really do our serialization and archiving the way we did them in the previous version of the code, how did we approach and solve this issue?

I will go over the various components of this code.


Right off the bat, we are creating our coordinate as a struct and not an object:

struct Coordinate {
    let x:Double
    let y:Double
    let z:Double

    init(_ x: Double, _ y: Double, _ z: Double) {
        self.x = x
        self.y = y
        self.z = z

Since we know from earlier that we can’t associate NSCoder with our Coordinate struct, we need to figure out another way to deal with it. We used a protocol.


protocol PropertyListReadable {
    func propertyListRepresentation() -> NSDictionary

Since property lists are just NSDictionary objects, we need to make sure that anything that conforms to PropertyListReadable is able to create and take in NSDictionary objects.

Since we can now extend structs with protocols, we are able to take the PropertyListReadable protocol and extend the Coordinate struct:

extension Coordinate: PropertyListReadable {
    func propertyListRepresentation() -> NSDictionary {
        let representation:[String:AnyObject] = ["x":self.x, "y":self.y, "z":self.z]
        return representation

    init?(propertyListRepresentation:NSDictionary?) {
        guard let values = propertyListRepresentation else {return nil}
        if let xCoordinate = values["x"] as? Double,
               yCoordinate = values["y"] as? Double,
               zCoordinate = values["z"] as? Double {
                   self.x = xCoordinate
                   self.y = yCoordinate
                   self.z = zCoordinate
        } else {
            return nil

The propertyListRepresentation function works under the assumption that a Coordinate instance was already able to be initialized with the correct number and types of parameters. This function goes through the Coordinate instance and sets key-value pairs for each of the axis and returns an NSDictionary. This function allows you to take any and all Coordinate instances and format them in such a way that they can be saved to the NSUserDefaults.

There are some situations where you want to go the other way. You have extracted an NSDictionary from the NSUserDefaults and you want to break it back down into a Coordinate instance. Since you can’t be certain that the data you are pulling from the defaults is in fact a completed coordinate, you need to use a failable initializer. You also need to make sure your return value is optional because if you were pulling data associated with a string you don’t want to crash your app by trying to process nonsense.

In our first line of code, we are implementing the shiny new guard statement. Since many of you may not have had time to dabble with guard, let me walk you through how we are using it and why.

Our goal with this initializer is to create a Coordinate with values we have extracted from the user defaults. Before we try to set each of our axis to a value, we want to make sure a value even exists. That is where guard comes in.

We are checking to see if our optional parameter was passed in or if we have nil. If we have nil, we don’t want to have to go through a bunch of conditional logic to verify that yes, we are doing nothing with our value. A guard statement only executes a line of code if the condition is not met. We want to return nil if we know that no parameters were passed in, so we can cut to the chase and do that immediately at the beginning of our block of code.

Once we have established that our NSDictionary was not nil, we now go through each value in the dictionary to make sure it correlates to a specific key. If at any point we encounter a key that does not have a value, we kick out of the whole thing and return nil.

By using a protocol to implement this functionality, we are able to specialize and reuse these concepts for other value types in our software. Before, we would have had to make a superclass or a delegate with methods that were required to be overridden by the subclass. By allowing structs to conform to protocols, we are able to specify functionality that we need in multiple places but with different implementation.

Map, Filter, and FlatMap

It would not be a shiny Swift blog post without the obligatory section on the functional features of Swift.

Just to clarify where we are at at this point in the code. NSUserDefaults is an NSDictionary where the key is the name you assign to label what you want to store. In our case, we want to store saved coordinates, so our key is “savedPositions”. The value is an array. The array can contain any object. Our Coordinate is not an object because it’s a struct, which is why we convert it to an NSDictionary. So, in theory, our NSUserDefaults should have a key-value pair where the key is “savedPositions” and the value is an array of NSDictionary objects that represent Coordinates. Simple, right?

Wouldn’t it be really cool to be able to filter through the array we pull from the NSUserDefaults to make sure we have an array of only the objects of the type we want? Sadly, there isn’t.

Of course there is. If there wasn’t then either that sentence wouldn’t be there, and or I would be a sadist. The jury is still out on that last conditional.

func extractValuesFromPropertyListArray(propertyListArray:[AnyObject]?) -> [T] {
    guard let encodedArray = propertyListArray as? [NSDictionary] else {return []}
                       .filter{ $0 != nil }
                       .map{ $0! }

In the extractValuesFromPropertyListArray function, we are accepting an optional argument of an array of any object and returning an array of our generic return value. We also are specifying our generic return value must conform to the PropertyListReadable protocol.

The first thing we need to do is make sure we actually received a value. If we didn’t, there is no point in filtering an array that doesn’t exist. Our first line of code checks to see if we have a value and if that value can be cast to an array of NSDictionaries. If we don’t or we can’t, we return an empty array.

If that passes, we go ahead and filter the array. We use the .map function (which iterates through an array, applies a function to it, then creates a new array from the results) to run each value through our propertyListRepresentation initializer we created in our Coordinate extension. The propertyListRepresentation either returns an optional Coordinate or a nil.

We then apply a .filter to our results. We check to see if each item in the array is not nil. If it is nil, we throw it away. We then create a new array of just optional Coordinates.

Finally, now that we have ensured that we don’t have any possible nil values, we use another .map to unwrap each value and return and array of Coordinates (or any other structs we extend with the PropertyListProtocol).

This is really inefficient.

The function extractValuesFromPropertyListArray was refactored to the following:

func extractValuesFromPropertyListArray(propertyListArray:[AnyObject]?) -> [T] {
    guard let encodedArray = propertyListArray else {return []}
    return{$0 as? NSDictionary}

It was a real shame in our previous version of the code that if we had an array of mostly NSDictionaries, but if some stupid NSData object (which could be a malicious program) somehow snuck into our array, we had to throw away all of our other valid values. Since we’re going to filter through our results later anyway, we just want to verify we have an array of anything.

Since we don’t filter for NSDictionaries in our first line of code, we need to move the filter to our second line. Now our first .map statement is checking to see if each item can be cast the an optional NSDictionary. If it can, it gets added to the new array. If it can’t, it gets kicked to the curb.

Our previous code had a convoluted setup to be able to apply a function, filter out the nils, then unwrap the coordinates. This is a common enough thing that there should be a more concise way to do this. There is, and that is using .flatMap. Flat Map does exactly the same thing as our previous three chained functions in one handy dandy function call. Huzzah!

Saving to Defaults

We have one last part left to our property list loading and unloading. We’ve verified that everything we are extracting to the defaults is safe. We now have to verify that everything we are sending out to the defaults is safe.

One last little block of code:

func saveValuesToDefaults(newValues:[T], key:String) {
    let encodedValues ={$0.propertyListRepresentation()}
    NSUserDefaults.standardUserDefaults().setObject(encodedValues, forKey:key)

For our parameters, we are taking an array of values that conform to T:PropertyListReadable and a string value to use for our key.

We’re creating an array of encoded values by taking the array parameter and mapping each one using the propertyListRepresentation function to turn it into an array of NSDictionaries. We then run the result through the setObject:forKey function associated with the NSUserDefaults.


I created a playground that contains all of the code I spoke about in the second half of this post.

When Brad showed me the extractValuesFromPropertyListArray function, it made my head explode. I saw the .flatMap() function and the guard statement, I felt stupid and inadequate. I felt despair that I would ever be able to come up with this stuff on my own. I can look at code and kind of grok what it means, but reading and understanding something are different than actually coming up with it.

After a while of struggling with the code, I realized I was asking the wrong questions about it. Rather than asking “how” it worked, I should have been asking “why” it was written that way. I talked to Brad about how we were dealing with the user defaults in the original code. He told me about the issue he had with it that I detailed in the first half of the post.

That is when a lot of this stuff began to click into place for me.

We don’t have this complicated code because we’re trying to be clever and use all the new toys in Swift. We are doing the code this way because it solves a problem that we had that could not be solved with Objective-C.

We could have used a “for-in” loop instead of the .map() function. We didn’t have to use .flatMap(), we had a longer implementation of it.

I have been approaching learning Swift all wrong. I was trying to take concepts like currying and trying to find ways of cramming them into my code so that I could understand how they worked. Our code is elegant because it had a specific set of problems it needed to solve that either were not solvable any other way, or would have resulted in more lines of code that would have taken more time to run because it wasn’t optimized.

For me, I took two lessons from this:

  1. Instead of spending more time thinking about clever ways to use shiny new features, I should spend some time thinking about what problems I had to solve.
  2. Just because my code “works” doesn’t mean it can’t be better. There might be “easy” ways to get something running, but there might be better, more elegant ways to write your code.

Yes, it’s overwhelming keeping up with all the new language changes and feature out there, but there can be great features that can make your code better that you never discover if you just decide your code is done once it compiles.

The Trick to Forgetting the Big Picture is to Look at Everything Close-Up

Any sufficiently advanced technology is indistinguishable from magic.
– Arthur C. Clarke

Back when I was a programming student, my teacher Eric told me that over the years he has learned and forgotten a dozen programming languages.

At the time, it was inconceivable to me that anyone could learn and forget so much. Two years later, I am shocked to discover that he was right.

Two years ago when I really doubled down on learning iOS programming, I worked on it eighty hours a week. I was working through the Big Nerd Ranch iOS book. They had a series of about five chapters putting together a table view that would display a detail view populated by a singleton.

Every day I would wake up and code this over and over again. The first time I coded the examples, they made no sense. I typed a bunch of words that didn’t set off the compiler warnings, ran them, and magic happened. The second time was not much better. But by the third for fourth time, I began to realize, “Oh, I am creating this object because later when I load this detail view, I will be showing all the stuff I am keeping in this object. This is where it comes from.”

At the time Storyboards Interface Builder wasn’t particularly good for things. If you listen to many people online, their assessment of this situation has not changed. I used .xib files for each of my view and my custom cells and did all of my transitions programmatically. It took me weeks to wrap my head around all of these moving parts to figure out how they worked together. It wasn’t enough for me to just have something work, I really wanted to understand it.

Over the last year and a half, I haven’t really worked with user interfaces much. I had a contract job where there was no UI in Interface Builder because it was a legacy project from 2008. Then I spent a bunch of time running around like a chicken with my head cut off trying to figure out shaders, which are a tiny subset of a program. Then for the last eight months I have been working on porting another legacy project to Swift. We are just now getting to the point where I am working with interfaces again. It’s been over a year since I dealt with interfaces.

I am working on my first application. It is going to be rather limited to start off with, but I have plans to add additional functionality over time, so whenever I finally get it out, no, that is not the final product, more will come later, so don’t give me crap about it.

I am working with HealthKit. In HealthKit, there is a HKHealthStore that you are only supposed to have one instance of in your entire application.

I have been trying to figure out where to make that instance. I know that it needs to be accessible through the entire application and that you’re not supposed to make a bunch of instances of the same thing. I also know you have to pass it along to a lot of different places. I know many people don’t like singletons and I don’t want to create one of those, even though I am pretty sure HKHealthStore is a singleton. I was trying to figure out how all of the controllers can know about something while minimizing global state.

I talked to Brad about this a bit and he was talking about how it should be created in the root view controller for the application because that is responsible for the views that are controlled by it. As he was talking about all this stuff, it dawned on me that he was talking about the same things I was bashing my head against two years ago.

It wasn’t like I had spent a week mucking around with this stuff. I spent eighty hours a week for MONTHS trying to piece together how all this crap worked. I can’t believe that after spending all that time and pain on these concepts that they were buried in some far corner of my brain.

It also made me wonder about all the people who are learning programming now who use storyboards because, honestly, they are easier to get things done quickly. If you just push a couple of buttons and things happen like magic, how do you get a full understanding of what is actually going on? It makes me wonder about what else I don’t know about because I came into programming relatively recently. I know that my knowledge of memory management is bad because it was never something I had to deal with. I came in around iOS5/iOS6, so we had ARC and GCD and a lot of other things that abstract out a lot of the lower level programming stuff from you. Will understanding how root view controllers own detail views go the same way? I know talking to a guy at my first job he didn’t seem to understand this concept and it drove me crazy. I guess I have gotten to the point where I don’t understand it either.

It frightens me about how vast the knowledge is of everything that happens within the iOS ecosystem and how incredibly difficult it is to remember everything because really delving into the low level stuff means that you don’t know how to get things done quickly in the abstracted level. Sticking to the abstracted level limits your ability to do anything really customizable because you don’t see how the pieces fit together.

I am hoping that over the course of the next few years I can figure out a balance that works for me. I hope I can remember enough about how things work that I can deal with the abstracted layer without fundamentally forgetting everything.

What’s an Object?

I was editing my interview with Orta Therox yesterday when I realized I mentioned asking my boss Brad Larson what an object was.

I realized when listening to this that I hadn’t given any context because I wasn’t anticipating talking about that during the interview and I come off being rather ignorant in the course of this question. So, to avoid having to turn in my nerd card, I am going to give some context and give a more nuanced explanation behind that question.

My Personal Background with Object-Oriented Programming

I started going to school in 2010 for computer programming. I was 28 and I had almost no experience whatsoever with computer programming. My background was writing HTML when I was in high school and learning how to compile “Hello, world!” in Perl. At the time I enrolled I was working at Target because I failed to find a journalism job after I graduated and I really didn’t want to work at Target for the rest of my life. Programming seemed like it would be a good fit and it didn’t seem like it was going anywhere for a while.

I got through my first semester of introductory programming okay. Starting in your second semester, you had to pick a language to study for the next three semesters. At the time I was making this decision, there were three languages to pick from: Java, PHP, and VB.Net. I decided I would pick whichever one fit into my work schedule. The one that fit was VB.Net.

Our introductory class kept getting further and further behind. By the time we got to the end of the semester, we had never spoking about object-oriented programming. It was something we were supposed to do, but we just never got around to it.

The following fall, I took the advanced class. It was a night class, which I don’t really do well with anyway. The first class period, my teacher showed me object-oriented programming for the first time. I had no idea what the fuck he was talking about.

A bunch of code was in other files! How did it work together? How does the computer know to look in these other files?? Wait, what the hell is polymorphism? Am I having a bad acid trip??

After three hours of this, the teacher said since this was all review he was never going to go over any of this ever again. That was when I realized I was kind of screwed.

I decided to drop out after I asked what a constructor was and the teacher asked me if I learned anything the previous semester. At this point I had a decent job with people that I liked. I figured I was too stupid to learn programming because I wasn’t born with an intuitive sense for it and I was tired of feeling stupid all the time.

Six months after this, I took a new job that was the most miserable job I have ever had. The plus side to this job was that I taught myself programming while I was there. I realized I hadn’t put enough effort into it and if I just programmed forty hours a week I could learn it. So I went back to school.

I finally grokked OOP when I took the Intro to Java class. They introduced objects immediately and forced you to use them throughout the whole semester so you could get used to them. I started to understand about file paths and how the program knew how to find your other classes and how you imported them and how you constructed them. I felt like after I understood this for the first time that I was a “real” programmer. I hadn’t felt that way before grasping object orientation.

OOP is Not the Only Paradigm

I went from Java to iOS/Cocoa/Objective-C programming. I had a few vague issues when I was learning Objective-C with trying to pass around things that weren’t objects. Rather than really think about it at the time, I just got annoyed and turned all of my ints and floats into NSNumber objects to shut up the compiler.

Here is a sample header file you might commonly make if you were creating an Objective-C project:

@interface MyViewController ()
@property (nonatomic, strong) UIImageView *backgroundImageView;
@property (nonatomic, strong) UIImageView *blurredImageView;
@property (nonatomic, strong) UITableView *tableView;
@property (nonatomic, assign) CGFloat screenHeight;

In my experience with Objective-C, everything was an object. You created classes, which were objects, and you populated them with instances of other objects and in turn instantiated your new object in instances of UIViewController objects.

You had header and implementation files. The name of your class was the same as the name of your implementation file. Every file has a class. This is what programming is. It’s objects all the way down.

My first experience with understanding that this wasn’t the only way of doing things came several months ago. I was working on translating a plug-in we were using to a piece of code we kept internally. I had a weird method I was dealing with that wouldn’t compile.

After fighting with it for a while, I took it to Brad and asked him what I was doing wrong. He told me I was treating the function like a method. This statement kind of blew my mind because I thought that methods and functions were the same thing. I thought we called functions methods in Objective-C the same way that Java interfaces were the same thing as Objective-C protocols. (Yes, I am aware I am probably wrong about this as well. I am still learning.)

I didn’t know that there was a difference in Objective-C between functions and methods. Functions exist outside of classes and methods are functions that are embedded in a class. I hadn’t really thought about this or why anyone would want to do that. I simply assumed that all functions were methods and everything had to be encapsulated in a class.

This was only the tip of the iceberg.

Becoming Functional

Back in November, Brad went away for a week for a trade show. We were planning to rewrite all of our control software in Swift and he wanted me to take a look at the code he had written so far to make sure that I understood it.

What I saw completely broke my reality.

He has posted a sample project on GitHub including some of the code I looked at initially. Here is a small sample of what I saw that changed the way I think about programming:

import Foundation

// MARK: -
// MARK: Error protocols

public protocol ErrorType {}

protocol PresentableError {
    var errorTitle: String { get }
    var errorInfo: String { get }

// MARK: -
// MARK: Error types

enum CommunicationsError: ErrorType, Printable, Equatable {
    case ReadWriteTimeout
    case WrongByteCount(expectedByteCount:UInt, receivedByteCount:UInt)
    case CorruptedResponse(expectedResponse:[UInt8], receivedResponse:[UInt8])
    var description : String {
        get {
            switch (self) {
                case .ReadWriteTimeout: return ".ReadWriteTimeout"
                case let .WrongByteCount(expectedByteCount, receivedByteCount): return ".WrongByteCount(expectedByteCount:\(expectedByteCount), receivedByteCount:\(receivedByteCount)"
                case let .CorruptedResponse(expectedResponse, receivedResponse): return ".CorruptedResponse(expectedResponse:\(expectedResponse), receivedResponse:\(receivedResponse)"

enum ElectronicsError: ErrorType, Printable, Equatable {
    case ElectronicsDisconnected
    case UnrecoverableCommunicationNoise
    var description : String {
        get {
            switch (self) {
                case .ElectronicsDisconnected: return ".ElectronicsDisconnected"
                case .UnrecoverableCommunicationNoise: return ".UnrecoverableCommunicationNoise"

// MARK: -
// MARK: Equatable protocol compliance for these errors

func == (lhs: CommunicationsError, rhs: CommunicationsError) -> Bool {
    switch (lhs, rhs) {
        case let (.ReadWriteTimeout, .ReadWriteTimeout): return true
        case let (.ReadWriteTimeout, _): return false
        case let (.WrongByteCount(expectedByteCount, receivedByteCount), .WrongByteCount(expectedByteCount2, receivedByteCount2)):  return ((expectedByteCount == expectedByteCount2) && (receivedByteCount == receivedByteCount2))
        case let (.WrongByteCount, _): return false
        case let (.CorruptedResponse(expectedResponse, receivedResponse), .CorruptedResponse(expectedResponse2, receivedResponse2)): return (equal(expectedResponse, expectedResponse2) && equal(receivedResponse, receivedResponse2))
        case let (.CorruptedResponse, _): return false

func == (lhs: ElectronicsError, rhs: ElectronicsError) -> Bool {
    switch (lhs, rhs) {
        case (.ElectronicsDisconnected, .ElectronicsDisconnected): return true
        case (.ElectronicsDisconnected, _): return false
        case (.UnrecoverableCommunicationNoise, .UnrecoverableCommunicationNoise): return true
        case (.UnrecoverableCommunicationNoise, _): return false

The name of this file is ErrorTypes.swift. There is no ErrorTypes class. There is nothing in this file named ErrorTypes.


We have several enums, which are not objects, that we are references for type conformity. We have UInts, which are not objects. We also have functions. Lots and lots of functions. That aren’t associated with a class. They’re just out there like llamas roaming free.

When I tried to understand this I felt like I went to a party and someone asked if I wanted to use another person’s liver. I didn’t know if was possible to call functions that were not associated with a class instance. I had never seen anything like this before. I couldn’t believe this would build and run and compile just fine. I felt like I fell down a rabbit hole and nothing made sense anymore.

Reorienting Myself with Reality

I, like many people, learned programming in the age of Imperative Programming. Java has been around for twenty years and many people learned programming with Java. A lot of us don’t know anything except the Object Oriented way of doing things. To many of us, this is what programming is.

It doesn’t have to be.

One reason I am so vocal in my defense of Swift is because this realization has completely changed my reality. I used to think there was only one way of doing things. Well, I won’t say that. There was one right way of doing things and then there was the “Dear god, what is this person thinking by having this property controlled in four different places?!” way of doing things.

Being exposed to Swift and seeing that you don’t have to put everything in a class has been a revelatory experience for me. It is forcing me to reevaluate everything I know about programming.

I never thought about what an object was before because there was no point because everything was an object. Now, I am trying to get a better understanding of what an object actually is. I wrote about the difference between structs and classes and at the time I really didn’t understand why you would want to use a struct instead of a class if they essentially do the same things. I now understand that you want to try to use structs when possible because they aren’t objects. Objects come with a lot of overhead. They let you do some more powerful things like subclassing through polymorphism, but you don’t always need to do those things. Looking at how powerful the enums are that Brad uses in his code, I am fascinated by how confined my own view was when I thought everything had to be an object and exist in a class.

So yes, I did ask what an object is. I know most programmers worth their salt can tell you the definition of what an object is, but I don’t think many of them stop to think about why we use them and if they are the best way of doing things. Or if they bother to wonder if objects are the only way of doing things.

Wrapping libxml2 for Swift

I have spent the last month or so working on a project where I am wrapping a legacy C toolkit, libxml2, in Swift. I have created a sample project here where you can obtain wrapper classes written in Swift allowing you to utilize libxml2 into your code without having to touch C.

My job at SonoPlot is to write control software for our robotics systems. One of our included pieces of software is a CAD program for users to use that creates XML pattern documents that that are parsed by our control software so that it can tell the robotics how to draw a pattern.

Since some of our pattern files can be very large and complex, it was important to us to be able to use the fastest XML parsing we have available. I benchmarked three different ways of parsing XML:

  • Tree-Based Parsing using NSXMLDocument
  • Event-Based Parsing using NSXMLDocument
  • Tree-Based Parsing using libxml2

I had wanted to include event-based parsing with libxml2, but that utilizes C function pointers, which are not currently possible with Swift.

I have included the profiler in my sample code for this project, but in case you don’t feel like running it yourself, my benchmarking showed that using libxml2 was four times faster than tree-based NSXMLDocument parsing and three times faster than event-based NSXMLDocument parsing.

Clearly, there is a large difference between using libxml2 and any permutation of NSXMLDocument.

What is libxml2?

libXML2 is a toolkit for parsing XML that is written in C. Back when the first iPhones came out, libXML was highly utilized because it was incredibly fast and the first iterations of the iPhone were not particularly powerful.

As the iPhone has become more powerful and the number of frameworks has become more robust, libXML2 has fallen out of use. Since it is a C toolkit, you are taking responsibility for your memory management. It wasn’t written for a specific language, so it is rather sprawling and has a lot of obtuse documentation. It’s also rather old. When I was looking into it they had sample code written in Pascal.

Basically, as things like NSXMLParser and the use of JSON became more prevalent and easier to work with, there hasn’t really been a need for most people to bother with this difficult toolkit.

Hooking Up libXML and the Wrapper Classes

libXML is included on your machine, but it isn’t included by default in Xcode. It will need to be important and linked to your project for Xcode to be able to see it.

Go to your project and find your Build Settings in your Project. Search your Build Settings for “Header Search Paths”. In your project’s search paths, add the following:


While still in your Build Settings, search for “Other Linker Flags.” Add this line to your linker flags:


Now go to your Targets and find your Build Phases. Find the tab that says “Link Binaries with Library”. Click on the “+” sign to load a new library to link to the project. Search for “libxml2.” There should be two results. Add both of those results to your project.

Lastly, you will need to import an Objective-C bridging header into your project. The Objective-C bridging header is a file that exists in this project, so you just need to drag it from the sample project over to your project.

After the bridging header is added to your project, go back to your Build Settings and search for “Objective-C Bridging Header”. You will need to add a line that has your project name and the bridging header name in it. For example, in the sample project LibXMLWrapperExample, the line added to the bridging header was:


A really good README going over this process is here. If any of my steps aren’t clear enough or something isn’t working quite right, use this as a backup for the instructions to hook this up. It can be incredibly obtuse and easy to forget one little step and have the whole thing not work.

Also, the way that I verified this worked was to look at a project I got this working on and I searched both the Target and the Project for “xml” to see where I had added search paths and linker files. This is a good way to do a sanity check to make sure that you didn’t forget anything.


The first wrapper class I created is the simplest one: LibXMLDoc. In XML, you have a tree that is made up of nodes. In libxml2 all of the nodes are contained in an xmldoc. You need two things from the LibXMLDoc class : a document and a root node. Once you are able to extract the root node, you are able to traverse the entire tree to find anything that you are looking for.

Since we are dealing with C, we are responsible for our own memory allocation and deallocation. I had to remember to deallocate the LibXMLDoc when we are done with it.


The second class, LibXMLNode, is where we do a lot of the heavy lifting. This class is responsible for finding and extracting values from our XML document.

The first property I needed to set up was nodeName. nodeName is going to be the primary way we are going to be accessing and dealing with each node, so this is a pretty important value to have easy access to.

Since libxml2 is a C toolkit, the type we are receiving is going to be a C string. The other thing complicating this is that libxml2 is set up to deal primarily with pointers to their node and document objects. We need to take a pointer to a C string and somehow do some alchemy on it to convert it to a Swift string. Swift strings have a method on them called “fromCString” that I was able to use. Also when dealing with C string types, you need to use unsafe mutable pointers. I also had to figure out how to navigate through a C pointer to access the actual values that they were referencing.

I was able to get this all down to one line of code that did all of these things:

return String.fromCString(UnsafePointer(!

From there, I needed to think about what we need to do with a node. Every node we encounter is generally going to be one of two ways:

  • It will be a parent node that contains children nodes but no value.
  • It will be a child node that might contain a value but has no children.

I set up two lazy properties in the LibXMLNode class to deal with these two eventualities: nodeValue and nodeChildren.

nodeChildren takes a LibXMLNode as a parameter and iterates through that node’s children until it encounters “nil.” It then returns an array of LibXMLNode objects.

The first time I wrote this code, I was getting many more nodes than I was expecting to get. By printing out the array of node children I found that every other node was a node, which mean that if I was expecting five children nodes, I was actually receiving eleven, because the first and last nodes were nodes and every other node in between was also . This was rather inconvenient, so I found a libxml function that checks to see if the node is a node. If it is, the function returns 1. I do a check on each node and if the function returns 0, the node is added to our LibXMLNode array.

nodeValue covers the other contingency where you have a node that contains a value that needs to be extracted. Since it is possible to have empty XML tags that do not contain values, this property has to be optional. We need to extract the value and look inside to see if we have anything in there.

I used the libxml2 function “xmlNodeListGetString,” which takes a document, a node’s children, and their index as parameters and returns either a C string or nil. If there is a value, we use the code we used in the nodeName function to extract a Swift string, we free the C string, and we return the Swift string. If the function returns nil, we return nil.

Raiders of the Lost ARC

So I was all excited that I figured all of this stuff out and I was ready to start testing my classes. I wrote a bunch of tests that all failed immediately.

While looking over the tests, I realized that every time I tried to access any of the properties on the root node, they were failing because the root node didn’t exist.

I was becoming incredibly confused and frustrated when Brad had me add a println() in LibXMLDoc between when we initialize the document and when we initialize the root node. It turns out that ARC was deleting the LibXMLDoc immediately after it was being initialized because it wasn’t being held on to or referenced anywhere. D’oh!

In libxml, the document controls the memory for all of the nodes, not the nodes themselves. Basically the way I was writing the code was that I only referenced the document once, where it gets initialized. From there, since there were no other references to the document, ARC deleted it along with all of the nodes it contains.

That was a problem. Since the document contains all of our nodes, we really need it to stick around until we are finished with extracting all of the nodes and their values. We have to create a LibXMLNode instance in the LibXMLDoc class to hold the root node, we couldn’t just have the LibXMLNode class point to the LibXMLDoc class. We had to have them point to one another without creating a retain cycle, so the LibXMLNode class has a strong reference back to the LibXMLDoc class to prevent the instance from being deallocate before we are done with it. I then went back to LibXMLDoc and make the reference to the LibXMLNode a weak reference to avoid a retain cycle.

There is still some juggling that needs to be done in order to make sure we are able to prevent the document from being eliminated and that we are able to get the root node.

The solution utilized here was to replace the strongly referenced LibXMLNode root node with a private, internal weak root node and a computed property checking to see if this internal root node has been set yet. If it has, it is returned. If it hans’t, we extract the root node, set it to the internal root node, and return it. Since computed properties are basically methods that look like properties, for all intents and purposes we are replacing a strong reference with a weak reference and a method.

We are trying to resolve a few things by taking this path. First, we are trying to avoid having the root node and the document deallocate before we can use them. Second, since we are using a class and a class is a reference type, we want to make sure that we only create the root node once rather than having a bunch of instances all pointing back to the same memory location.

And this, kids, is why you still need to think about memory management and ARC even if you started coding after iOS 5, like I did.

...and knowing is half the battle!

…and knowing is half the battle!

Adding Bundled XML Files

The last part of this sample application that I want to cover is including XML files rather than accessing them from an internet URL.

I have included in my sample project a relatively simple pattern file generated by our CAD program to use as an example.

One thing you have to remember to do when you include an XML file with your program is that you have to include it in the application bundle. I have included a convenience function in the LibXMLDoc class called “bundleForResource” that takes the the resource name and returns an NSURL. This can then be passed into the parser where it asks for the URL of the resource.

You also have to make sure that your file resource shows up in “Copy Bundle Resources” in “Build Phases.” My original attempt at creating a sample project was trying to make this a command line application, but I wasn’t able to copy the bundle resources (because there was no bundle) and it generated an IO error.

The last convenience function I included in the LibXML wrapper classes is the “outputXMLTree” function. This function is recursive and it walks through the document tree checking each node to see if it has children or values. I am using this function in the App Delegate to demonstrate the the classes have in fact parsed the included document correctly.


Before attempting to work on this project, I decided I was going to avoid dealing with C in Swift as much as humanly possible. Considering the nature of what we do here, where we use serial communication in C with our control software, that was an incredibly stupid and wrong-headed way to approach things.

Yes, it is a little more complicated. It required some more work, some tenacity, and some help from my boss who has been around the block a few more times than I have. As much as part of me would like to not think about it, C isn’t going anywhere. I want to work with micro controllers and firmware in the future and deciding not to get C to play nicely with Swift is basically a non-starter for the projects I would like to do.

Even if you think that XML parsing is as boring as dry toast, hopefully the code will help you with figuring out how to integrate older C code into your projects or at least give you a clean way to add better XML parsing to your applications.

Again, the sample code associated with this post is here.

Hit me up on Twitter if you have any questions about it.

Functional Programming in Swift: Chapter 3 – Wrapping Core Image

**Note- I originally took this post down because I wasn’t really happy with how I organized it. I also believe that this series has a larger readership than I originally envisioned and I felt that the assumptions I made about this post were confusing. I am going to repost this post and figure out how to proceed in a way that is useful to everyone who is reading my blog. **

I am writing a series of blog posts analyzing the code and concepts from each chapter in Functional Programming in Swift. I am assuming if you are reading this that you are following along in the book, so I am not references their specific code snippets in my blog.

The purpose of this chapter is to show the reader how to do a very important thing in programming, which is wrap a framework or an API written in another language, such as C.

Being able to integrate lower level code into your applications is a really important skill to be able to master. Over the last month I have had a project where I had to write a few wrapper classes around XML-parsing functionality in the C library libxml2, which I will write about in a later blog post. Learning how to search the sparse documentation for this library and figuring out how to integrate it with Swift was a really interesting and painful learning experience. Even though a lot of times I wanted to hang my head and weep in despair, after I got it working I felt kind of like one of those douchebag programming ninjas that recruiters keep contacting me looking for.

This might not be the best sales pitch for why you should care about this stuff, so without further adieu, I will get to the content.

Core Image

Even though the focus of this chapter wasn’t specifically on learning Core Image, I wanted to take a moment to talk about it because it’s a neat little framework.

Core Image is a framework that allows you to add filters to photos in both iOS and Mac applications. Core Image is very similar to GPUImage, except GPUImage is open source, so you can go in and actually see how all of the shaders were written. Core Image has a few more filters than GPUImage has. In iOS 8, Apple opened up the ability for you to write your own Core Image filters, which wasn’t possible before.

Core Image is, as my coauthor Chris Adamson calls it, “stringly typed.” If you want to use a filter from Core Image, you have to reference it in a string. If you spell the filter name wrong then your project will fail silently. Whereas you can use auto-complete on other parts of your project to ensure that you don’t get felled by spelling errors, there is alas no auto-complete in Core Image.

If you’re interested in how to write shaders for either Core Image or GPUImage, I recently wrote an article about it for Objc-io. There are a lot of other neat photo articles in this issue too, so be sure to go check it out if you want to know more about how to use photos in your iOS/Mac applications.

But enough of my own buzz marketing, on to the actual content of the chapter…

Wrapper Type

Generally speaking, Core Image has a rather repetitive pattern. You take an image, filter it, then you take that result and feed it to the next filter you are using.

If you’ve ever used Core Animation or another framework that affects the output of what goes on your screen, you will know that the order you implement your changes in affects your output. The same thing goes for your image filters. If you add more than one filter to an image, changing the order will change what the output image looks like.

Since you are using a filter chain where you are taking the output of one operation as the input of another, it makes sense to encapsulate this functionality into its own type. In this case, the type is a function that takes a CIImage and returns a CIImage.

CIImage filters all take different types of parameters. Some filters only take an image as a parameter while other ones many more. We want to be able to customize our filter functions to take the correct number of parameters. Regardless of what kind of filter we are making or how many parameters they take, we want each of our new custom filter functions to return a function that conforms to the Filter type alias. Naming this function type makes our code cleaner and safer by assigning a name to it and removing code we would have to write over and over again.

Convenience Initializers and Computed Properties

We want to make it easier to extract the output image so that we can chain this filter’s output image to the input of the next instance of our CIFilter class. We are using a convenience initializer and a computed property to extend the class to customize it for our needs.

The class extension has three pieces we are going to look at: a convenience initializer, a computed property, and a typealias representing a dictionary that holds our Core Image parameters.

Any time we create an instance of a class or a struct, we have to handle initializing it. Back in Objective-C we had our pattern of [[NSString alloc] init] to initialize our instances. We still have to initialize our instances, but like many thing in Swift, this process has been simplified. Instead of the long, verbose way of initialization, we just use “()”, which is a void function call. This initialization function is void by default, but life wouldn’t be very interesting if we couldn’t customize things to suit our needs.

Just because the default initializer is a void function does not mean that it always must be. If we have want to pass in parameters to the initializer, we can do so. In the example used in this chapter, we are trying to customize the CIFilter class. We are doing that by extending the class to include the functionality we need.

The normal CIFilter initializer just takes the name of the filter being used. We want to initialize the filter with the dictionary of parameters along with the name. In order to make it easier and clearer what we are doing, we are typealiasing the dictionary of parameters and passing that type into our convenience initializer. Within the convenience initializer, we are calling CIFilter’s designated initializer, essentially wrapping the base CIFilter initialization within another function that allows us to do more.

The last piece of our extension is a computed property, which is our coveted output image. We are treating an outputImage property that is of type CIImage and instead of just setting it to a CIImage, we are checking the value for the key that we are using (which in this case is the name for the CIFilter we want to use) and returning a CIImage.

Computed properties are interesting. They do not store a value. Instead, they are a getter to find and set properties and values indirectly. It is my impression (which, if wrong, I would really appreciate someone correcting for me) that they are similar to functions but with slightly less overhead. Natasha The Robot says in this post that a computed property is a function disguised as a property. I am on the fence about what the difference is between a function and a computed property, so I am on the fence about how to handle them. Would like to write about them further in a future blog post, so hit me up with any thoughts you have at some point in time.

Compositing Filters

Anyone familiar with special effects or Photoshop might be familiar with compositing. Compositing is the art of layering multiple images and filters together to create a single new image. Compositing encompasses everything from making collages out of multiple images to generating large Photoshop pieces of art that have hundreds of layers.

The way we are using compositing here is that we are taking several simple image filters and we are combining them together to make a larger, more complex image filter. Many of the large, complex image filters in both Core Image and GPUImage are composites of smaller, simpler filters.

Core Image has an entire section of filters that are exclusively used to composite images. If you have a chance, it’s a lot of fun to play with compositing filters. If you work with Photoshop and you’re familiar with the various blend modes, these are represented in this category of Core Image filter. You can get some really awesome effects using compositing and blend modes in your photography and I encourage you to explore them.

The first composite filter we are creating is one that superimposes a color on top of the original image. It is made up of the CIConstantColorGenerator and CISourceOverCompositing. The Color Generator is just creating a blanket color layer whose output is not at all affected by the underlying image. The Source Over Compositing is simply taking one image and placing them over another. In our case, it is placing the Color Generator layer on top of our image we want to filter.

After we create this composite filter, we are chaining it to the output of the blur filter. So, first we are taking our image, applying the blur filter, then taking the output from the blur filter and applying our composited red filter to the top. We are specifying that the opacity on the red filter is only twenty percent so that the the second filter doesn’t completely block out the first filter or the input image.

Adding Functionality

Since being able to compose two or more filters together is an incredibly useful thing to be able to do and something we might need to do many times, it makes sense to write a custom function to simplify this process. Also, considering the number of inputs we are dealing with for this functionality, being able to simplify the code and avoid missed parens is a good use of our time.

The composeFilters() function being defined takes two filters as parameters and returns a new filter. In the code sample, we see that we are setting a variable to hold the output of this function, which is a filter. We are then creating a second variable that will hold the output of the filter we just created. Since the output from the composeFilters function is a filter, when you use the variable you are calling a Core Image function that is filtering the image being used as a parameter. When I read through this at first, it took me a little bit to parse apart the logic.

Infix Operators

Infix, Postfix, and Prefix notation is a complex way of labeling a phenomenon most programmers are familiar with: Where to place an operator.

Infix operators are placed between two operands. Which is an obtuse way of saying you write an equation like this:

X + Y

The operator, in this case the “+” sign, gets placed “in-between” the numbers it is operating on.

Prefix operators are placed, just as they sound, before the operands:


I’ll bet you can figure out how to write a postfix operator now:


What do these operators do? Why are there a bunch of them?

Think back to your Algebra class. Remember PEMDAS? That acronym helps us remember the order of operations. If you want to isolate two numbers that you want to add together before the result is multiplied, you had to put parentheses around them to ensure that the product was calculated, not just the first number. Infix, Prefix, and Postfix operators affect the order of operations in mathematical calculations. All equations can be represented and translated in each style, so theoretically you don’t lose any functionality by not understanding how to use each type of operator.

These operators are incredibly common in mathematics. Since Haskell and other functional languages evolved from Lambda Calculus, there are a lot of operators and notations that are foreign and unfamiliar to people like me who flunked calculus and grew up on imperative programming.

Swift lets you write your own custom operators. There is a list of ASCII characters that can be used to write custom operators. You have to specify what type of operator you are defining. If you are defining an infix operator, as we are doing here, you need to specify the direction of associativity. In standard mathematical equations we have associativity from left to right. You can choose left, right, or none. None, which is the default, means that you can’t place your custom operator next to another operator with the same precedence.

I am still trying to figure this part of the chapter out. I don’t know why the custom operator “>>>” was chosen. I don’t know if the character is significant or important. My understanding of the code as written is that instead of using a text label for our composeFilters function, we are using symbols. I know this is a common thing in languages like Haskell and unfortunately I haven’t delved into them enough to be able to fully answer my own questions about how infix operators are being utilized here. Again, if someone has an answer, I would appreciate a ping on Twitter.


Currying is the process of taking one function that takes multiple parameters and breaking it down into a sequence of functions that each take a single argument. For example, if you were writing a function that took two floats as a length and a width for a rectangle, you could rewrite this function to take the first parameter and then evaluates a sequence of functions, each of which take one parameter.

Currying is found in languages like Haskell. In Haskell, the language only allows you to pass one parameter into a function. Currying is a way to get around this constraint.

Side note: Both Haskell and curried functions are named for Haskell Curry. Curry was a mathematician and logician who hopefully didn’t get his lunch money stolen too often for having such a strange name.

Currying gives us some options for customizing our functions. Currying allows us to seed functions by supplying too few arguments and using it as a basis for fully implementing another function. It allows us to choose if we want to apply the function to all of our parameters.

Since this post is getting rather long, I don’t really want to write a comprehensive explanation of currying and why you want to use it. I will save that for another post. The concept of currying is introduced in this chapter, so I wanted to cover it just a little. I would also like to look over the code from this chapter to get a better grasp of currying before I try to explain it further.


There was a lot of stuff being touched on in this chapter. Core Image, infix operators, and currying. These are complicated frameworks and concepts, so again, don’t get frustrated if you got through this chapter not fully understanding how everything works.

Up next, we have our old functional friends Map, Filter, and Reduce. See you next time!

My Defense of Swift

**Note: I am using an example in my blog of a post written by a developer in our community. I have noticed many posts with the same thoughts expressed in them and I am in no way attacking this particular person, who I respect a great deal. I want to preface this with saying I am in no way attacking the author of this piece or trying to single him out, so I hope he will not be offended that I am offering a counterpoint to his post.**

This morning I had someone send me a link to this article and asked me what I thought about it.

Honestly? I am kind of sick of everyone crapping on Swift.

I am tired of everyone saying the language is broken and that you can’t write real applications with it because it’s half baked and unusable.

I don’t mean to keep waving my credentials around, but I am working on a project where we are rewriting our software in Swift. We are not writing the usual weather app/something that pulls data from an API. This is some heavy duty crap. We are writing this on the Mac. We are using a serial port to connect to outside hardware. This is a legacy project that is on its third rewrite that has been around for ten years. So far we have not encountered anything that we can’t do in Swift that is being done in the original software.

For the last month or so I have been bashing my head against a project where I am implementing libXML in our project (which I am going to write a blog post about shortly.) Taking a really under documented C library where the sample code is written in Pascal and trying to get it to work in Swift has been a demoralizing massive pain in the ass. I have had to deal with all kinds of horrors that I didn’t know existed or were abstracted away so that I would usually never have had to deal with them again.

However, doing those things has made me a better developer. Just because I came into Cocoa programming after ARC doesn’t mean that I have no reason to think about it or know how it works.

I started learning programming three years ago. Prior to that, I didn’t know how to write a “for” loop without looking it up online. I was one of those noobs that people hate on Stack Overflow who ask how to do incredibly simple and stupid things. Learning programming was hard. It forced me to fundamentally change the way I think about the world. It was also hard because I had a lot of people who had been doing it longer than I had who were crapping on me because I didn’t know who the Gang of Four were or why we do the MVC pattern, or even what MVC means.

There are a lot of things that we think are easy and intuitive that aren’t either but we think they are because they are familiar. My boss told me about working with a woman who had a PhD but had never used a computer before. Our structure of navigating through folders and files is “intuitive” to us because many of us have been doing this for bordering on 30 years.

If you have been doing imperative programming since you were 12, then yeah, some of this stuff is going to feel complicated and unfamiliar. If you don’t have a painful, visceral memory of the pain it took to learn programming the first time, you might think that all of this stuff is complicated and broken and wrong.

I, however, do remember how hard learning programming was. I find learning functional programming and figuring out Swift to be no more difficult than it was learning Objective-C. It’s different. It isn’t broken. Yes, there are some things that will be refined over the next few years, but Objective-C wasn’t born completed either. It evolved over a period of years as Swift will evolve.

I got into programming because I wanted to learn how to solve complex problems. I am excited about Swift because it affords an opportunity to solve a complex problem in a different way than we did before.

I am worried that people’s opinions of Swift are being influenced by a few people’s bad experiences with it. When I have tried to advocate for Swift because of the work I am doing, I get my experiences brushed off because of my boss. I am told that of course Brad Larson can use Swift to control robots. He’s a genius. Us normal people can’t use it because it’s too complicated.

Again, there is a difference between broken, complicated, and unfamiliar. If you go into Swift thinking it should be just like Objective-C, you are going to be disappointed. If you go into it knowing that it is unfamiliar and that you have to fundamentally approach things a different way, then you might be okay with it. If programming was easy, then everyone would be doing it. Just because something is different than the way that you are used to doing something doesn’t mean that it is wrong.

I hope that people who are discouraged will eventually change their mindset about how to approach Swift or some other hybrid language with functional features. Life gets boring if you just do the same thing over and over again in the same way. Programming is a young discipline and we haven’t yet reached the point where we absolutely know that the way we are doing things is best. It will continue to grow and evolve and change. And that’s a good thing.

Functional Programming in Swift: Chapter 2- Thinking Functionally

*Note: I strongly recommend following along in the book with this blog post. I am not going to be recreating the diagrams or the code here, so if you don’t have the book open when you are reading this post, you will be very confused and I would not like that.*

This first full chapter of Functional Programming in Swift introduces one of the most important new concepts in Swift: Higher Order Functions. I will get into higher order functions in a moment, but first I would like to give a little bit of context as to what the example of the chapter is about.


The example used for this chapter is called Battleship. I, like many other people, associate Battleship with the board game. Since many programming textbooks use common games with known rules to teach programming concepts, it was understandable that many people thought that this example would be about the board game Battleship. This is not the case.

Back in 1994, the Office of Naval Research was exploring rewriting some of its defense software. Like any good agency, they didn’t want to just pick a programming language out of a hat. They wanted to benchmark which language would be the most efficient language to use for this project. They were concerned with a few factors:

– Development Time
– Lines of Code/How Concise is the Code
– Human Readability
– Maintainability

For a very long time, functional programming languages were considered to be impractical for real world applications. They were an interestring curiosity and another approach to programming, but the enforced static nature of functional languages and the lack of mutable variables seemed to doom functional languages to never be implemented in actual projects.

This study proved that a purely functional language could not only be used effectively in a real application, but also proved that this approach could be even better than an imperative approach.

If you look over a lot of the examples in this chapter, you will notice a lot things that are not present in our traditional games of Battleship:

– Checking the range of your weapons
– Avoiding engaging enemies too close to your ships
– Taking the location of friendly entities into your equations

These are not things we think about when playing the board game Battleship, but they are incredibly vital things to consider if you are a naval ship engaged in battle with actual enemy combatants. These are not small considerations. You don’t want to accidentally frag your fighter jets when you are aiming for an enemy ship. Any targeting program that you design must account for all of these considerations.

This beginning chapter takes this example and shows how Hudak and Jones were able to work around these constraints in a functional manner that was more efficient and easier to maintain than the traditional imperative way of approaching these problems.

Imperative Complexity

Our initial calculation is very simple. We are assuming our ship is at a location and we are trying to determine if another point is within range of our ship. Our range is represented by the radius of a circle and we are simply passing the location of our ship (position) and the distance we can shoot (range).

We are then using the Pythagorean Theorem to determine if our target point is within range of our ship. a squared plus b squared equals c squared. In our case, target.x squared plus target.y squared should be less than or equal to our range squared. Our first function is taking the square root of the two target coordinates and returning it only if this qualification is met.

In order to keep things clear, we are using a type alias so that we don’t have to remember that the CGPoint object is our position and the CGFloat is our distance. We will see type alias again, so don’t forget it.

So far, so good.

As the program grows in complexity, it becomes harder to continue to maintain the function. We keep adding additional parameters and constraints. I am going to honestly say at this point I developed code blindness and stopped looking at the code. Suffice it to say, this once simple function grows to a large mess of spaghetti that kind makes me weep for the future of human civilization.

I am not going to untangle the spaghetti code because we aren’t supposed to be doing this anyway and I am not going to encourage you to write unmaintainable code. Bad Swift developer!!

Going to skip ahead to the functional way to deal with these constraints.

The Functional and Rational Approach to This Problem

There is one very important thing to remember about functional programming versus imperative programming:

– Imperative programming is about telling the computer how to do something.
– Functional programming is about telling the computer what to do.

In the above spaghetti code, we were getting over wrapped up in how the conditional logic would deal with all of the various contingencies of our problem. If our point is in range but it is also too close to a friendly, what do we do? It is easy to get overwhelmed by the complexity of implementation.

So let’s take a step back and ask what are we actually trying to do, without thinking about how it will get done.

We want to know if our point is in a region where we can target it.

Remember when I told you to remember type alias? We are bringing it back here. A type alias allows you to assign a label to an existing type so that if you have multiple objects/properties/variables that are all the same type, you can assign a label to the one specific instance of that type.

We know that strings and numbers and classes are all types, but there is another thing in Swift that now qualifies as a type: a function.

Functions in functional programming are values, no different than strings or structs. They can be passed around and referenced exactly the same way you would work with any other kind of value. The best analogy I can think of for this is a string. In C we didn’t have real strings. Stings were an array of chars that were eventually, in later languages, encapsulated into their own type. As you work more with functions as their own discreet values, it should get less weird to think of them in this way.

We can create a type alias for a specific function type. In the example in the book, we are creating a type alias for a function that takes a Position as a parameter and returns a Bool.

So instead of our initial function that uses the Pythagorean theorem and returns the result of that calculation, we are instead returning a closure that performs the calculation. Closures are simply unnamed functions. Basically we are taking the logic we had before and putting a nice, shiny function wrapper around it. We are wrapping a riddle inside of an enigma.

Why would we want to do this?

Let me give you a real world example of this in practice:

I work at a company called SonoPlot. My boss, Brad Larson, wrote a blog post about our project to rewrite our robotics control software in Swift. Since we are dealing with interacting with hardware, there are a lot of things that can go sideways that you don’t have to deal with when you are working with just software. Sometimes something goes screwy when we are communicating with the hardware and if we just send the command again it will go through just fine. Other times, the hardware is disconnected.

We don’t always know which one of these situations we will be in. We don’t want to keep sending commands to our robotics if they are not connected or on. Alternatively, we don’t want to tell the user that the robotics are not connected when they actually are.

To get around this situation, we created a special function called “runCommandAndAttemptSoftRecovery()” that takes a function as a parameter. We wrap many of our hardware functions in this function. “runCommandAndAttemptSoftRecovery()” will try to run the function we are passing in and if it doesn’t pass, it will attempt run the function again. If the function fails a second time, we handle the error.

Sometimes you will have some functionality that is important to apply to many parts of your project, such as our hardware commands. In times like those, being able to pass a function into the function makes it possible to reuse a piece of code in ways that weren’t possible with Objective-C or an imperative language.

In the example in the chapter, we are trying to figure out a way around the creepy spaghetti code and conditional logic. Rather than creating one Frankenstein’s Monster of a function that has to account for all of these things, we are creating a lot of small functions that account for discreet parts of this problem.

We check if the point is within range of the circe. We check the offset. We write a function that combines known areas that are in range so that they are in one data set instead of two. Each of these functions returns a function of the same kind, so they can work together to narrow down more discreetly if a point is within range of the battleship without hitting a friendly craft.

This is a rather difficult example to explain and I will honestly say that at this point I can only explain it on a high level. I strongly recommend looking at the final code and referring back to each individual function to see how they work together. There are truly reusable functions in the final function that behave differently based on their inputs and parameters. Sometimes looking at a final piece of code and following the logic through its various rabbit holes is the best way to understand how something works. That’s why we dissected frogs in high school biology class, even though I swear some of my teachers were sadists….


This is an introductory chapter. It isn’t expected for you to genuinely grok all nuances of functional programming from this.

Here are the points I would take away from this chapter:

  • Start thinking about what you want your code to do rather than how you are going to implement it.
  • Start trying to mentally break things down into smaller pieces. Instead of having some big, scary function full of state and conditional logic, think about what you are trying to do in smaller steps.
  • Get used to the idea that functions can be passed around like variables. Think of functions as things that take one thing and turn it into something else. If you have a piece of wood, that can be turned into many different things. It can be a table, a desk, or a bookshelf. If you think of a function that takes a piece of wood and returns a piece of furniture and think about how each piece of furniture can be different, this might give you a better idea about how to conceptualize passing functions in Swift.
  • Don’t get discouraged!! This is a different way of thinking. It isn’t going to be intuitive. I have been working on this for nine months and I have barely gotten to the point where this chapter makes sense. That is one reason I am doing these posts. This is just to get your feet wet with some functional concepts. You are not expected to fully understand everything at this point in time. If you feel dumb right now, join the club. You’re not the only one. Just keep working at it and eventually something will click.

I wanted to recommend some resources I am using to try and work through this book to get these concepts to make more sense:

I will try to add to my list of resources as I encounter new ones. If people have sources they particularly like and want to make me aware of them, please ping me at @redqueencoder

Again, if a lot of this is still super confusing, that’s fine. You’re in the right place. We’re all trying to figure out how to please our new functional overlords. It will take a while and no blog post anyone is going to write is going to make this immediately intuitive. Think back to when you learned programming for the first time. It took a while, didn’t it? Learning how to think takes some time and some work. Don’t get down on yourself. Keep at it.

Up next, we are tackling some Core Image. Stay tuned!!

Functional Programming in Swift: A Chapter by Chapter Analysis

I preordered the book ”Functional Programming in Swift” shortly after it was announced. I got a chance to meet Chris Eidhof at 360|iDev, which was a really awesome experience. He really knows his stuff and he is a wonderful person.

However, I have found it has been a little difficult to get into the Functional Swift book. I know there is a lot of really important content in here that I think is vitally important for people to be aware of, but I feel like it is being presented in a slightly obscure manner. This is not a beginning programming book and it can be a little difficult to break into.

I am trying to write more technical posts on my blog. I wasn’t doing this for a while because I was working on my book ”iOS 8 SDK Development.” I was so stressed trying to learn all the stuff we were writing for the book that the thought of going and writing technical posts for my blog was a little discouraging.

Now that the book is pretty much completed and I don’t have any conference talks to prepare for a while, I would like to spend more time writing technical blog posts. One series of posts I would like to do is analyzing the Functional Programming in Swift book.

I was a beginner not too long ago and I know how incredibly daunting it can be to be confronted with a bunch of technical stuff you don’t quite grok yet. I know that Chris is passionate about functional programming and I hope that he will not be offended by my efforts to spread the word about his work and to try to sugar coat it a little for people who are not as far along as the target audience for his book was.

I am going to try to tackle a chapter every week or two. If I am slacking on this, please harass me on Twitter so that I know that people are actually reading and getting some use out of my posts.

If people have things they would like me to write about, please hit me up on Twitter about it. I am happy to go out and figure something out that people want to learn more about.

I hope that doing this analysis will open new people up to things in Swift that weren’t possible in Objective-C. I know that right now it is very hip to hate on Swift. I was rather unhappy about Swift when it was first announced because I was under the impression that many things we do were going to be abstracted away. I didn’t like Ruby on Rails because you could write three lines of code and have a functioning website without understanding anything going on under the hood. I am an incredibly curious person who wants to have a deep understanding of how things work. When I was able to shift my perspective on Swift I became very excited about learning a new way of doing things. I hope that other people will do the same when they become familiar with how to effectively write Swift.

If you want to know what my current long-term project is, check out this blog post from my boss, Brad Larson. So far, we have not found anything we have wanted to do that could not be done more efficiently in Swift. We have had to use a few work arounds with the compiler, but we have not encountered any show stoppers.

I have been disappointed with all of the people who are claiming that Swift is broken and that it shouldn’t be used for serious projects. If Brad and I can use Swift on the Mac to communicate with an electronics board through a serial port, you can figure out how to use Swift to communicate with an API. It is just a question of working with the language, not fighting against it.

I hope over the next few months I can help others learn how to work with Swift. I think that is is a promising language and I hope that people can learn to open their minds to new ways of thinking about how to program.

Zen and the Art of Analog Synthesizer Maintenance

2014: The Year of Magical Thinking

You can take a picture of something you see
In the future where will I be?
You can climb a ladder up to the sun
Or write a song nobody has sung
Or do something that’s never been done

Last week I was in Atlanta for CocoaConf Atlanta. That conference was the cap on one of the craziest years I have ever had.

Exactly a year ago I had dropped out of school because I was having a nervous breakdown. I knew I needed to find a programming job but I had no idea where or how I would do so. I was completely broken and I had no hope that anything would get any better. The only thing that got me through that period of my life was the faith that something would happen.

I spent a lot of my time in 2013 sowing seeds, hoping one or two of them would take root. I attended several conferences and met a lot of people. Two of the people I met were Jonathan Penn and Chris Adamson. Jonathan mentioned he was writing a book and wanted to know if I would tech review it. Being a tech reviewer is an unpaid task, but I like and respect Jonathan, as evidenced from this blog post.

The editor for Jonathan’s book is Rebecca Gulick, who also happens to be the editor of my book with Chris. When he was looking for a coauthor and he mentioned me to Rebecca, she already knew who I was.

Before I was approached about writing the book, I reached out to Brad Larson about learning OpenGL. I knew I wanted to be a graphics programmer, but that it takes a long time to learn, especially for someone like me who didn’t have any programming experience until two years earlier. My reaching out to him resulted in me having the chance to work with him on a contract project for Digital World Biology. Even though we were working on this project, I hadn’t met Brad in person.

I happened to meet Brad in person a week after I signed the contract to work on the book with Chris. I didn’t know it at the time, but the book I was working on used to be the textbook used for the iOS programming class at MATC. That definitely made an impression.

Six months ago, I had a couple of conferences that I knew I would be speaking at. I wound up doing twice as many as I thought I would. My first conference talk was less than a year ago. This year I spoke at ten conferences total.

Between writing a book, traveling all over the United States, and getting a job with one of the best programmers in the world working on robots, my head is spinning. There are so many things I thought I might get to do a few years down the road. I just wanted a job to get some experience so that maybe one day in like five years I would be able to work with someone of Brad’s caliber. I hoped that maybe I would be able to work on a book in three years.

I looked back at the goals I set for myself at the beginning of the year. No, I didn’t wind up starting a podcast or buying my MIDI wind controller (however that is on the horizon). I set out six long-term goals that I wanted to do in the next 3-5 years. I have knocked half of those off in 2014.


Oh brother I can’t, I can’t get through
I’ve been trying hard to reach you, cause I don’t know what to do
Oh brother I can’t believe it’s true
I’m so scared about the future and I wanna talk to you
Oh I wanna talk to you

I am going to be honest. I had absolutely no idea how to proceed from here. Part of being alive is to strive to go further and do better. Once you get to where you want to be, what do you do? I always feel a bit of a disappointment when I finish my cross stitching projects because I keep feeling like I will feel a sense of accomplishment, but it’s always a letdown. I enjoy the process of making the thing more than the joy of accomplishing them.

Part of my excitement about these long term projects was the anticipation of all the neat things I would get to do between then and now. I was really looking forward to all the neat stuff I would get to do and all the time I would get to spend working on my craft.

None of that happened.

Things happened so fast that I haven’t had a chance to enjoy anything I have been doing. I haven’t had a chance to stabilize the ground under my feet. I haven’t had a chance to really dig deep into something than interests me because I am running around like a chicken with my head cut off rushing to the next thing.

I have honestly been depressed. I feel like I shouldn’t be depressed and that I am a terrible and ungrateful human being because I got everything I ever wanted. Not only did I get everything I ever wanted, I got it way faster than anyone else. I have it made and I have no idea how to get up each day and deal with my life. Plus I feel like I can’t talk about it because I know that there is absolutely no reason for me to be unhappy.

I had a lot of conference talks lined up for 2015 and I was thinking about doing a lot more stuff because I feel like I worked my ass off sowing these seeds. I hoped that one or two would take root but twenty did. Last year I had nothing but my stubbornness and refusal to quit and now I have the situation of having too much. It feels wasteful to me to squander opportunities I would have killed for a year ago.

But I have to.

It has been a tremendously difficult decision, but I am not doing any conference talks for at least six months. I do not plan to attend any conferences during that time either.

I love this community. I have made so many friends in so many places. I spent a lot of my life feeling like a freak who never fit in anywhere. Being welcomed into this community and treated with respect has meant more to me than I can ever express. One reason it took me so long to make this decision is because this community means so much to me and I want to make sure other people like myself have a chance to join and be welcomed as well. The Klein family has changed my life and I can never express to them what their kindness has meant to me.

I feel like my life is moving too fast and I need to take a step back. I need to focus on getting my feet back under me. I need to focus on doing my job well. I need to focus on sharpening my tools. I need to find something that gives me back the joy and meaning I had in my life back when I was struggling to break through.

The Zen of Sound

Are you lost or incomplete?
Do you feel like a puzzle, you can’t find your missing piece?
Tell me how do you feel?
Well, I feel like they’re talking in a language I don’t speak
And they’re talking it to me

Last year I felt like I had to spread a wide net to catch one opportunity. I spread myself very thin doing a lot of different things to try and get myself enough exposure to find a job. I am pulling back on a lot of these things.

Looking back at my long-term goals, the half that were not fulfilled all had to do with audio programming. I love sound. I wanted to be a sound designer before I became a programmer. Last year I wanted to write a synthesizer app as a portfolio project, but I had too much noise in my life that I couldn’t focus the way I needed to for this project.

Now that I can pull back on a lot of the things that are taking up my time, I can focus my free time on projects that personally interest me without worrying if they will get me a job.

I spoke to Brad when I began to feel overwhelmed about what I should focus on for the next year or so. He advised me to think of something that doesn’t exist and to try and make it happen. He talked to me about taking an impossible task and breaking it down into small, discreet parts that can each be accomplished individually.

Audio affords me a lot of opportunities to explore things that interest me. I became interested in electronics after I began working with physical hardware at my job. I also became interested in math after I started working with GLSL. Additionally, Apple introduced not only Swift, but AVAudioEngine. There have been audio programmers on Twitter who do not think you can do audio programming in Swift because Swift is not built on C.

When I tried to tackle this last year, I had no idea what I was getting into. I also placed a lot of chips on me being able to pull this thing off that caused me a tremendous amount of anxiety.

I am not going to make that mistake again.

I know it isn’t necessary, but I want to build a physical synthesizer before I tackle a software one. I want to get a feel for how all of the pieces fit together.

I also want to spend more time making music with my tools. You can’t really create a piece of software for a group of people if you don’t understand how they are going to use it. I used to play around with this stuff all the time years ago, but it’s been too painful to work with until recently.

I am not going to disappear. I am going to catalog my journey here on my blog. I hope that I can figure out how to do some things that will be helpful to the community at large. I plan to take everything I am learning over this time and present it at NSScotland, which I am still going to speak at. I could not let down Alan Francis again.

I hope that anyone reading this can understand and respect my decision. I hope that I am not the only person who has felt this way and that reading about my depression can help someone else. I am in this career for the long haul. 2014 was a sprint. The journey is a marathon. I can’t keep going the way I am because I won’t make it to the end. I am going to miss all of the amazing people I have met over the last year, but I need to take care of myself and focus.

Thank you everyone for an unbelievable 2014. I am looking forward to coming out of my self-imposed isolation a happier and healthier person. God bless and keep all of you. Don’t have too much fun without me.

A Brief Analysis of Swift Structures and Classes

Now that I have cleared a few things from my queue, I have some time and mental energy to really delve into some of the things I left on my back burner. One of those things is to really dive deeply into Swift.

Yes, I know. I have my name on a book using Swift. That book isn’t a language book, it is a framework book. We are primarily getting people who code familiar with the Cocoa Touch frameworks that most people will use. We did not really dive deeply into the minutiae of the Swift Language because, honestly, very few people have. It is still in the process of changing and many people are still stuck in the mental paradigm that they are supposed to write it like they would Objective-C.

I knew when I was going to learn Swift that I really wanted to grok in fullness how best to use the language and to not write hacked, inefficient, and messy code.

One thing I am trying to get used to is the fact that a file does not have to have a class. I am so used to the idea that every file must not only have a class, but that the class must have the same name as the file that seeing it is possible to write a file without that and have it compile kind of blows my mind.

This begs the question in my mind of what do you, or should you, need to include in a file that integrates into your project. Right now I am focusing on three different structures: classes, structs, and enums. I want to explore what each of them gives you and what their limitations are. These are three very similar things and I am interested in exploring what situations each would work it.

This post will be on structures and classes and a future post will be on enums.

Class Versus Structure

Classes have all the same functionality that structures have, but this does not go the other way around. Classes and structures can both do the following:

  • Define properties
  • Define methods
  • Define subscripts to provide access using subscript syntax
  • Define initializers
  • Be extended and expanded
  • Conform to protocols

Structures are far more powerful here in Swift than they were back in the Objective-C days. Back in the day structures could pretty much just do the first thing in this list, define properties. Structures have taken on some of the heavy lifting that only classes used to do.

Classes, on the other hand, can do all of these things along with the following:

  • Inherit characteristics
  • Check and interpret the class type through type casting
  • Deinitialize resources
  • Allow more than one reference to the class instance

This kind of begs the question of why you would create a struct if you can get all the functionality of one for “free” by creating a class. What are the advantages of a struct? Why did the Swift development team think it was necessary to supercharge the struct type?

We would of course want to create a struct in the same situations we used to use them before. But if a struct can conform to a protocol, be extended, and define methods, then where is the line between a class and a struct?

One of the things in this list confused me somewhat: ”Define subscripts to provide access using subscript syntax.” I am perusing the Apple documentation and apparently this means that if you instantiate a struct in a class, you can directly set one property inside the struct. I didn’t use structs much when I was learning Objective-C, but I vaguely remember if you created an instance of a struct, like CGRect, you had to set both aspects of the CGRect. You couldn’t create a CGRect that was a square, change your mind, and just reset the length to be longer. You had to reset the height as well. Now if you wanted to do that, you could simply specify the parameter you want to change and reset it directly.

Value Types

Structures and enums are both value types, but classes are not. A value type is a type whose value is copied when you assign it or pass it around. I didn’t know this, but all the types that we use in Swift, like integers, Boolians, and strings, are all actually implemented as structures. I am so used to dealing with these “primitive” data types that I never thought about how they get implemented by the compiler. I find it fascinating that all the types we use in Swift boil down to structures.

I guess if you really think about what the code is doing, this makes total sense. We are not using C pointers in Swift. If you create a CGRect and then create a second one that is set to the same initial value as the first one, your second CGRect can change and mutate independently of the first CGRect.

Reference Types

Classes are reference types. This means that if you create an instance of a class then set another instance of the same class to the first instance, they are linked and what affects one will affect the other. This is a really important distinction between a class and a structure. If you have something where you will need to create a lot of instances of that object, but you want them to display slightly different behavior, you would want to use a structure. Likewise, if you want a lot of instances that will all change when one changes, you would use a class.

So When Do I Use A Structure?

Here is Apple’s advice about when you would want to use a structure. They advise you do to so if at least three of the following conditions apply:

  • You are encapsulating a few relatively simple data values
  • Your values must be copied rather than referenced when they are passed around
  • Any properties in the structure are value types, or if you are not storing instances of classes
  • The structure does not need to inherit properties or behaviors from an existing type

This list is…interesting…

The problem I am having here is that this is pretty much what you could do with structures back in C and Objective-C. What was the point of really increasing the scope of what they can do just to advise everyone to treat them like they did before. This puzzles me. I thought by exploring these differences that I would uncover something I hadn’t considered before, but I am left with my initial questions.

It’s possible I am reading too much into this. Being an Apple developer means sifting through everything Apple says to try and read the tea leaves of what direction they are going in next. Sometimes they leave a decent trail of breadcrumbs. Sometimes they don’t.

I am in the parallel process of learning Haskell along with Swift. I am going to keep these questions in the back of my mind to see if I can find any more answers to this question in other locations. I feel there is something significant here I haven’t gleaned yet, and I am looking forward to figuring out what it is.


I hope for this to be the first in a series of posts about the Swift programming language and how to work with it most effectively. I am probably not telling anyone anything they couldn’t figure out from reading Apple’s Swift book. I have found that writing things out as I am learning them is helpful to my own learning process. If my writing is helpful to you as well, awesome.