The simple Swift shoot ’em up: updated for Xcode 6.0 and now on GitHub!

swift kickA couple of quick updates about the simple “shoot ’em up” game tutorial app written in Swift with Sprite Kit that I posted a little while back:


Xcode 6.1 beta 3 and iOS 8.1 beta are out!

do you feel lucky geek

For those of you who like living on the edge, beta 3 of Xcode 6.1 (the current stable version is 6.0) is now available to registered iOS developers. Of note in this release:

  • More APIs have been made optional-conformant. The good news is that code will make more sense. The bad news is that some existing code may break.
  • Value of type Any can now contain function-type values, as you might come to expect from a value named Any.
  • Documentation for the standard library, which shows up in quick help and in the synthesized header for the Swift module, is improved.
  • All the *LiteralConvertible protocols now use initializers for their requirements rather than static methods starting with convertFrom. Any type that previously conformed to one of these protocols will need to replace its convertFromXXX static methods with the corresponding initializer.
  • Xcode now produces fixit hints to move code from the old-style fromRaw()/toRaw() enum APIs to the new style-initializer and rawValue property.
  • Class properties don’t need to be marked final to avoid O(n) mutations on value semantic types.
  • iOS Playgrounds now support displaying animated views with the XCPShowView() XCPlayground API. This is disabled by default, but can be enabled by checking the Run in Full Simulator checkbox in the Playground Settings inspector. When this checkbox is checked, running the playground will cause the iOS Simulator application to launch and run the playground in the full simulator. This is also required for some other functionality that fails without the full iOS Simulator, such as NSURLConnection http requests. Running in the full iOS Simulator is slower than running in the default mode.
  • Apple has addressed an issue that could cause Xcode to become unresponsive while editing Swift code.
  • Dead code stripping no longer removes public declarations from Swift application targets which are needed by unit testing.
  • Weakly-linked symbols no longer cause compilation errors in Playgrounds .
  • Swift expressions like expr, p, and print that are evaluated from the LLDB prompt in the Debugger console will now work on 32-bit iOS devices.
  • Profiling App Extensions with Instruments now works.
  • Ampersand and double quotation mark characters are now fully supported in the company name for iOS projects you create.

Also available for download is iOS 8.1 beta. As with Xcode 6.1 beta, you have to be a registered Apple developer to get it now.

Remember, these are betas, and the standard caveats apply.

I’ll close with the Dirty Harry clip referenced in the photo at the top of this article, for the benefit of younger readers who may not be familiar with Mr. Clint Eastwood’s iconic character:


Mobile carrier news roundup: Verizon gets top marks, US wireless market trends, AT&T’s double data deal, and get your unlocked iPhone 6 at T-Mobile

RootMetrics gives Verizon top marks for its wireless network

rootmetrics on us carriers

Investment site The Motley Fool points to RootMetrics’ report for mobile carrier performance for the first half of 2014, which shows Verizon as the best overall performer of the “Big Four”. RootMetrics’ methodology incorporates thousands of mobile network performance tests performed on voice, text, and data from the consumer’s point of view. In the most recent round of these tests, Verizon performed best in reliability, speed, voice call performance, and data performance. AT&T beat them out in text message performance.

rootmetrics tests 1

rootmetrics tests 2

rootmetrics test 3

Click on any of these test graphs to see the RootMetrics report.

The Motley Fool credits Verizon’s XLTE — their branding for their Advanced Wireless Service (AWS) spectrum — which allows them to offer more than double the bandwidth provided by 4G LTE to customers, and this often yields faster connection speeds. Verizon has made XLTE available to 80% of its wireless market and 35% of devices currently on their network, and nearly all the devices it sells are XLTE-compatible.

total us carrier subscribers

Graph from Jan Dawson’s US wireless market trends for 2014 slide deck.
Click to see the source.

