The amount of work it took to port this to Swift (and pure Swift at that) was simply ridiculous.

First the good bits: Swift constructs like tuples, reduce and map made some code a lot nicer. My subpath length code looked like this: “return pairDistances.reduce(0.0, combine: {$0 + $1})”, where pairDistances were built from a generic array function that combined adjacent elements into 2-tuples and then combined into distances.

And the less good bits. You can’t compare CGPathElementType instances, so you have to use “.value” everywhere. CGFloat-land residents don’t live happily in Double-world.

And the really bad bits. You can’t use CGPathApply at all because reasons and CGFunctionPointers. So I ended up parsing the string descriptions of Bezier paths. No, really.

I designed everything so when Swift does support UIBezierPath decomposition properly, I have all my BezierElement structures in place, ready to go. Until then, this is a bandaid.