Hacker News new | ask | show | jobs
by msarnoff 4339 days ago
I'm a little disappointed with the scope of this writeup. I just finished my first full Swift app this weekend, and by far, the most bothersome part was interacting with the C APIs (CoreMedia, ImageIO, etc.) I would have loved to see more examples of interacting with framework objects like CGImageSources, CMSampleBuffers, etc.

For example, CGImageSourceCreateWithURL() returns an Unmanaged<CGImageSource>!. You can't pass that object to CGImageSourceCreateImageAtIndex(), because it expects a CGImageSource!. Instead, you have to call takeUnretainedValue() on the Unmanaged to extract the raw pointer. Not terribly difficult, just mildly annoying and not well documented. In C/ObjC, you'd just take the return value of the first function and pass it right into the second.

Another example: CMSampleBufferGetImageBuffer() returns a CVImageBuffer!. And CVPixelBufferLockBaseAddress() takes a CVPixelBuffer! as its argument. In C/ObjC, CVPixelBufferRef is typedef'd to CVImageBufferRef, but that doesn't carry over in Swift. I tried to figure out the opaque-pointer voodoo required to convert from one to the other, and eventually gave up, wrote the function in Objective-C, and moved on.

Swift is shaping up to be an excellent language, but at this point, the casting/wrapping/unwrapping hurdles make it difficult for newcomers and experienced developers alike to take advantage of Apple's 15+ year corpus of powerful APIs.

2 comments

I, too have found the type system to be a bit tedious at times, especially with Carbon. It also doesn't help that SourceKit crashes often while doing crazy things with types. I've just been reverting back to ObjC for these specific things (plus better error messages and tooling).

But looking back, the first versions of ObjC were also kind of tedious (no @property declarations, no blocks, etc) and it's gone a long way.

Hopefully the pace of language development will be a little faster!

Putting snark to one side, is it a general principle that languages evolve/develop more quickly now than in olden times...

> I'm a little disappointed with the scope of this writeup.

There's a teaser at the end that there will be a follow-up article about UnsafePointer.

I just hope they hurry up and post it soon. I have half a large app that relies on UnsafePointers, and I could really use some clear documentation to reassure myself that I'm not abusing them.

Likewise, I'm running into UnsafePointers with IOKit.