TDD in Swift Playgrounds

I’ve recently been trying my hand at writing a bit of Swift, and one of the things that I do love is being able to try out code in Playgrounds. It’s especially nice to use Playgrounds for coding in isolation from the rest of an app, which can help keep functionality isolated, avoid tightly coupling code, and other jargon phrases besides.

Unfortunately, I can’t use Playgrounds as much as I’d like, because I like to use Test-Driven Devlopment (TDD), and Playgrounds don’t really play nicely with this.

The problem with using Playgrounds for TDD is that once you’re done with your Playground you move the code into your app and throw the Playground away - and along with it all the validation which demostrates that the code is working correctly. When using TDD you’re supposed keep and run those tests, in order to continually validate that functionality as changes are made in the future.

Wouldn’t it be really cool if somehow you could write your code in a Playground alongside the unit tests which validate the code. That way, once you’ve finished your class you could move the code and the tests back into your app, and get the best of both worlds.

Well, the good news is, you can!

Read on →

Making More of the More View

One of the most frustrating things about using a tab bar in your app is that once you exceed five tabs you get the dreaded ‘More’ view - a system component which always displays with stock styling, lacks almost any customisation options, and just seems to have that slight air of desperation about it. In fact the only real way to get the more view consistent with the rest of your app’s design is to create your own view controller, put it in the fifth slot, then start adding the navigation logic for the rest of your app to that manually (which also prevents users editting the tab bar).

But instead of just rolling over and creating our own custom more view, though, I wanted to go ahead and customise the one that Apple already provided. What’s more, I want do it without crazy runtime hackery, without subclassing anything, and with safeguards against future implementation changes in the system components. So, in this post, that’s exactly what we’re going to do.

Read on →

In Search of the Longest Method

Objective-C programmers are famed for their discursive nature. A good Objective-C developer will never use three or four words when a couple of thousand would easily do. We treat header files as carefully crafted essays, surprising and delighting the casual reader with innovative word play and thesaurus-stretching prose. After all, the argument goes, we have excellent code completion in Xcode, making even the longest method only a few keystrokes away - why not take advantage and let our imaginations take flight?

In light of this, the question arises every now and then: what is the longest method in all of Cocoa? Which method name stands head and shoulders above all the others, looking down upon its brothers with an air of smug superiority?

Read on →