When I first started iOS development (think it was iPhone OS development) Interface Builder (IB) was pretty clunky and since I was used to creating Java Swing applications, it was no big deal to create the UI in code. It was also simple because there was only one screen size so you could hardcode coordinates and sizes with impunity. As IB has become more robust and has incorporated Auto Layout I do most UI layout in IB.

Now with this mixing of SpriteKit and UIKit I needed to once again place elements programmatically. The things is that SpriteKit and UIKit have their own coordinate system orientations (which I knew) and their own coordinate bounds as well (which I didn’t know). In my initial UIViewController I was centering a UIButton based on half the view’s width. And in my SpriteKit SKScene I was setting a UITextView based on half the view’s width. However, in the UIViewController the UIButton was centered as expected, but the UITextView would never line up right.

After playing with various iPhone Simulator hardware and experimenting with the code, I found that the SKScene bounding box was always 1024x768 and that the bounding box of the UIViewController was the device screen size (e.g. 1136x640 on an iPhone 5s). To get things to work as I expected, I had to get the SKScene as a UIView and then the bounds would be the device bounds. I could now manipulated UIViews in my SKScene but I would have to be aware of the specific device size.

This didn’t seem like a great path to follow. Apple’s whole trajectory is to move away from coding to specific device sizes. I vaguely remembered overhearing that there was a way to do Auto Layout programmatically. After a Google search or two I found some Swift examples of programatic Auto Layout. I was able to put together this code to get the effect I wanted in a non-device specific way:

let viewDictionary = ["textView": textView]
let textViewConstraintV = NSLayoutConstraint.constraintsWithVisualFormat("V:|-2 0-[textView(100)]", options: NSLayoutFormatOptions(rawValue: 0), metrics: nil, views: viewDictionary)
let textViewConstraintH = NSLayoutConstraint.constraintsWithVisualFormat("H:|-50-[textView]-50-|", options: NSLayoutFormatOptions(rawValue: 0), metrics: nil, views: viewDictionary)
view.addConstraints(textViewConstraintV)
view.addConstraints(textViewConstraintH)

I chose to use the “Visual Format Language” in this case. I’m not sure if I’ll stick with this or move to the object-based way of creating constraints. Either way, I’m glad I learned a couple of things even though I found a better way to accomplish the desired effect.

I knew I would eventually run into a decision regarding how to write something based on whether or not it was testable, and I’m actually not that surprised that it came early in the project. Xcode UI Testing leverages iOS’s accessibility functionality. That works great for standard UI elements, but Table Talk Quiz is SpriteKit based, and while most of the UI elements will be text labels or fields and buttons I imagined using SpriteKit to do the animations and any special effects.

Sticking with SpriteKit

My first decision was that I’m going to stick with SpriteKit. I want the option to use the effects and animations that SpriteKit provides. I can see using them for “win” and “loss” fanfare and background effects. The problem is that SpriteKit nodes aren’t testable (at least I didn’t find a way) so I wouldn’t be able to use BDD. Of course I already had a test for the start button which is an instance of UIButton which is testable. The mixing of UIKit classes and SpriteKit classes is fully supported, but I found that I have to do a little more management of the UI elements. Also, there will be a mix of UIAnimation and SpriteKit animation code which was what I was hoping to avoid, but software development is always about compromise and in this case I will sacrifice the cleanliness of a single animation type for the ability to continue my attempt at BDD.

I’ve written an app is Swift, but I couldn’t claim to be much more than an advanced beginner. The question is though, “how much Swift do I need to understand to write good apps?” Secondarily, “how much Swift do I need to understand to get a job as a Swift developer?” These sound similar, but they are definitely two different things.

A Good App

I made a decent app (Triglotta 2) with my advanced beginner skills. It’s pretty basic and although there is some complex text processing a deep knowledge of Swift wasn’t needed. That being said, there is probably code that is not very idiomatic and considering the code base started from Swift 1.0, I’m sure there are unwrapped variables and control flows that look wrong if not problematic.

To make a good app, meaning robust, flexible, and extensible will take a deeper understanding of Swift. Table Talk Quiz should push me a great deal in that direction. My vision is to have the quiz portion be the foundation for multiple apps going forward and to be that foundation I want the code to be good. So to make a good app I have some idea about where I need to increase my skills.

