Posts tagged dev
Doing things the hard way

This year, we gave a talk at GDC called “Making Night in the Woods Better with Open Source”. In it, we talked about how Night in the Woods, which came out last month and you should totally go buy, used the open source process in its development.

Unlike most of our other talks, we did something a little ridiculous with this one - we built an entire presentation system, from scratch, into Night in the Woods. We’re actually pretty proud of this, and so we put together a video showing how it was done. Check it out!

The talk from GDC is also available online, and we've embedded it below:

Open Data + Video Games = Win

At 2016, in Geelong, we presented a talk on our experiences building video games at open data hackathons, such as GovHack. The video and slides are now available! The video is available on YouTube, and embedded below, and the slides are available on SpeakerDeck.

We had a great time preparing and delivering this talk! You can check out our GovHack entries from 2014 and 2015 online.

Thoughts on WWDC14

Some quick thoughts from Secret Lab on the mind-blowing collection of WWDC 2014 announcements from Apple.

OS X Yosemite

Pretty! Made simpler. Not super sold on translucency, though.

Handoffs and Continuity is awesome. Will be super useful. Devs get access to this too. Reminds us of the excellent “Send to Chrome” feature in Android. Only really polished.

iOS 8

Not a huge amount of new stuff, visuals wise; however, there are some awesome behind the scenes changes.

Custom Actions, Photo Editing, Sharing Options can all be provided by apps. You can make your app provide services to other apps. This is AWESOME - it’s going to make the app ecosystem quite a bit richer.

Android’s had this for some time, and it’s great to see it in iOS.

The ability to put widgets in the notification center is also great, lots of devs are going to make some great stuff with this.

Being able to share documents between apps without having to copy them is going to be Super Nifty. This has been a real weakness of iOS until now.


WOW. Apple developed an entire language, wrote all the docs, and wrote all the supporting tools for it, without it leaking. This is really impressive.Can’t wait to use this.

The language is very modern. Its syntax feels like a mashup of Python, Haskell and Ruby.

Interoperation with Obj-C is rather nicely handled. They’ve directly translated ObjC’s arguments-are-embedded-into-method names approach into named parameters. The goal was clearly to make it as painless as possible to work with both languages in a single project.

Something that’s interesting is it’s completely opposed to Objective-C’s way of doing things is that, while ObjC allows sending messages to nil (thereby making it safe to not have to do null checks), Swift instead guarantees that all values that are not Optionals are non-null. Optionals are a very cool feature: in other languages, the concept of “nothing” is usually represented by a special value (for example, Lua’s ‘nil’ value), or by convention (for example, in C, the value 0 means ‘nothing’). This creates its own problems; if you use a special value, comparing it to other objects means you have to do type conversions, and if you instead use the convention of zero meaning null, you have to do checks. Objective-C goes some of the way towards helping with this: it defines ‘nil’ as a special value that’s represented a zero pointer, but calling methods on it is safe because the runtime automatically returns if it notices you’re trying to call methods on nil.

This is nicer than crashing, but it can lead to problems, since if an object you’re trying to work with is unexpectedly nil, you’ll get bugs. Not crashing bugs, but weird behaviour bugs.

The Optionals system is nicer. In Swift, a value is either guaranteed to be a valid one, or else is explicitly known to sometimes be nil.

For example: if you’re converting strings to integers, your code looks like this:

let theString = "123"

let theInt = theString.toInt()

In most languages, the ‘toInt()’ method would return a value that represents ‘not valid’, such as 0. But in Swift, it returns an optional int - that is, a value that MIGHT represent nothing, but if it doesn’t represent nothing, then it’s GUARANTEED to be an integer and nothing else.

This makes things quite a bit safer, since the compiler’s able to do more checking, and is able to reason about your code better.

Swift is filled with this kind of thing. Another example: in C and similar langauges, the assignment operator (=) returns a value, like this:

a = b = 3 // sets both a and b to 3

In Swift, that doesn’t apply. This means that the following is actually a compiler error (it’s just a warning in ObjC):

