Just had a response to a radar (thanks Apple Swift team) that you can now implement Objective C protocols with generic Swift classes. This means that you can make typesafe and composable classes to do much of the work for many UI objects without ugly wrapping code and indirection.

This example shows a really basic example and should work in a playground.

In production code I would not initialise the table view cells in the closure but would make the closure but would probably take either the table view as an argument and directly dequeue cells from it or would take the cell as the argument and only configure it in the closure. Still this approach allows much of the boiler plate and common code to be abstracted. The next level may use a similar approach to make each section and an array of such structures could be used to make the whole table (or collection) view.

There is still work for the Swift team to do as I don't think that you can implement the Objective C protocol in an extension to a generic yet. I can't think of a reason why it wouldn't be possible and I'm confident it is coming.

@jl_hfl You should be able to use an extension. What problem do you hit if you try?

— Joe Groff (@jckarter) September 15, 2015

This post is a response to David Owens' Swift Resistance Explored post.

First I want to acknowledge that Swift Debug builds are hideously slow. This isn't news to me or anyone who has seen my talk on Swift optimisation. To be clear this is a problem which Apple have said that they are working on but I still don't think it is an absolute block on any real development because there are fairly simple workarounds.

If you want to see the code under discussion it is all in my repository here with a log of my development. The first commit is the Zipfile that David made available in his blog post, the rest is my testing and development of the Swift version.

These are my performance figures (for 100 runs so it isn't directly comparable to David's):

Read more