Swift Journal: Day One


Learning a language is sometimes confusing

I decided to jump right into Swift without doing any research into the writing done over the past month so that my opinions were not colored. My background is in the C/C++ and, lately, Objective-C of which I’ve become quite fond. I approached Swift with the hope that it would provide the same kind of  power I’ve found Obj-C/Cocoa to have, but with some modern newness brought in from other successful languages. It is too early, and the tools are too fresh, for me to draw conclusions on how useful it will be for production code other than that it does look promising.

TL;DR after the jump wherein I detail experiences with the Xcode playground and a small Swift based iPhone app.


  • It took only about a ten minute glance over the language docs to be able to port my C code to Swift
  • Explicit control of nil behavior such as when to require non-nil objects
  • Enums are first class types along with classes and structs
  • Property system like Objective-C’s with custom getters and setters
  • Aspect oriented features on the properties,




  • The beauty of every callable block being a closure: global functions, nested functions, class methods and traditional lambda style closures
  • Syntax shortcuts when they make sense like leaving off

    for a readonly calculated property or


    for one line closures


  • Tools: the playground, compiler, all are early versions and have problems; but we know that, and that’s why we will be shipping Obj-C apps for a while
  • The syntax is a step back from the terseness of Objective-C towards the explicitness of C++ (Python users are laughing right now; and yes Obj-C names are wordy, read that as “readable”, but the syntax mostly stays out of the way)
  • No headers; wade through the implementation to find the declarations you need (somehow Swift’s type declaration file avoids this)
  • I don’t think I like the declaration style 
    var x: Int = 4

    which reads like “assign something to SomeType” to me

  • It took some fumbling to figure out how to define outlets and actions in my first Cocoa Touch app (where are these language extensions documented?)


Beef up your text editor on Mac OS X

Work horses

Link your app to something more powerful


This is a gentle reminder that you are not forced to limit yourself to any app’s built-in features when you work on Mac OS X thanks to Services with an assist from Automator. I recently utilized Automator’s Run Shell Script action to create a needed function in Xcode’s text editor.

My problem is that I follow a style guide that limits line length to 80 characters. I usually don’t have trouble with this. Xcode will show a gutter line to help prompt me to break my lines around the limit. But when editing multi-line comments it becomes a pain to reflow the new text. Other editors can do this without my help.


Retraction: Large Data Imports with AFIncrementalStore Are Painful


I know. I’m sorry.

Last time I wrote about doing imports of large data sets when using AFIncrementalStore to handle server synchronization I thought I had made an end-run around it, finding a technique which was compatible but faster. I was wrong.

Before I begin, this is not a knock on AFIncrementalStore which does its job well overall. It was my first use of this library, and I have no trouble recommending it for certain uses cases.

After my last post, when I started to test more thoroughly and use the imported data, I saw strange things. Mostly that meant my objects relationships were not what I expected.  I’m fairly sure I had seen these relationships created as they should be, but in the fog of the battle which was my work on this feature, I can’t say for certain. My bad. (more…)

Painless Imports With AFIncrementalStore


Imports can be, in a word… (photo by freefoto)

Before taking this advice, please see my follow-up.

AFIncrementalStore (AFIS) is a brilliant bit of open source code from Mattt Thompson. It is a great help in synchronizing a remote data source and local data storage handled with Core Data. Its magic is turning the Core Data API into a single interface to both what is on the device and on the server. Data consumers need not worry where the data resides before asking for the data. Just perform a fetch request, and AFIncrementalStore will query both the local store and the remote side to make sure that all data returned is up to date as best as it can.

There is a use case where this model fails, but that’s not a problem if you know how to deal with it.


“GPU” Moves Closer to Being “General Processing Unit”

audio reactive sphere
(Audio reactive sphere by Andreas Köberle.)

For years it has been possible to write general purpose code for those data crunching cards almost all of us have in our devices by using tools like NVIDIA’s CUDA and OpenCL, but that power is rarely applied to non-graphical tasks except in high performance computing.

This article passed my attention many weeks ago, but I only recently came to read it. Two researchers implemented a finite difference simulation of a cymbal-like instrument which runs on a Mac’s GPU. (more…)