Verizon added 1.4 million net new wireless subscriptions in Q2 2014, and most of them — nearly 1.2 million — were tablet subscribers, not phone subscribers. Tablet mobile plan subscriptions are typically secondary subscriptions (with the primary one being for a mobile phone), and this, coupled with the fact that they’re one of the top 2 carriers in the US, suggests that their focus is on retaining customers and keeping their churn rate down. They seem to be succeeding in this goal, considering that they’ve kept their churn to under 1% for postpaid subscribers in Q2 2014.

Worth reading: Jan Dawson’s US wireless market trends for 2014 slide deck

The last graph in the segment above comes from US wireless market trends for 2014, a slide deck created by Jackdaw Research’s chief analyst, Jan Dawson. The deck looks at the wireless market’s financials (revenues, profitability, capital intensity), subscribers (total subscriptions, net adds, churn), and device trends (subsidies and penetration). If you want a good overview of the market, this is a good place to start.

AT&T offers double the data for family plans

att double data chart
att jpgFrom now until October 31, a family currently on AT&T’s Mobile Share Value plan can apply to get double the data on their plan for the same price. The deal doesn’t expire once you’ve signed up for it, but you do have to sign up for it, as it’s not automatically offered, and you have to do so before Hallowe’en.

Want an unlocked iPhone 6? T-Mobile’s got ’em!

t-mobileIf you’ve got the money to buy it outright from the get-go, T-Mobile can help you; they’re the only US carrier who sells unlocked, contract-free iPhone 6. If you take this route, you’ll have to pay off any installment balance remaining on it and use the T-Mobile network for 40 days, which is the usual policy for T-Mobile. Once those 40 days have passed, you can switch to the network of your choice.

this article also appears in the GSG blog


“The Flappening” (or: my fixed version of “Flappy Bird” in Swift)

For a while, FlappySwift — an implementation of Flappy Bird put together by the folks at as part of a Swift development course — was the go-to GitHub repo for understanding both Swift and Sprite Kit. Then, Xcode 6 beta 7 happened and…

xcode beta 7 broke everything

At the beginning of the beta period, many of Apple’s APIs returned values as implicitly unwrapped optionals, which I suspect was a quick and dirty way to get a large number of APIs Swift-compatible. As the beta period went on, they started changing the APIs for optional conformance, which means that:

  • If an API call was going to return a value that might be nil, it would do so as an optional, and
  • if an API call would never return a nil value, it would do so as a non-optional.

A lot of the APIs were updated for optional conformance in Xcode 6 beta 7, including Sprite Kit, which means that suddenly a lot of Swift game code broke. Any code that expected to be using PhysicsBody! objects was suddenly dealing with PhysicsBody? objects and therefore wouldn’t run thanks to a crop of PhysicsBody? does not have a member named [SomeMember] errors.

I explained how to fix this problem in an article titled Why your Swift apps broke in Xcode 6 beta 7 and the GM versions, and how to fix them, but I thought I’d do one better.

I decided to fork the FlappySwift repo, make the necessary fixes, and post the resulting working new version on GitHub.

Now there’s a Swift version of Flappy Swift that will compile under the Xcode 6 GM and the optional-conformant APIs. Enjoy!


Mobile device roundup: BlackBerry Passport’s American-cheese-sized screen, “Bendghazi”, no Edge for you, and the FBI’s concerns about phone encryption

BlackBerry Passport’s big screen

blackberry passport american cheese

The Canadian BlackBerry Passport meets American cheese…and dirty fingernails.

Nothing conveys the size of the BlackBerry Passport’s screen as well as this photo from Charlie Wells’ recent tweet:



The current kerfuffle in mobile technology goes by the name “Bendgate” (or my favorite, “Bendghazi”), in which a number of users have reported that their brand-new iPhone 6 Plus devices would have a tendency to warp and bend while in their pockets.

I’ll leave it to tech videographer extraordinaire Marcus Brownlee to explain it in detail:

In response, the Apple PR machine has given tours of their iPhone torture-testing facilities:

In a story on The Verge, Josh Lowensohn reports that 30,000 iPhone 6 units — 15,000 of the 4.7″ iPhone 6 and 15,000 of the 5.5″ iPhone 6 Plus — underwent testing at Apple’s labs, where he saw phone undergoing all manner of stresses that they might undergo in regular (and some not-so-regular) everyday use. Apple report that they’ve received a mere 9 complaints.

Whether or not your bent iPhone 6 is your fault, chances are that if you take your bent iPhone 6 to the Genius Bar at your local Apple Store, they just might replace it, given their mandate and training to provide maximum customer satisfaction.

No Galaxy Note Edge for you!

samsung galaxy note edge
Remember Samsung’s Galaxy Note Edge, which we wrote about in our article covering the IFA trade show? It turns out that despite all the promotion, it’s a concept device.

galaxy edge edge

The phablet, which boasted a screen that curved around its right edge, with the curve acting as a second screen that could be viewed from its side, is a limited edition device whose primary purpose is simply to, as PC World puts it, “scream ‘First!'”. According to them, there will be limited sales in South Korea next month, and only way you’ll have a chance of getting one in the U.S. is either by being very lucky or knowing someone high up in Samsung US.

FBI director “very concerned” about new Apple and Google smartphone privacy features

fbi director james comey

In response to announcements from Apple and Google about enabling encryption on their mobile operating systems that would keep out both thieves and law enforcement, FBI director James Comey expressed his concern:

“I like and believe very much that we should have to obtain a warrant from an independent judge to be able to take the content of anyone’s closet or their smart phone. The notion that someone would market a closet that could never be opened — even if it involves a case involving a child kidnapper and a court order — to me does not make any sense.”

The Verge provides some valuable perspective in their article on the subject in these two paragraphs, which we’ll close with:

If this fight sounds familiar, it’s because much of the 90s was spent on exactly this legal question, a fight that’s now known as the Crypto Wars. PGP founder Phil Zimmermann almost went to jail over it. Of course, because it was the 90s, the fight was over desktop hard drives rather than phones, but when the dust settled, the courts ruled it was completely legal and large, reputable companies like Microsoft and Apple started offering full-disk encryption services without anyone making a fuss about it. Julian Sanchez has a great rundown of how it happened and why it was a good decision, but the general punchline is that it’s hard to build a backdoor that can only be used by the good guys.

It should also be pointed out that Comey’s refreshing enthusiasm for warrants is not shared across all federal agencies. Surveillance of this type frequently happens under a much lower legal standard, whether it’s a subpoena, a National Security Letter or plain old FISC-approved bulk collection. In fact, programs like that are the biggest reason Apple implemented this encryption in the first place, trying to placate concerns over unauthorized government data collection. Unfortunately for Comey, just invoking kidnapped children isn’t enough to undo 20 years of legal precedent.


Why your Swift apps broke in Xcode 6 beta 7 and the GM versions, and how to fix them

xcode beta 7 broke everything

If you had Swift projects that worked perfectly fine under Xcode 6 beta 6, you might find that they no longer work under beta 7 or the GM versions. This article will show you how to fix them, and why they broke.

For example, the FlappySwift game on GitHub — “Flappy Bird”, implemented in Swift — worked fine in Xcode 6 beta 6 and earlier, but is rife with errors in the present version of Xcode:

flappyswift code screencap

Click the screen capture to see it at full size.

Most of the errors are of the form “[SomeClass]? does not have a member named [SomeMember]”. The fix is simple — use optional chaining to fix the problem. For example, code like this:

pipeDown.physicsBody = SKPhysicsBody(rectangleOfSize: pipeDown.size)
pipeDown.physicsBody.dynamic = false
pipeDown.physicsBody.categoryBitMask = pipeCategory
pipeDown.physicsBody.contactTestBitMask = birdCategory

should be changed to:

