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)

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"]

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.


I just finished the majority of the development for Triglotta 2 which will be released on Reformation Day. This means it's time to start the next side project. For the umpteenth time I'm going back to working on a quiz game. I've gone back and forth so many times about the pros and cons of educational games and the pros and cons of the types of games within that subgenre. I'm finally just going to try to build one and learn from the experience. This project will be a rewrite and reimagining of the Table Talk Radio app with new games and a simpler format to allow for more frequent content updates. I may not be able to include as many soundbites, but I will try to keep them as best as I can as that was a major feature, at least in my mind.

Multiple Learning Paths

As with all my side projects, one of my goals is to learn and improve various development skills. My major focuses will be on really understanding Swift, improving my use of Xcode, and learning about the new UI Test feature.

Blogging the Process

The other major component of this side project is my plan to blog about the progress or lack there of. My plan is to write lightly filtered thoughts about my thoughts, what's working, what's not, what I'm learning, what I need to learn, where I'm falling short, what's hard, and really what ever comes to mind that I can look at later and see where my processes worked and where I can improve.

I don't know if this will be useful for me or anyone else, but I want to take the time to examine what I'm doing instead of just plowing ahead without some introspection.

I hope to build a full-time business making tech products that confess, teach, and defend the Faith once delivered to the saints. With that in mind, I have been building a couple of apps and trying to figure out what to charge for them so that I can progress toward this goal. And now those apps have stagnated. One is mostly in a good state, but it doesn't have the features I would make money from and has been stagnant for a couple of months. The other app is about ready to be user tested, but it's been in that state for about a month. Both have stagnated for the same reason: fear.

Root of Multiple Fears

There are multiple fears in play hear. Fear of not being good enough, offending people, failure, etc. Most of these fears would be alleviated if I weren't planning on charging for the apps. I think there is value in the work I've done, but I'm not sure how much or if anyone else will perceive that value and if a person makes a purchase will my work meet or exceed the value that was paid for?

I'm missing out on several things at this point. I'm not learning anything about pricing or running a profitable business, and I'm also not learning about what is valuable to people and how to ship a great product. The thing I'm considering is not charging for the apps and giving people value for free. The Lord has blessed me with a wonderful job and I don't need to make money from my apps at this point. The value for me of learning from shipping, building a reputation, and learning about what people are interested in is good enough for me right now. My hope is that these experiences will guide me into the time when I can feel comfortable in switching things into a business.

What's Next

My plan is to focus on cleaning up the apps and getting them into shape based on not charging for them. I'll take the summer to do testing and actually try to do some experimental marketing in hopes of a Reformation Day release.

I started my latest project which is a simple game with a high difficulty level (think Flappy Bird) where gameplay can be extended by answering increasingly difficult questions. It might be chocolate covered broccoli, but I'm here to learn.

I'm writing the game in Swift (as a learning exercise as well) and ran into something interesting. I had run across the common wisdom to default to using Structs over Classes. I followed this advice without completely understanding it. I knew that Structs were passed by value but with their ability to include functions they were mostly like Classes.

Until They Aren't Alike

I was happily using Structs everywhere until I needed an Array as a property. I added and initialized the Array property just fine, but when I tried to assign a value to the Array I got the cryptic message: "Cannot assign to the result of this expression." Looked like a valid Array assignment to me. I went and created a Playground to test the Array syntax and there was nothing wrong with that. So I did some Googling and eventually ran across this note about Structs: "The structure’s primary purpose is to encapsulate a few relatively simple data values." Something in my mind told me that Arrays weren't simple data values. I changed the declaration from Struct to Class and the Array assignment worked as I expected.

This is the pragmatic way I learn. I pickup generally accepted patterns and practices for the tools and languages I'm using and use them without complete understanding. Some would see this as problematic because I'm moving forward without complete knowledge of what I'm working with. I argue that complete knowledge of the tools, while desirable, is impractical. Using the commonly accepted wisdom to solve known problems frees me to add value by working on the solution or application I'm writing. I also have the confidence that when I run into problems while using the tools I can figure out and increase my understanding of them as I need to do so.

Do I Have a Right? is the best example I've run across of game-base learning. It uses elements of resource management games like Diner Dash, but instead of giving patrons the correct food, you must direct them to the proper lawyer who can address their constitutional problem. For example, an NPC may come in saying that she was told she can't vote because she is not of drinking age, but is 20 years old. You would need to direct her to a lawyer who knows the 26th Amendment. Similarly, you might get a buy who comes in complaining that nobody will pay him to be an actor. You would need to let him know that you can't help him since there is no constitutional guarantee that you be paid to be an actor.

I can imagine a version of this that might be used to teach various aspects of Christianity. An NPC might come in with a question about Jacob and the player would need to direct the NPC to an Old Testament scholar, or an NPC might come with a question about Baptism and being buried with Christ and would need to be directed to a Pauline scholar.

If you know of any other games that impart knowledge as a core part of the game, drop me a line on twitter @byamabe.

Wouldn't it be great if learning was fun and engaging? We have a better chance of learning subjects we are interested in, but even then, learning a foreign language we've always dreamed of speaking can become boring and arduous if presented poorly.


One way to make the learning process fun is to add game mechanics around the subject matter. This is known as gamification. Some examples would be adding a point system to learning vocabulary words, giving badges for being the first to mix a set of chemicals and get a specific reaction, and having levels for the amount physical activity you do in a day. In gamification the activities themselves aren't any more inherently engaging, it is the process layer around them that keeps people interested.

Game-Based Learning (Educational Games)

Another way to make learning fun is to make learning an integral part of the game play. This is called an educational game or more fashionably game-based learning. Examples of game-based learning would be flashcards which drill a skill, the game Civilization used to teach about history and technological progress, and flight simulators to teach about aerodynamics and control systems.

Good and Bad

Both gamification and game-based learning can point to successes, failures, and cases of being oversold. In a previous dive into this field, Civilization was always held out as a model for game-based learning. There was talk of students taking deep dives into history and cultures because of exposure to the game. I've played at least 3 versions of the game and have yet to learn much more than some of the famous rulers in various civilizations. Maybe in the context of a good curriculum Civilization and other games can be used to spark curiosity. Other "kill and drill" games were routinely criticized and rightly to some extent, but I could see how you might actually learn some of the subject matter before you were bored to death or turned off by the subject.

Fun and Engaging Self-Directed Learning

What I'm attempting to do is create a game-based learning app where learning is part of the game play. I'm sure my early attempts will be little better than "kill and drill" or "chocolate-covered broccoli" games, but I hope to keep at it and find a formula for self-directed learning that is fun and engaging.