My Experience Building a Small Mac App in Swift

I dabbled with a Mac Sprite Kit game over the summer and was generally pleased with the experience. The last couple of weeks I put together a small full Mac app(Restaurants) currently under review on the Mac App Store (Update: now released) written largely in Swift. Here are a few notes from my experience. As you read them, please keep in mind that the last Mac Cocoa app I built was in 2003 (pre Cocoa Bindings even!). Since then all my Cocoa programming has been iOS. Also keep in mind, while I have a formal CS graduate education, I am a very applied guy, so I might not always get the theory parts/terminology right here.

Cocoa Bindings
Having not built a Mac Cocoa app since pre-Cocoa Bindings, I was amazed with how convenient this technology is (and a little disappointed that it never made its way to iOS). It relies on KVO/KVC of course, which feels like a bit of a hack in Swift (make sure to use the dynamic keyword). It would seem that there is a lot of room for improvement/new innovation in Swift with more advanced versions of property notifiers like didSet/willSet taking the place of KVO/KVC somehow (although I haven't yet figured out how). Ultimately everything did "just work," including doing Bindings between Swift interface elements with Swift objects that have properties which are Objective-C objects, which speaks to how well the two languages really do integrate.

Objective-C Integration
Speaking of Objective-C, the library for interacting with Yelp used in Restaurants is written in Objective-C. I modified it a bit as I worked and once again it was impressive how things "just worked" when called from Swift. Clearly this language was designed for that purpose. The bridging header is short and simple enough, but like dynamic, it also feels a bit hacky.  Once when I created it manually (and even setup the project settings correctly I thought), the linker didn't recongnize it. It seemed like only when Xcode created it for me, was everything setup correctly (yes I specified the name of the bridging header). It could be that I made a mistake in the project settings - but I do think things should be more automatic. Can't the bridging header be created for us at build time when Xcode detects the project has a mixture of Objective-C and Swift code in it?  Ah... first world problems.

Sometimes it was unclear to me as a Swift newbie how some Objective-C method parameters should be provided from Swift as far as type signatures go. Better hints in Xcode would be helpful.

Optionals
Although I've worked in a lot of different languages over the years, I never have worked in one that made such extensive use of optionals (Haskell has maybe - feels like sorta the same thing to me, but I only did Haskell for a few months). Do optionals make the code safer? Yeah it feels like they do - a little bit - although I still created errors for myself occasionally by unwrapping nil optionals - so clearly we can't completely protect ourselves from ourselves. But I also now have an inoordinate amount of boilerplate if let statements.

The big problem with optionals though is interacting with the Cocoa frameworks. I feel like Swift was designed for most variables to be non-optional, non-nullable values (I could be wrong of course) and optionals are supposed to be the special cases. But instead, due to having to work with the Objective-C Cocoa frameworks, almost everything is an optional. It's annoying - the boilerplate is annoying, the unwrapping is annoying, and the cognitive overhead of deciding what should be !, ?, etc. is annoying. Personally, while I feel I fully grasp the concept and I appreciate the safety, it hasn't been worth the loss in productivity for me when dealing with Cocoa.

Syntax
There have been a lot of comparisons saying "it's like this or that language." For me, someone who has spent the last few years programming professionally in C, Objective-C, Java, Dart, JavaScript, Python, Ruby (so mostly C-like languages except the latter two) but with significant exposure to some more academic languages, Swift doesn't quite feel like any of them. It does feel fresh. It does feel like an amalgamation of some of the best ideas of each. Just the lack of @ symbols and headers makes it more compact than Objective-C (and I like Objective-C a lot). I honestly think it's the optionals again that stops it from being perfect for me. It feels like there are too many ?s, !s, and if lets littering my code. Frankly I think that sort of stuff is what makes a language a bit hard/not fun for a beginner to grasp (and I'm the author of an absolute beginners programming text and do teach beginners professionally so I know something about this - this might be the only opinion of mine here that shouldn't be taken with a grain of salt).

Philosophy
Like every mainstream new language out there, Swift tries to bring the best of the functional world to object-oriented programmers. I think it largely succeeds. I'm even worried the community is going too far in the functional direction. I'd like to see more of an emphasis on the object-oriented features of Swift in the future. On a day-to-day basis, that's the world I think/work in, and I think that's true for most Mac/iOS developers. It's great to see the energy, enthusiasm, and contributions of the functional folks who have gotten involved with Swift. I look forward to taking advantage of it. However, my work is so much more about building intelligent class hierarchies than it is about building cool recursion tricks (ha that sounds awful and debasing - didn't mean it that way!).

Also, I appreciate the dynamacism of Objective-C. Like many have said, Swift feels more like C++ (and my understanding is that its method dispatch is more similar to it than Objective-C (please correct me if I'm wrong)) than Objective-C. Maybe we need that for the speed advantages, but that's awkward when we have to deal with these huge Objective-C frameworks all_the_time. I saw someone propose on the Apple developer forums that the dynamic keyword should be default. No, I don't think we want that slowness by default. I think what we want is to take full advantage of new, better ways of doing things, than what we had available to us in Objective-C. But we're handcuffed by Cocoa. I think Swift won't start to really have its own voice/come into its own until we have Apple frameworks written in Swift.

Bugs
I had Source Kit crashes. I had weird, unexplainable errors. I had bad syntax highlighting. Generally things got slightly better over time but some of them I still can't explain. Unfortunately it's not very easy to explain how to reproduce all of these bugs in Radars. I feel like it would be helpful if it was easier to just share full projects with the team somehow. Here's a radical idea - what about adding a built in screen capture video tool in Xcode that could also send your source code (with your permission of course) straight to Radar. Too much potential for hackers maybe?

Working on a small app, I didn't encounter some of the slow compilation issues that a lot of other people have. In general, I found the actual compiling/running process to be pretty pain free.

Community
The Swift team at Apple has been awesome on the Apple developer forums. Some cool sites have popped up on the Web like sososwift.com and others that aggregate high quality material. However there's also been a lot of negativity, which is understandable given how invested some people have become in the language given the obviousness of its future as the premier Apple sanctified language. A lot of the tastemakers who are updating their Cocoa books for Swift have been particularly vocal. I appreciate that - I wrote a book about Dart starting when it was still in beta and nothing is more frustrating than changing something big when you're going to print. But that language faced relatively few changes/bug issues compared to Swift in its early development (they also made the first public beta release a full 2 years before I started, so it's not a fair comparison).

Swift has attracted an interesting combination of long time Apple developers, brand new Apple developers, and people from the functional programming world. Sometimes it feels like these three groups are speaking Greek to each other. There are regularly code snippets on the Apple developer forums that I, a long time developer, don't fully grasp without careful study. We need coding standards, and we need more direction from Apple regarding conventions and style. We need more sample code. We need the first few books by the people most invested in Swift to come out from the major publishers. Then we'll see where the cards fall and which of these groups will get the most pull in the Swift world.

Anyway, that's it for now. I will not be doing my next big client project in Swift, but I will continue to use it in my personal projects. I also posted this on the Apple developer forums.