In Java there is the idea of [100% Pure Java}](http://www.javacoffeebreak.com/faq/faq0006.html). Put simply it is the idea that your code contains no OS native calls. This idea came from the desire to have completely portable programs. As Swift migrates to different platforms I wonder if we will see this desire come to it. I assume this would be useful for server apps built with Swift. Also, it depends on the language itself. Does Swift and its standard library lend themselves to writing platform agnostic code. If the facilities to write server apps aren't built into Swift and the standard library (like I/O or concurrency or whatever) then people will have to write and link in platform specific code which ends that dream.

I'm guessing that the easiest work is done in that there are Mac OS and Linux implementations of Swift which I assume means that 100% Pure Swift is possible on *nix based systems. I'm not sure how well the language plays with Windows since Apple hasn't provided a Windows port.

There is rumor that Google is considering making Swift a "first class" language for Android. I don't know what "first class" would mean in the context of Android, but I would assume that it means that Swift could be used in the standard Android tool chain in the same way that Java is now. I could see how this could be a big deal and how it might not be.

For the change to happen, all the Android API's would need to be exposed as Swift API's and then the Swift source code would need to be compiled to Android bytecode. This seems rather trivial for the big brains at Google. So I don't really see this as any kind of technical challenge. But how do you introduce and migrate this into the developer's tool chain when 60% of your userbase uses an OS version more than 2 years old. So if developers aren't likely to switch to your new tools, why develop them and what is the calculus for how likely and how many switchers are needed to make the switch make sense?

Moving to Swift might cause me to re-evaluate development for Android. The main reason I don't is that I do Java at work and have no desire to see more of that style of coding. However, Swift for Android isn't likely to make development easier as Cocoa Touch and the other frameworks that make up the substantive parts of app development aren't part of the open source project. I'd get to use the language, which is one level of expertise, but the libraries would be completely foreign and incompatible.

What IBM does in the technology field has little bearing on me anymore. They are in the business of consulting and services to very large enterprises and my interests lie largely on the opposite end of the spectrum. So it is a little bit of cherry picking when I mention their adoption of Swift on their servers and cloud services as a positive sign for Swift. A more balanced view would that it's interesting that IBM is putting some wood behind their Swift efforts.

IBM does have an enterprise deal with Apple and if Apple is moving toward Swift why wouldn't they. Swift being open source gives IBM more reason to put it on their servers and cloud. IBM already develops their own JVM which I assume they have to license and pay money to Oracle to do and since Oracle is a competitor why would they want to keep doing that especially for a technology that has seen its heyday. If they can build new platforms and applications using an existing partners technology that they don't have to license it makes sense for them to go in this direction.

So while IBM supporting Swift isn't a big deal for me, it does improve the likely hood of Swift's long-term viability which is interesting.

Proving once again that I have a difficult time sticking with a side project I'm going to focus my attention on a flash card app. I'm not abandoning the quiz app. The simple question and answer infrastructure as well as the ideas for fill in the blank, matching, and ordering questions will find their place in future projects whether specifically a quiz app? I'm not sure.

The reason for a flash card app is a renewed interest in memorizing Luther's Small Catechism brought on by the work at Lutheran Catechism. I figure I can help myself and help others by building this app.

Additionally, I'm going to do a better job of blogging about the development of the app. I would like to see a bigger ecosystem of Lutheran apps and I hope that blogging about it will inspire someone to learn and create their own or push someone to say, "heck I can do that" and build something better.

Non-Standard to Standard

It's probably too early to worry about the look of the app, but I want the header to look like the Brainscape iOS app above. My initial attempt, after throwing out the default UIViewController, was to take a create a view that contained a navigation bar and a table view. With these in place I set out to make the status bar and navigation bar both dark and translucent so they would look like one unit and have the effect of allowing items to scroll underneath them.

After about 45 minutes of digging through StackOverflow and using trial and error. I chucked this attempt to roll my own. I dragged out a navigation controller and got what I was looking for. I hadn't thought that this default would give me the control or look I wanted but looks like it is good, at least for now.

When starting a new project in Xcode the first decision you make is the type of application you are going to create. Master-Detail, Page-Based, Single View, Tabbed? My vision for the app is close to Master-Detail but doesn't fit exactly so I decided on the Single View Application figuring that I would throw out the default UIViewController.

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.