pipeDown.physicsBody = SKPhysicsBody(rectangleOfSize: pipeDown.size)
pipeDown.physicsBody?.dynamic = false
pipeDown.physicsBody?.categoryBitMask = pipeCategory
pipeDown.physicsBody?.contactTestBitMask = birdCategory

Note the addition of a ? — the optional chaining operator — to physicsBody when accessing one of its members. Make changes like this to FlappySwift’s code (it won’t take longer than a couple of minutes), and it’ll work again.

What happened?

It’s not as if Apple didn’t tell you what happened. It’s all spelled out in the Xcode 6 beta 7’s release notes:

A large number of Foundation, UIKit, CoreData, SceneKit, SpriteKit, Metal APIs have been audited for optional conformance, removing a significant number of implicitly unwrapped optionals from their interfaces. This clarifies the nullability of their properties, arguments and return values of their methods. This is an ongoing effort that started shipping in beta 5. These changes replace T! with either T? or T depending on whether the value can be null or not null, respectively.

It’s perfectly understandable if you read that and this was your reaction:

beavis and butt-head wtf

We’ll translate this into plain language, but first, let’s do a quick review of non-optional, optional, and implicitly unwrapped optional variables.

Non-optionals, optionals, and implicitly unwrapped optionals: a quick review

optional 1 In Swift, a variable whose type that doesn’t have any punctuation is guaranteed to contain a value of that type. For example, a variable of type String is guaranteed to contain a string value, even if that string is a zero-length string (“”). It will never be nil (nil means that the variable doesn’t contain a value), and you can start performing string operations on its value immediately.

Of course, there are times when you want a variable that might not contain a value at the moment, to indicate that you haven’t yet recorded a value or to denote that there’s no connection to another object. That’s what optionals are for: optional 2 Variables in Swift whose type ends with a question mark — ? — are called optionals, and they’ll either contain a value of that type or nil (which means that it contains no value). You’ll need to perform a check to see if contains a value or is empty first, and you’ll need to unwrap it before you can use its value.

For example, a variable of type String? will contain either a string value or nil. An often-cited example for showing optionals in action starts with a Dictionary with String keys and values, like the one below:

