Writing updates and asking “Is Github my new Dropbox?”

I’m testing the waters for the first time in using Github rather than Dropbox to coordinate a private project. I’ve used private repos before for material that wasn’t meant for public consumption or to stage material that would then later be released openly but this is the first time I’m testing it out for material that’s substantially not code.

I’ve been meaning to give this a go ever since Github changed its policy to allow unlimited private repositories. I used to be limited to just five in total and I guarded those slots carefully. Under the new policy, I have repos to burn. Today was the first time that I set one up to use in this way.

It feels odd using Github instead of Dropbox as I’m so used to my Github content being primarily open, and Dropbox requiring explicit permissions. Have you tried using Github this way? And how have your experiences been?

The reason I’m testing out Github is that I’m updating iOS Drawing for Swift. I have a week or so to burn while I’m waiting on editorial feedback and tech review on my Swift Style title from Pragmatic. It will take another 4-6 weeks for Addison Wesley to release iOS Drawing rights back to me but I figured I’d get a head start writing some test chapters and get some early feedback about the project while I had some downtime.

I’ve used Dropbox for years to provide material to beta readers and gather their feedback as well as to coordinate material on multiple machines. In testing out Github, I was inspired by Pragmatic’s workflow.

Pragmatic uses a delightfully retro SVN version controlled interactions between editors and authors. (I’ve had to create an SVN/git cheatsheet to remind myself how to SVN all the things.) Pearson/AW in contrast uses Basecamp to manage projects. Basecamp offers a lot of great team features including messaging, calendars, email updates, and so forth, and I’ve been quite happy with it.

Book projects tend to be hefty, especially those with lots of illustrations and sample code but Github has generous file policies. It imposes a 1GB repo limit, 50 MB file warnings, and 100MB file limits.  These are far beyond what I’d need.

I’ve recently changed my overall personal workflow, having been inspired by conversations with editors at O’Reilly. O’Reilly has been pioneering modern, flexible content using markup source. I took my lead from them. (I’m personally using CommonMark instead of AsciiDoc and pandoc instead of Atlas, but the ideas are similar.)

Pandoc has been a pure delight. Even if CommonMark offers less nuance and control than Microsoft Word (however ugly MS Word is, it has power and all the ugly but practical features you need for professional publishing), pandoc allows me to push from manuscript to book in seconds.

I don’t have to use Calibre to build epub, pdf, and mobi output. My code examples are readable and my tables of contents are perfect. I’ve written a bunch of command-line utilities that automate the process of building the ebooks, zipping up archives, and storing copies in a Dropbox beta folder. I still use Dropbox to provide early reader access.

I built Swift Style‘s first draft using this workflow, writing in MacDown, an open source macOS Markdown editor. I like MacDown’s side-by-side display but, to be honest, for material of any size, it has no way to keep the text and output in sync, especially once you introduce illustrations.

If I find some time, I’ll probably try to mess with the source to add this functionality because once you drop the ability to see your edits as you add them, the utility loses a lot of its charm but that’s a project for another day.

In the meantime, I’m just getting settled into Github for this project. A lot of my work steps are similar: I start by pulling and wrap up by pushing but now it’s to the repo, and not to Dropbox. Github offers more version control than Dropbox’s undelete functionality and I don’t have the same worries about filling up my quota.

I’m curious: Are you using Github for non-coding projects? And how has that worked out for you? Did the DNS incident a few days ago make you rethink? Or are you committed to this kind of collaborative tool? Let me know. Thanks!

Animating letters into place

I love playgrounds. This is exactly the kind of challenge they were built for. Joe Fabisevich asked: “Does anyone know how (or if) it’s possible to animate every character of a UILabel (or UITextView/some other text holding view if necessary)? I want to replicate this effect, of the word Hello!


If you want to read about this kind of UIKit fun, my Gourmet Cookbook covers a lot of it. The book is in Objective-C but it’s not hard to translate the tricks over to Swift.

Once you’re in Swift, you can easily put together proof of concepts and tweak parameters from a playground, with instance feedback — from speeding up and slowing down the animation, to testing out different font faces and color schemes.

Source Code

And another take, with a little fade in and scale popping:

This one weird trick for drawing dashes