A Swift Job

Now to get a job as a Swift developer, that’s another story. If you look at something like these swift interview questions there are concepts that, while technically useful, aren’t great predictors of whether someone who would be good at developing apps for your team. This makes me recall the Java interviewers that always asked about double checked locking and pass by value vs pass by reference. I’ve seen a bunch of production code that has the double checked locking problem, but in practice I’ve never seen an error caused by it. I’ve also never seen a problem arise because of pass by value vs pass by reference confusion. Nobody I know tries to write code that complicated or tricky.

Where does that leave my thinking with Swift? I’m not sure how much I’m going to need to use functions and closures as arguments. I probably should know that they can. What about mapping and filtering? How deeply should I understand them? Once again, I’m not sure how much the type of apps I’m going to write will need them. Will that mean I couldn’t find a job as a Swift developer? I think it will depend on what the company and the role values. If they want someone who has a solid grasp of the fundamentals and can ship software then I think I can get to that point. If they want someone who has an intimate knowledge of the language and how to get the most out of it, I doubt I will get to that point. The types of apps that I conceptualize don’t require that depth of language knowledge and I need to make the decision to prioritize an understanding of Swift that will help me ship apps as opposed to understand the language.

As part of the process of building Table Talk Quiz, I want to try to adhere to BDD. What that means for me in practical terms is that I want to write application code only after I have a test that is failing. The failing test may need a functioning piece of code to pass, but it might also need a piece of UI. For example, the first thing Table Talk Quiz will need is a start button to start the game, and I want have a test that verifies that the start button exists.

Xcode UI Testing

In Xcode 7 UI Testing is natively supported. Previous to this version of Xcode you had to use an external tool like Frank or Kiwi. I tried these and other and while a diehard BDD practitioner might wrestle with them to build a project, the lack of integration into Xcode made sticking to them too much of a hassle. But now Xcode supports a UI Testing target with APIs for testing and driving your app. Yay, sort of. The first thing you will notice is that there is no documentation. There are the headers and someone has run the doc scripts on them and posted them, but there are no official guide or API documentation. Apple’s support of testing is like its support of gaming; it throws little bones, but never gives you all the tools to make you feel like a first class citizen.

From watching the WWDC UI Testing video I wrote this as my first test:

func testStartButtonExists() {
    let app = XCUIApplication()
    let startButton = app.buttons["start"]
    XCTAssertTrue(startButton.exists)
}

I have a failing test, yay! Now on to making that test pass.

Xcode Project Template Looks like Table Talk Quiz is a going to be a game.

Xcode Project Options That uses Swift and SpriteKit and includes unit and UI tests.

A new project is similar to a blank canvas or page for other creative people. It’s the place where the actual work of creating happens. It can be exciting and overwhelming at the same time. The possibility of greatness, failure, or mediocrity. The endless possibilities of what could be created.

Sometimes I actual talk and think the way I wrote the previous paragraph. I’ve exposed myself to various books and movies that have caused that type of writing and speaking to creep into who I am. It can sound lofty and fake even to me, but it comes out at times and that’s just who I am. I’m not a good enough writer or communicator to stick to one coherent style so I just have this jumbled mess. One of the reasons I fail at blogging is that I see this mix of styles, try to clean it up, and then just kill the whole thing because I’ve lost focus on the subject matter because of stylistic mattters.

The Deal

I’ve tried to write iOS quiz games at least 5 times. I have the projects sitting on my drive in various stages of incompletion. I even shipped one (Table Talk Radio) about 5 years ago, but I never iterated on it and I consider it incomplete. After building some momentum with the development of Triglotta 2, I think I found a rhythm that I can sustain and get me to final make the quiz game that I can ship and maintain.

What’s the game going to be like? Do I have a design? How am I going to make money from it? These are all questions that I’d like to answer, but 1) I don’t have all the questions answered and 2) I’m going to use the technique I used to sustain my work on Triglotta 2 and apply it to blogging which is to say I’m going to do a little every day. So I’m not going to attempt to answer all the questions in this post. As I hash various aspects of the project out I will post my thoughts and internal debates.

Pax