let airports = [
  "YYZ" : "Toronto Pearson",
  "YUL" : "Montreal Pierre Elliott Trudeau",
  "TPA" : "Tampa",
  "SFO" : "San Francisco",
  "ORD" : "Chicago O'Hare"

This dictionary lets you look up the name of an airport given its three-letter code like so:

let airportName = airports[airportCode]

You might think that the type of airports[airportCode] is String, but it’s not — it’s String?. That’s because the value of airports[airportCode] will be either:

  • a String value, if the value for airportCode corresponds to one of the dictionary’s keys: YYZ, YUL, TPA, SFO, or ORD, or
  • nil, if the value for airportCode isn’t one of the dictionary’s keys, such as LAX.

With optionals, you’ll write code that first checks to see whether or not they contain a value, and if they do, unwrap them with the ! operator. Here’s an example that continues with our dictionary:

if airports[airportCode] != nil {
  // We CAN'T do string operations on airports[airportCode] since
  // not a string, but an optional. We have to unwrap it first
  // with the ! operator.
  let airportName = airports[airportCode]!

  // We CAN do string operations with airportName, since it IS a string.
  let phrase = "The airport's name is: " + airportName
else {
  println("Airport name unknown.")

This sort of check is going to happen quite often, so Swift’s designers added the “iflet” shorthand to save reduce the amount of code you have to write:

// If airports[airportCode] isn't nil, assign its value to airportName,
// which is a string.
if let airportName = airports[airportCode] {
  let phrase = "The airport's name is: " + airportName
else {
  println("Airport name unknown.")

You can also unwrap an optional by assigning its value to an implicitly unwrapped optional:

optional 3 Variables in Swift whose type ends with an exclamation mark — ! — are called implicitly unwrapped optionals, and they’re optionals you don’t have to unwrap in order to access the value they hold. When you want to work with the contents of an optional, you can either use the ! operator to unwrap it, or you can assign its value to an implicitly unwrapped optional, like so:

var tampaAirport: String! = airports["TPA"]

in which case tampaAirport is a String! variable. It’s still an optional, but you can use it as if it were a regular string variable. It’s still an optional, and it can be nil. There’s a coding convention that promises that by the time you need to access an implicitly unwrapped optional’s contents, it’ll hold a value.

This “it may have been nil at one point, but I promise it’ll contain a value by the time you use it” property of implicitly unwrapped optionals make them useful for instance variables whose values can’t be set when they’re declared. For example, suppose we need variables to store the width and height of the screen — values that we can’t know in advance:

class ViewController: UIViewController {

  // We want instance variables to hold the screen's width and height,
  // but we won't know what values to set them to until the app is running.
  // So we'll declare them as implicitly unwrapped optionals.
  var screenWidth: CGFloat!
  var screenHeight: CGFloat!
  override func viewDidLoad() {

    // NOW we can fill those screen width and height variables!
    let screenSize = UIScreen.mainScreen().bounds
    screenWidth = screenSize.width
    screenHeight = screenSize.height

  // (the rest of the class goes here)

That’s the review. Now let’s look at why your code broke.

Why your code broke after Xcode 6 beta 7 and later

This long answer on Stack Overflow explains implicitly unwrapped optionals exist. Long story short, they’re a practical compromise that allows Swift, which purposely doesn’t have null pointers, to work with iOS’ existing APIs, which were written with Objective-C, its pointers, and its conventions in mind.

There were a number of iOS APIs that were returning values as implicitly unwrapped optionals because they’re as close as you get to pointers in Swift: they can either hold a reference or nil, and you can access them directly without unwrapping them. Over time, Apple have been updating these APIs so that they followed the rules for optionals — if they might return nil, return the value as an optional, otherwise, return the value as a non-optional. Hence the term “optional conformance”. With the release of Xcode 6 beta 7, and after that, Xcode 6 GM, most of the APIs now conform to the rules for optionals. If an API call returns a value that could be nil, it’s no longer returned as an implicitly unwrapped optional, but as an optional. Here’s a snippet of code from my “Simple Shoot ‘Em Up” game that worked in Xcode 6 versions prior to beta 7. It assigns physics bodies to missile sprites:

// Give the missile sprite a physics body.
// This won't work on Xcode 6 beta 7 or GM!
missile.physicsBody = SKPhysicsBody(circleOfRadius: missile.size.width / 2)
missile.physicsBody.dynamic = true
missile.physicsBody.categoryBitMask = missileCategory
missile.physicsBody.contactTestBitMask  = alienCategory
missile.physicsBody.collisionBitMask = 0
missile.physicsBody.usesPreciseCollisionDetection = true

It used to work when the SKPhysicsBody(circleOfRadius) initializer returned an object of type SKPhysicsBody!, which granted access to its properties. As of Xcode 6 beta 7 and later, SKPhysicsBody(circleOfRadius) returns an object of type SKPhysicsBody?. You need to unwrap it to get at its properties, which you can do through optional chaining, as shown below:

// Give the missile sprite a physics body.
// This won't work on Xcode 6 beta 7 or GM!
missile.physicsBody = SKPhysicsBody(circleOfRadius: missile.size.width / 2)
missile.physicsBody?.dynamic = true
missile.physicsBody?.categoryBitMask = missileCategory
missile.physicsBody?.contactTestBitMask  = alienCategory
missile.physicsBody?.collisionBitMask = 0
missile.physicsBody?.usesPreciseCollisionDetection = true

My suggested general guideline is that if you’re dealing with an API call or property that returns a pointer, you’re dealing with an optional that you’ll need to unwrap. You can always check the type of an entity in Xcode by putting your cursor over it and alt-clicking:

returning a pointer


I think the new sysadmin might be a little strict…

cat o nine cat-5 tails

Photo via AcidCow. Click to see the source.

…if the cat o’ nine cat-5 tails is any indication.