Just a quick tip before the weekend: You get dashes and you get dashes and you get dashes and…


Here’s the code.

let drawSize = CGSize(width: 100, height: 100)
let ovalRect = CGRect(origin: .zero, size: drawSize)
    .insetBy(dx: 5, dy: 5)

let path = UIBezierPath(ovalIn: ovalRect)
path.lineWidth = 5

// Set up dash pattern 
var dashes: [CGFloat] = [12, 2, 2, 2]

// Plug it into the Bezier path
path.setLineDash(&dashes, count: dashes.count, phase: 0)

// And draw
let image = UIGraphicsImageRenderer(size: drawSize).image {
    context in let bounds = context.format.bounds
    UIColor.white.set(); UIRectFill(bounds);
    UIColor.red.setFill(); UIColor.blue.setStroke()
    path.fill(); path.stroke()


Your (not very) weird tips:

  • Use an even number of dash values as on-off point patterns. Odd patterns don’t look right. The second time through each pattern the on-off flips and…just try it out and you’ll see what I mean.
  • Make the sum of the dashes divide cleanly into diameter * π (in this example, 90π). This prevents weirdness where the start and end meet up.
  • Make sure the dash values is var and not let, so you can pass them by using “&” instead of doing some godawful UnsafePointer<CGFloat> thing.
  • Draw the path to see your dashes. Swift playgrounds don’t show borders or dashes in QuickLook previews.

Dashes are always as thick as a path’s lineWidth and the lineWidth is centered on the exterior of the shape. In this example, 2.5 points lies outside the path, 2.5 points inside, which you can see when looking at the gaps between each dash segment.

Leave enough space so the border won’t clip by applying rect.insetBy. It’s one of the new Swiftier Core Graphics calls, and it’s much easier to read than the old CGRectInset-style calls.


Solving Mathieu’s Phone: The mystery of disappearing gigs

The other day, Mathieu’s 16 GB phone suddenly had no space. Even after rebooting, even after reformatting (and not restoring from backup), all his spare bytes were being sucked into a black hole.

He had no songs, few apps, a modest number of photos, and under a gigabyte of space available, making him unable to compile, load, and tests his apps.


Each time he deleted one of his apps, the space would mysteriously fill up within a few minutes, adding to the ever increasing “other” bar in iTunes:


This delete-then-lose-space behavior made me think that iCloud was trying to store files locally on his phone to reduce cloud access. I suggested that he disable iCloud and sync just the bare essentials like contacts, calendars, and notes. (Mathieu has a paid 300GB iCloud plan.) Sure enough once he logged out and rebooted, over 7GB of space was freed up and he was able to use his phone again.

I’m not super-familiar with iCloud so if anyone can further explain how this works, and how to set up the phone to limit it from glomming space, I’d sure appreciate being able to pass that along. Thanks!

Which code style reigned supreme? Unswifty Procedural vs Swifty Functional Results

Yesterday, I asked you to pick a style for some sample code about character-by-character layout.

  • Choice A used a procedural for-in loop
  • Choice B used a map-reduce pair
  • Choice C used a series of maps, followed by a reduce.

The people have spoken, and they spoke primarily in favor of choice A:

Summarizing the majority view, David wrote “For my money, A wins by a mile. It’s just far more readable, maintainable, with far less mental work required.”

Here’s the layout I was working on presenting:


And the code I ended up using was this. It ended up closer to choice C than Choice A, but I took my guidance from the “make it clearer crowd”  A crowd. I hope that I picked up the “more readable, maintainable, less mental work” theme the voters asked for.

// Convert characters to attributed strings 
// and measure them
let letters = characters.lazy
    .map({ String($0) })
    .map({ NSAttributedString(string: $0, attributes: attributes) })
let letterSizes = letters.map({ $0.size().width })

// Calculate the full extent
let fullSize = letterSizes.reduce(0 as CGFloat, +)
var consumedSize: CGFloat = 0

// Draw each letter proportionally
for (letter, letterSize) in zip(letters, letterSizes) {
    let halfWidth = letterSize / 2.0
    consumedSize = consumedSize + halfWidth;
        defer { consumedSize += halfWidth }
    pushDraw(in: context) {
        // Rotate the context
        let theta = 2 * π * consumedSize / fullSize
        context.cgContext.rotate(by: theta)
        // Translate up to the edge of the radius 
        // and move left by half the letter width.
        context.cgContext.translateBy(x: -halfWidth, y: -r)
        letter.draw(at: .zero)

I took Paul C’s advice to heart: “I like each step to be a useful thought that conveys to a human some but not too much new information about what’s going on.” My revised approach breaks the code down more into  steps.

Reader feedback led me to consider a few excellent points. Was I going to re-use any of the information? (Yes I was) If so, I needed to break down the functional chain. If I went functional, shouldn’t I be using lazy mapping? (Yes I should).

The zipped for-loop let me pair letters with their sizes so I could perform the rest of the layout without re-calculating each letter size. One perfectly cromulent approach put forth (that I decided not to go with) was that I could merge the characters into a single string (presumably disabling ligatures and kerning) and calculate the full width once.

If I were only calculating the width, this would work fine. Once I decided to retain and re-use individual sizing, that approach became less attractive, but I thank the several people who suggested it.

Finally shout out to Rob N, who suggested Core Text layout for better spacing, which I’ll try out this morning.

Thank you everyone for your feedback and input.


Update: I gave it a try, using TextKit, laying out the text in a line and then using the resulting glyph widths. I had to enable kerning to get a better layout result (my first attempts were identical to yesterday’s). Here’s the updated layout, plus an overlay of the two. I think the “W” looks a lot better.




Holy war: Unswifty Procedural vs Swifty Functional

Background: I’m working on a proof of concept chapter.

Goal: Sample code that’s teaching about proportional spacing in character-by-character layout.

The contenders: I initially went with a basic loop (choice A) rather than reduce() (choices B & C).  For an audience that’s learning about graphics rather than Swift, does this read significantly more easily? Are there compelling reasons to prefer the functional approaches? And if so, how much would you break it down? Which would you go with and why? Let the battle commence. Which code reigns supreme?

// Choice A
// Calculate the full extent
var fullSize = 0 as CGFloat
for character in letters {
    let letter = NSAttributedString(string: String(character), attributes: attributes)
    fullSize += letter.size().width

// Choice B
// Calculate the full extent
let fullSize = letters
    .map({ NSAttributedString(string: String($0), attributes: attributes) })
    .reduce(0 as CGFloat, { return $0 + $1.size().width })

// Choice C
// Calculate the full extent
let fullSize = letters
    .map({ String($0) })
    .map({ NSAttributedString(string: $0, attributes: attributes) })
    .map({ $0.size().width })
    .reduce(0 as CGFloat, +)

Which code reigns supreme? Results discussed here.

The Joys of iOS 10 UIKit Drawing

I just spent a few days enjoying all the iOS 10 UIGraphics renderer utilities for images and PDFs and wide colors and so forth. It’s lovely. I thought I’d share a post comparing the old world and the new.


Remember this?

// Create a color space
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB(); 
if (colorSpace == NULL) {
    NSLog(@"Error allocating color space");
    return nil; 

// Create the bitmap context.
CGContextRef context = CGBitmapContextCreate(
    NULL, width, height,
    BITS_PER_COMPONENT, // bits = 8 per component 
    width * ARGB_COUNT, // 4 bytes for ARGB 
    (CGBitmapInfo) kCGImageAlphaPremultipliedFirst); 

if (context == NULL) {
    NSLog(@"Error: Context not created!"); 
    CGColorSpaceRelease(colorSpace ); 
    return nil;

// Push the context.

// Perform drawing here


// Convert to image
CGImageRef imageRef = CGBitmapContextCreateImage(context); 
UIImage *image = [UIImage imageWithCGImage:imageRef];

// Clean up 
CGColorSpaceRelease(colorSpace ); 


let image = renderer.image { context in
    let bounds = context.format.bounds
    for amount in stride(from: 1.0 as CGFloat, to: 0.0, by: -0.1) {
        let color = UIColor(hue: amount, saturation: 1.0, 
            brightness: 1.0, alpha: 1.0)
        let rects = bounds.divided(
            atDistance: amount * bounds.size.width, from: .maxXEdge)
        color.set(); UIRectFill(rects.0)


public func imageExample(size: CGSize) -> UIImage? {
    let bounds = CGRect(origin: .zero, size: size)
    let colorSpace = CGColorSpaceCreateDeviceRGB()
    let (width, height) = (Int(size.width), Int(size.height))
    // Build Core Graphics ARGB context
    guard let context = CGContext(data: nil, width: width, 
        height: height, bitsPerComponent: 8, 
        bytesPerRow: width * 4, space: colorSpace, 
        bitmapInfo: CGImageAlphaInfo.premultipliedFirst.rawValue) 
        else { return nil }
    // Prepare CG Context for UIKit
    UIGraphicsPushContext(context); defer { UIGraphicsPopContext() }
    // Draw to context using UIKit calls
    UIColor.blue.set(); UIRectFill(bounds)
    let oval = UIBezierPath(ovalIn: bounds)
    UIColor.red.set(); oval.fill()
    // Fetch the image from the context
    guard let imageRef = context.makeImage() else { return nil }
    return UIImage(cgImage: imageRef)


extension UIImage {
    public func grayscaled() -> UIImage? {
        guard let cgImage = cgImage else { return nil }
        let colorSpace = CGColorSpaceCreateDeviceGray()
        let (width, height) = (Int(size.width), Int(size.height))
        // Build context: one byte per pixel, no alpha
        guard let context = CGContext(data: nil, width: width, 
            height: height, bitsPerComponent: 8, 
            bytesPerRow: width, space: colorSpace, 
            bitmapInfo: CGImageAlphaInfo.none.rawValue) 
            else { return nil }
        // Draw to context
        let destination = CGRect(origin: .zero, size: size)
        context.draw(cgImage, in: destination)
        // Return the grayscale image
        guard let imageRef = context.makeImage() 
            else { return nil }
        return UIImage(cgImage: imageRef)

Okay, I admit the bitmapInfo is still a little ugly, but isn’t the rest of it grand?

  • No more hacky UIGraphicsBeginImageContext()/UIGraphicsEndImageContext() stuff, let alone getting image from context. Why wasn’t it like this years ago?
  • I do love my Swift constructors. Creating the CGRect from the size is much cleaner now.
  • If you want Core Graphics, Swift gives you Core Graphics: there’s still good reasons to create custom contexts (for example, device gray color spaces) or otherwise work at a low level without having to fire up Accelerate, Core Image, or other power frameworks.
  • You can pair the graphic stack context push with its pop if you do need custom context work. I love defer pairs that prepare for cleanup at the same time you do set-up. (We need to extend Swift reference types to allow paired deinit tasks too!)
  • Swift handles all the memory management. All of it!
  • Swift optionals and errors let you fail so much more gracefully.
  • As you’d probably expect, PDF drawing is just as easy as working with images.
  • The “hoisted” CG utilities (like CGRect’s divided(atDistance:, from:) and the context’s draw and makeImage) are lovely too.

I’m seeing the light at the end of the tunnel for Swift Style wrapping up. Anyone interested in me revisiting “iOS Drawing” for Swift? Or are there other topics you’d rather me follow on?

How do I: Cast an optional string to NSString

McFly says: I keep getting the following error and can’t seem to find solution on stackoverflow: “Cannot convert value of type ‘String?’ to type ‘NSString’ in coercion”

First the answer: you have to unwrap an optional before casting it to a different type.  “String?” means a value is stored within an Optional enumeration, which can contain a value or be nil. That’s why you’re getting the error.

You don’t want to force unwrap so you’ll want to conditionally bind that string and cast it to NSString. But before going there, let me step back a moment and discuss why you have an optional string to begin with. You may have used an optional initializer, or called a function that returns an optional string:

let test = "abcdef"
let optionalString = String(test)

Or you more typically may have looked up a key in a dictionary, and your variable is actually typed as Any?, not String?.

let optionalValue = dict["key"]

The thing that kept nagging at me is that it’s pretty rare to pick up optional strings and then want to convert them to NSString. At first I thought McFly was pulling values from a JSON dictionary or the like (which is [AnyHashable: Any]) but the error message for calling a function that expects an NSString value with an Any optional is “error: cannot convert value of type ‘Any?’ to expected argument type ‘NSString'” so no, he really was working with String? and NSString.

I asked McFly why he had a String?, and it turns out he was using this API:

My Post class has the following declared:

private var _imageURL: String?

In any case (leaving apart the sin of naming a string as “URL”, argh), given this scenario, you have two goals:

  1. Safely unwrap the value to get at the string
  2. Convert that string to NSString so you can pass it to the function

Don’t do this:

functionCall(string! as NSString)

Forced unwrapping kills Tinkerbell quicker than kids who refuse to applaud. Instead, conditionally unwrap and *then* cast:

if let string = optionalString {
    myFunction(string as NSString)

(And yes, you usually shadow with the same name as the optional string so you don’t accidentally collide with a different existing symbol. I wanted to make clear the roles of the newly bound unwrapped variable and the existing optional string)

To do everything at once, so you have a bound local variable that stores an NSString instance, you can cast your optional string to Optional<NSString> and then conditionally bind:

if let string = (optionalString as Optional<NSString>) {

This solution is easy for new devs because you can explain: “What you’ve got is an Optional<String> and what you want is an Optional<NSString>, so cast with as, which can be checked at compile time and is guaranteed to succeed.

Experienced developers might prefer optional mapping:

if let string = optionalString.map({ $0 as NSString }) {

This is not an especially obvious solution for new learners. Assuming you’ve already gotten past the basic concept of optionals that can store either a value or nil via the Optional enumeration, picking up the notion of  “mapping” optionals let alone collections isn’t intuitively clear especially without an existing background in  functional languages.

The nice advantage to this approach though is that it easily expands to type-erased casting. Substitute flatMap for map so you don’t conditionally bind an Optional(Optional).

if let string = string.flatMap({ $0 as? NSString }) {

In any case, I told McFly, I’d write this up. And, as it turned out, I cut out about half or more of this post to save for another day because there are some particularly interesting ways that Swift handles casting “Any?” lookups from dictionaries.

As always, I’m sure I probably messed up somewhere in this post, so I invite you as always to offer feedback and corrections. Thanks!


Converting optionals to thrown errors

Soroush Khanlou writes: “Lots of times i just wish there were no optional type, and it was all just `Result`”

He gives this example:

struct NilError: Error { }

func throwable<T>( _ block: @autoclosure() -> T?) throws -> T {
    guard let result: T = block() else {
        throw NilError()
    return result

let image = try throwable(UIImage(data: imageData))

I decided to fancy it up a little:

// Inspired by Soroush Khanlou

public enum Throws {
    public struct NilError: Error, CustomStringConvertible {
        public var description: String { return _description }
        public init(file: String, line: Int) {
            _description = "Nil returned at "
                + (file as NSString).lastPathComponent + ":\(line)"
        private let _description: String
    public static func this<T>(
        file: String = #file, line: Int = #line,
        block: () -> T?) throws -> T
        guard let result = block() 
            else { throw NilError(file: file, line: line) }
        return result

do {
    let imageData = Data()
    let image = try Throws.this { NSImage(data: imageData) }
} catch { print(error) }

The obvious difference is that my errors look like “Nil return at playground13.swift:24” but I also added a few things according to some style choices I’m testing out:

  • No autoclosure. Reserve autoclosure for lazy evaluation. Apple writes, “The context and function name should make it clear that evaluation is being deferred.”
  • No global freestanding function. Embed globals into types as static members.
  • Nested error declaration. It’s a subordinate and specific to the type.
  • Custom description. The error tells you more about itself than just its name.
  • Allman after a multi-line complex initializer declaration.
  • Late private property declaration. I’m kicking the wheels on this, which I picked up from the Standard Library folk.


Update: Loic has a really nice alternative that inspired me to tweak:

public struct NilError: Error, CustomStringConvertible {
    public var description: String { return _description }
    public init(file: String, line: Int) {
        _description = "Nil returned at "
            + (file as NSString).lastPathComponent + ":\(line)"
    private let _description: String

extension Optional {
    public func unwrap(file: String = #file, line: Int = #line) throws -> Wrapped {
        guard let unwrapped = self else { throw NilError(file: file, line: line) }
        return unwrapped

do {
    let imageData = Data()
    let image = try NSImage(data: imageData).unwrap()
} catch { print(error) }