Tag Archives: objc

Core Int 242, Swift, and verified Twitter

From the show notes for today’s episode:

Manton reacts to negatively to the Swift 3 decision to disallows subclassing by default, while Daniel tries to see the bright side. The two discuss Twitter’s new invitation to apply for @verified status, and Daniel’s attempt to do so. And they quickly touch base on the upcoming Apple-sponsored reality show, “Planet of the Apps.”

Believe it or not, I was kind of holding back a little in my Swift ranting. But it was the most critical I’ve been on the show. And it’s totally okay for you to disagree! Maybe even good for the platform if you do.

Apple’s mindset on Swift dynamic features

I let myself go off into a bit of a Swift rant on the latest Core Intuition. I’ve been doing a lot of Swift development recently. The more I use it, the more conflicted I am. I really love some parts of the language, but it’s not what I would have asked for as a successor to Objective-C 2.0.

Remember when Steve Jobs came back to Apple and compared NeXTSTEP to constructing a building by starting out on the 20th floor, with so much of the foundation and common patterns already taken care of for you? Cocoa allowed apps to be built significantly faster than before. Steve said at Macworld Expo in 1997 that the goal was to “eliminate 80% of the code that every developer has to write for their app.”

Swift is not like that. Swift’s priorities are correctness and stability. These have more indirect benefits to developer productivity than we saw going from Carbon to Cocoa.

When Marco Arment wrote about Swift last month, he mentioned wanting a language designed for high-level apps:

Objective-C wasn’t much better for this, but I think we could’ve done better than Swift if the most important goal in Swift was maximizing real-world developer productivity when writing modern Mac and iOS apps. Swift does a little of that, but gives up a lot to also serve lower-level, more clever, language-geekier goals.

This weekend, Brent Simmons has a new post about the loss of dynamic features in “pure” Swift:

What makes me nervous is Swift’s emphasis on type safety and on compile-time resolution. As long as we also have what we need from Objective-C, then that’s fine — then we still get xibs and storyboards, the Responder Chain, and so on.

I hope Brent’s right that this will be a core part of Swift 4. Leaning on the Objective-C runtime feels like a temporary solution because it only exists on the Mac and iOS. Great web frameworks like Ruby on Rails, for example, can’t be built without relying on a more dynamic language. (And to me a great promise for Swift is being able to use it everywhere.)

Daniel Jalkut followed up with a more optimistic post. He thinks Apple is on top of this, even as he acknowledges the clash between existing frameworks and the new language:

Some major design priorities of the Swift language, namely type safety and compile time dependency binding, are at odds with the design priorities of 20 years of evolution in Apple’s frameworks. How and if that disparity will be reckoned by Apple remains to be seen.

I think it’s telling that the “dynamic” keyword isn’t even mentioned in the main language guide. Anything related to Objective-C is off in a separate set of documentation, which includes discouraging statements such as “Requiring dynamic dispatch is rarely necessary” and “use of the performSelector APIs is discouraged”. For Swift to thrive in the future, as a great language for newcomers and long-time Mac developers, Apple will have to compromise on that mindset.

I think it’s a bust

The movie Draft Day doesn’t really have any business being good, but somehow it is anyway. I don’t even like football that much — who has time for it when there’s basketball? — but I’ve now seen this movie several times and love it. The movie actually gets better instead of worse on multiple viewings.

It also has a number of memorable lines. One of them is this, said by Kevin Costner’s character about the college football star who everyone thinks is the next greatest thing: “I think he’s a bust.” Five simple words that undo all momentum.

And unfortunately that’s still how I feel about Swift. I’m following Brent’s blog posts about learning Swift and I’m trying to come to terms with whether to adopt the language, and I finally got it. I already have a capable quarterback in Objective-C, and I’m not ready to rebuild my roster yet, risking everything on a young language with so much promise but less real-world success.

No matter how much Swift has improved, no matter how much everyone fawns over it, I still can’t shake the feeling that it’s a hype that someone else’s team needs. For me, it won’t end up solving the problems I have when building apps. For me, it’s a bust.

Learning from Rails design

Since version 2.0, “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/ has had a built-in web server for serving music and photos to the Nintendo Wii. The server was written in Cocoa and the code became very unwieldy as I continued to add features. Dozens of methods for processing different parts of the URL, and many if statements for conditionally branching based on the URL, splitting the URL parameters, and more.

The code looked something like this (only worse):

if (path startsWithSubstring:@"/albums") {

[self processAlbumsRequest:path];


else if (path startsWithSubstring:@"/artists") {

[self processArtistsRequest:path];


else {

// ...


(void) processAlbumsRequest:(NSString *)inPath


// split out the parameters and request extensions from the URL path

// ...

if ([e isEqualToString:"xml"]) {

// ...


else if ([e isEqualToString:"html"]) {

// ...



Multiply that times 10 for all the different URLs that Wii Transfer knows how to process, and you can see how it worked fine for a couple simple things, but quickly became a mess as I added features.

For the upcoming version 2.3, I redesigned most of the URLs to follow a common structure, patterned after the default URL syntax that Rails uses: /controller/action/id. Now, instead of if statements, I dynamically route the URL requests using NSSelectorFromString() and performSelector:withObject:.

Consider this code (as above, simplified from the real thing):

// extract the values from /controller/action/id URLs

NSArray* pieces = [[path stringByDeletingPathExtension] pathComponents];

NSString* controller = [pieces objectAtIndex:1];

NSString* action = [pieces objectAtIndex:2];

NSString* param_id = [pieces objectAtIndex:3];

// call a method named controller_action, passing it the id

NSString* sel_name = [NSString stringWithFormat:@"%@_%@:", controller, action];

SEL method = NSSelectorFromString (sel_name);

[self performSelector:method withObject:param_id];

Now if I need to invent a new URL, say “/tracks/play/1234.mp3”, all I have to do is write the implementation for that method:

- (void) tracks_play:(NSString *)inParamID


// ...


The web request calls through to this new method without any additional glue code, in this case passing “1234” in the single parameter.

(The underscored method signatures aren’t very Cocoa-ish, but this is actually a plus because I can quickly spot the chunk of the controller that processes a set of requests, and I like that they read just like the URLs. I’m also currently using a single controller instead of having separate controller objects for the different types of requests, but I may expand that later.)

This convention has also allowed me to simplify all the URLs that Wii Transfer uses. Other examples include “/covers/search/U2” or “/artists/show/5”. I’ve eliminated a bunch of code, and it fits nicely with how I serve application resources and the start of a HTML template system.

Could it be taken further? Sure. I remember in the Mac OS 9 days building a web interface for a product using only compiled AppleScript scripts stored in the resource fork. Lately, folks like “Gus Mueller”:http://gusmueller.com/blog/ and Adobe’s Lightroom team have been doing interesting things with “embedding Lua”:http://www.sqlabs.net/blog/2006/01/adobe-lightroom-and-lua.html. I don’t want that level of extensibility yet, but it seems like a logical next generation when I outgrow even this new web architecture in Wii Transfer.