if x = y {


We’re not huge fans of the range operators: a...b means “range from a to b, including b” and a..b means “range from a to b, not including b”. Notice that they only differ by a single period. That’s going to lead to bugs, due to typos.

The mutability of variables depends on whether or not the variable is declared as a constant or not. This is nicer than Objective-C, which has two different classes for each type based on whether it’s mutable or not (ie NSString vs NSMutableString)

This only applies to strings, arrays, dictionaries, and other low-level things. We’re still going to be stuck with NSURL vs NSMutableURL for a while.

Playground is super cool. Reminds us of IPython, in that you can figure out your code without it having to be run inside a larger app. This is going to make development a lot faster.

App Store

Being able to show videos and make app bundles (with discount) is going to be neat. Not a huge game changer for us, but any increase in app store functionality is good.

Storyboards and NIBs: A Rebuttal

Beneath the relatively placid surface, a battle is raging among iOS developers.

On one side, we have developers who use the built-in visual interface development tools for constructing their screens. On the other, we have the code purists, who insist on entirely generating their interfaces from code.

Storyboards have a number of important advantages:

  • Seeing your design means thinking visually
  • Storyboards let you see how apps flow together
  • Storyboards are the only way to use segues, which are a marvellous way to handle the transitions from screen to screen.
Screen Shot 2014-02-10 at 1.40.28 pm.png

Apple vigorously promotes the Interface Builder and the use of Storyboards, but there's a surprisingly large number of developers who insist on not using them. One famous example is Google, who, as of 2012, apparently forbade the use of storyboards and XIB files, as well as checking in .pbxproj files (that is, the actual project files used by Xcode to organise where files go.) The reasoning provided is that merging these files is too much of a challenge.

Google aren't the only ones insisting that storyboards aren't a good idea. There are dozens of examples of developers promoting this viewpoint, and here are the most common arguments we see.

"Programmers should code, and not do visual design. You should know how views work from the ground-up, and being able to code your interface is more extensible."

A good programmer knows more than just than their specialty. The argument that programmers should only focus on the written component of their apps implies a separation of skills that simply isn't workable in mobile apps: if you're making an application that relies on the user holding a screen in their hand, deliberately not thinking visually means that you'll be more likely to not catch small visual problems in your app's design.

There's a lot to be said for understanding views and view controllers from the ground up, for the same reasons as understanding any other topic in programming: knowing as much as possible about what's going on behind the scenes makes it easier for developers to make more advanced use of the technology. However, this isn't an argument for avoiding the Interface Builder - understanding how views work doesn't require that you manually create them in your code.

"Creating re-usable views is harder. Also, custom views are hard to see in IB, they're just white boxes."

Another common argument against using storyboards is that using custom views is harder. For example, if you've got a view controller that needs to use a custom selector view of some kind, embedding a view that you've designed in a XIB can be a pain.


  • Using the Interface Builder doesn't mean that you have to use the Interface Builder for everything. You're still free to embed a custom view, set its class, and then provide a loadView method for that class to manually create the view hierarchy for that class.
  • Embedding view controllers using container objects is straightforward. If you need to embed a collection of views elsewhere, or if you want to break out the logic of a screen into multiple sub-units, use the Container View object to break out a collection of views into a separate view controller.

A related argument that we see is that custom views just look like empty white boxes in your view controller's designs. Technically, that's true - if you drag in a generic UIView, and set the view's class to your own, it'll still appear as a generic white box. However, this argument against storyboards ignores some important facts:

  • Unless you care about the contents of your custom view, seeing a preview of your view isn't a requirement for constructing the rest of the screen. Positioning and sizing the view on the screen is the most useful feature, and that's what you get.
  • A number of important, Apple-provided views also appear as empty boxes. The point isn't that you get to see the content, but rather that positioning and arranging the view in the screen is significantly more straightforward.

"Auto-Layout sucks, and doing the layout yourself is easier to understand."

Auto-Layout has received a significant amount of criticism since it was introduced, and many developers argue that the older method of struts and springs (as well as defining frame rectangles for each view) is easier to understand.

This was a fair criticism - in Xcode 4, constraints were a huge mess, and it was very difficult to understand how re-repositioning a view in the Interface Builder would affect the constraints.

However, Xcode 5 and iOS 7 has simplified this considerably. You no longer receive a soup of vertical and horizontal blue lines, and controlling the position and size of views using constraints that you design in the Interface Builder is simple and straightforward.

"Using storyboards means designing your interfaces in Xcode, which is slow and crashy."

Xcode doesn't have a great reputation for stability, it's true. However, the time lost to re-launching Xcode after a crash is miniscule compared to the amount of additional time you'll take designing, testing and debugging your layout code.

(Xcode's still the worst IDE ever built, but that makes it no different to every other IDE.)

"Dealing with lingering outlets leads to crashes."

It's a common situation: you link a view to a class using an outlet; later, you decide you don't need the outlet, so you delete it from your code. You run the app, but the view still wants to connect to the now-deleted outlet. Your code crashes. You scream with rage.

This is a reasonable criticism - Xcode should at least provide a more visible warning that the property is missing. However, it's nowhere near enough of a reason to forswear ever using it.

"Merging sucks."

This is the only valid major criticism, and is the major one that causes organisations to ban the use of storyboards and XIBs in their codebases.

However, starting with Xcode 5, the Interface Builder is getting better and better at detecting merge conflicts. When a merge results in structurally valid XML but an invalid storyboard, Xcode will attempt to repair what it can: for example, if merging two versions results in an object connecting to an outlet that was removed, Xcode will notice it, and correct it.

Part of the problem, from a human perspective, is that dealing with merging two versions of a storyboard means working with XML, which is text; normally, working with storyboards is a visual task, but when there's a problem, you have to jump down to text and interpret what the XML actually means.

The XML used by storyboards, however, is actually pretty straightforward. Each view controller is an element that contains its subviews and other components (such as gesture recognizers or segues), and references to other objects are done with short alphanumeric strings. If there's a conflict, it's generally because two developers both inserted views into the same view controller - in which case, it's about as straight to recognize and fix as it is to fix a merge conflict in code.

Parting notes

Storyboards and XIBs are one of the most powerful and flexible tools that you get as part of the iOS developer tools, and shunning them means you lose both flexibility and features. If you're avoiding storyboards for personal reasons, we strongly recommend that you give them a try. If you're avoiding storyboards in your team because of the risk of merge conflicts, get some practice in fixing merge conflicts - they're easier than you think.

If you have any comments, email us!