Nate Stedman


April 4th, 2016












Networking with µframeworks

March 3rd, 2016

There’s a few different components to a networking stack for an iOS app:

  • Describing request parameters in a programmer-friendly manner (NSURLQueryItem, to some extent).
  • Encoding those parameters to URL request values (NSURLRequest).
  • Sending URL requests (NSURLSession).
  • Handling conditions that may arise during requests (NSURLSessionDelegate).
  • Decoding response values (NSURLResponse/NSHTTPURLResponse, NSData).
  • Delivering the data to clients asynchronously (callback functions).

Most iOS networking frameworks provide all of these, calling out to NSURLSession internally. I’m interested in building small frameworks that provide a single component and communicate in a relatively standard way, so that they can be composed with other frameworks of the developer’s choice. Smaller frameworks tend to be easier to understand, and the Swift Package Manager documentation suggests that they are preferable:

As a rule of thumb: more modules is probably better than fewer modules.

Read More


January 28th, 2016

I wrote Attributed to make attributed strings in Foundation more expressive. It works well with many attributes, including fonts and colors, because those values are represented by a single simple object. However, the paragraph style attribute contains a number of different properties. By default, the best way to create a paragraph style is to create a mutable version and set its properties. As this requires multiple expressions, it can’t be used inline with other attribute functions, without embedding it within a closure, which is also unnecessarily verbose.

To solve this, I’ve written a simple extension function for NSParagraphStyle, called with. It takes all of the properties that can be set on a mutable paragraph style as parameters, all of which have default values, so only the necessary properties need to be specified, like so:

let style = NSParagraphStyle.with(alignment: .Center, lineSpacing: 12)

Available on Github.

Nested closures & weak capture

January 27th, 2016

In Swift code, there’s a potential strong reference leak hiding in nested closures:

    bar({ [weak self] in

This code seems okay, since only bar refers to self, which is captured weakly. However, that’s not actually the case! foo captures self strongly. Instead:

foo({ [weak self] in
    bar({ [weak self] in

Will work correctly. There is a proposal to change this.