Sofa's blog about design, code everything else.

Objective-C is a great language, but lots of people are looking into building native Cocoa apps in the languages they know and love. Interesting technologies like MacRuby have emerged, with small but strong communities around them and it became time for someone to organize the first official event for this. Thijs van der Vossen from Fingertips did exactly that with the first MacRuby conference held in Amsterdam last friday. He asked me to talk a bit about our experiences shipping an application in an interpreted language, and designing Mac desktop applications.

Presentation Transcript (Edited for the Web)

First some confessions. We're not a Ruby place at all. We build most of our stuff in either Python or C/C++/ObjC. And regarding myself, while I started out designing and developing, we now have way better developers and designers in our company than I was, and probably will ever be. So even though I will talk about programming, please keep in mind I'm probably the least qualified person in this room to actually do so.

So what to talk about then? I came up with two things…

Part One: Writing Cocoa Apps in an Interpreted Language

The first one has everything to do with Checkout. Checkout is our biggest application which is available in most Apple stores worldwide. It was built built entirely in Cocoa/Python using the PyObjC bridge. That makes it–to my best knowledge–the only commercial shipping app for the Mac that's written in an interpreted language. So I thought it might be interesting to share what we learned about that.

Legal & Commercial Risks

Let's start with the most boring stuff, but most often asked. How do you protect your app if you ship it with source code? We all understand that it's way easier to reverse engineer an interpreted app than a compiled app. My advice here would be to not care about it on a technical level, but protect it through the law. It's easy to spend hours trying to obfuscate your code, but there is no way you can protect it from some smart evil dude that has his mind set on getting it. Instead, spend those hours studying what can be done legally if this happens, and make sure that you can act. To this day we have had no problems with this at all, but we sure know what to do when it happens.

Using the Non-Official Technology (Ruby over Objective-C)

Let's face it. You'll be a second class citizen on the Mac platform. Although Apple made promises otherwise and has some really smart people working on it (thanks Laurent!), it's hard to deny that more effort is spent on technologies Apple itself uses to build apps than on MacRuby/PyObjC. So building your app will make you dependent on the community you build around it and with a pretty niche combination of technologies like this, it can be pretty volunteer-dependent. So yeah, that's a risk. Fortunately Rubyists have built many of these communities that work perfectly well–even to the point that you could argue that it might work better than letting Apple handle it (ever filed a radar bug?).

What Can You Do Better Than Obj-C Coders

How many people here have built professional Ruby web apps already? I bet a huge group. That gives you quite an advantage over Cocoa programmers. I'll go over some examples.

Frameworks & Libraries

Ruby has a ton of gems that do great stuff Cocoa can't yet. I mean CoreData is cool, but ActiveRecord lets you build networked SQL apps really easily (we do this in Checkout with SQLAlchemy). I can think of a ton of stuff that's so much easier to do with ready made gems like serialization, xml processing, mail processing, prediction algorithms, socket networking etc… But also, sometimes buggy Cocoa behaviour can be substituted easily with some Ruby solution that is tested and ready to drop in. We also experienced this a lot with Checkout (you damn NSNumberFormatter!)

Tools & Tests

Xcode is great. You can use it, but sometimes it's better not to. There are tons of Ruby build tools out there that integrate with your favorite IDE. For example, we do automated builds of Checkout with a bunch of python scripts that put it on custom designed disk images and we love TextMate and Espresso for coding. Testing is also a lot easier than in Obj-C. Languages like Ruby makes it easy to apply the agile test-driven development that we all like.

Skills

As web and Ruby programmers, you know lots about technologies like networking, persistent data, HTTP, SQL and REST. These aren't skills that a lot of programmers have, so leverage it for your app. Build a Tokyo Tyrant backed API to store data from your app online. Or deploy it on one of the many stacks available like Heroku and start selling subscriptions as an add-on to your app. Or build an app that locally shares data by using Bonjour and Memcache. That's everyday stuff for you guys, but seems like magic if applied to desktop apps.

Part Two: Building Desktop Apps

Having said all that, let's look from the other side. You guys are great at building webapps but you're moving into the Desktop space, which is quite different, especially on the Mac. Here are some pointers that might help.

A New Experience.

As with web apps it's all about the experience of using it. On the web you can have so much control over that experience, and in a way, that saves you a lot of time. On the desktop, people expect stuff like logical keyboard shortcuts, undo, copy and paste, drag and drop, multiple windows and falling asleep. If any of those things is not there, the experience will be bad regardless of the rest. So the bottom line is that you will have to spend a lot more time on stuff you probably never really had to think about.

But with great control also comes great responsibility. If you are planning to go wild on your UI keep in mind that Mac UIs tend to look the same, within certain rules (for the basics check out Apple's HIG). So before you use that font or start animating entire sets of windows, make sure you know how that will influence the user experience.

Side-note: The Mac UI is always changing. Currently, the iPhone has a huge impact on how stuff starts to look on the desktop but interface designers try to use the stuff that makes sense on the desktop. For example, we're trying to redefine how desktop scrollbars should work because of that, but that's another story.

Snappyness

Interpreted languages are not as fast as C/ObjC. And that is almost never a problem. Still, I notice people are pretty sensitive about this and spend hours of coding to make that one routine 20% faster. But to the user, 20% faster slowness is still slow. Instead of engineering, focus on how it ‘feels’ to the user. Show precise and fancy looking progress indicators, start displaying partial content if you can, or make your app in such a way that you can do other interesting stuff while it's crunching. For some good examples check out how iPhone apps like mail deal with this. They're slow, but still feel ‘snappy’.

Get Design

There is really no way around this. You might be really great at coloring squares with css and doing typography with 3 fonts on the web, but with more control come higher user expectations. This is especially true on the Mac platform, where there’s a very distinct idea about what is done and not done regarding UI graphics and icons. The hard thing is nobody can actually express it, but everybody seems to recognize it. I guess it comes pretty close to art in that regard. A cool side effect is that when you get it right, you get a lot of free advertising from the community. People will try out your app and write about it even if they’re not the target audience. True viral marketing through a good UI. So take a good honest look at your design skills and decide if you need to find someone to help you out there. We try telling everyone that it pays off to start with a full-time designer on board, but that’s a little out of scope for this presentation. If you’re building something really awesome, be sure to give us a call ;-)

So I guess that’s what I could tell in about ten minutes. I hope it’s useful to some of you, and wish you lots of fun building Cocoa apps.