Guard! Guard!

Swift 2 introduced the guard keyword, a handy bit of syntactic sugar with semantics similar to a debugging assert. It’s pure sugar, nothing more than an alternate if construction, but I’ve found that liberal use of guard has made my code far more readable with very little effort.

Basically, guard is a sort of inverse if. You could just as easily write the (hilariously contrived) above example as:

I strongly prefer the guard version, though, as I find the guard...else line to be much more explicit than the narrow and easily-overlooked !. guard really comes into its own, however, when dealing with optionals. I often find that I end up with a lot of code like:

This is fine, but it feels like inverted logic. I'd far rather take care of the error cases up front, and guard lets me do just that:

UIResponder and Swift 2.0

I was revisiting an older Swift 1.0 project this morning, and discovered that, in the upgrade to Swift 2.0, it had become hilariously uncompilable. The automatic converter worked, frankly, better than I expected, but I was still left with a couple of head-scratching errors. The most confusing was that my SpriteKit subclasses no longer seemed to override their parent UIResponder methods:

No, Xcode, I'm pretty sure it does.

No, Xcode, I’m pretty sure it does.

My touches* methods don’t seem to have the right signature anymore. Turns out, I’d implemented them all as:

Either Swift 1.1 was more relaxed when it came to matching method signatures or the signatures of these methods changed in iOS 9, because the solution turned out to be to change the method signatures to take a set of UITouch objects and an optional event, e.g.:

The App Classifieds

I’ve taken a break from app development to launch something different: a classified listings site for mobile, desktop, and web apps:

The App Classifieds Logomark

If you’re a hobbyist iOS developer with a few spare apps sitting in iTunes Connect (like me), then The App Classifieds can help you turn those apps into something useful by connecting you with like-minded app buyers. There are plenty of markets for apps, sure, but most of them are either borderline scammy, auction-only, or too expensive to make sense for smaller apps. The App Classifieds is a place to list apps that you’d be willing to sell but aren’t necessarily looking to auction right now — and listing an app is totally free. Promoted listings are also available, if you want to maximise the number of potential buyers who see your app — use the code SWIFTALICIOUS to get promoted listings for just $1.25/month (50% off of $5/month).

I wrote a little more about why we need a better way market for apps over at The App Classifieds blog; check it out for a better introduction. And if you’ve never sold an app or taken over someone else’s, I’d give it a shot. You’ll be surprised!

Swift 1.2, or The End of Egypt.

Swift 1.2 is out! Well, sorta-out — it’s bundled with the latest Xcode beta, and I’m still a little hesitant to jump on the beta Xcode train having been burnt one time too many. Plus, I’m not sure I like the idea of having my dev tools be ‘beta’, especially in the oh-wow-it-really-is-beta way that Apple uses the term.

If you want a highlight of changes in 1.2, jump over to NSHipster — but the most exciting change for me is a slight syntactic sugar around optional binding that turns the let-pyramid of doom:

into a sensible, manageable one-liner:

#pragma mark Equivalent in XCode 6

Remember #pragma mark? In Objective-C code it’s a lovely way to make your methods a little easier to find in the Xcode source navigator. While Swift doesn’t have Objective-C’s preprocessor support (and good riddance) I’ve come across a few magic comments that, if conservatively used, can make your code a lot more readable: MARK, TODO, and FIXME.

The effect of MARK, TODO, and FIXME in Xcode 6

The effect of MARK, TODO, and FIXME in Xcode 6

MARK

Use // MARK: Section Description to break your code up into logical sections. I use MARK breaks to (among other things) group together methods that implement a particular interface or share some related function (e.g. touchesBegan, touchesMoved, &c.). Start your section description (the bit after MARK: with a single dash to set the code off with a separator.

TODO

Use // TODO: Message to your future self! to indicate places in your code that still need work.

FIXME

As near as I can tell, FIXME works exactly like TODO. Take your pick, I guess — but try and stay consistent. I exclusively use TODO, but that’s just a personal preference.

Introducing alt.hack

For the last few months I’ve been working on a new game using SpriteKit and (of course) Swift. In a past life I used to be a game developer (tip o’ the hat to Blazing Griffin, the studio I co-founded back in 2011), and it’s been so great to get back into building games. Without further ado, let me introduce alt.hack, a hacking game for iOS and OS X loosely based on the hacking mechanic in Deus Ex: Human Revolution.

alt.hack, a hacking game coming to iOS

alt.hack, a hacking game coming to iOS

In alt.hack you play as an aspiring hacker, breaking your way through a series of increasingly well-defended networks. Every hack is a race against time as you capture your way across a network before security can trace you and kick you out. The game has a lengthy story mode, plus a fully-featured level designer (so fully-featured that I’ve used it to create every level in the game!) that lets you publish networks and see how other players fare against them.

I started Swiftalicio.us to document the things I was learning about Swift as I build alt.hack, and I’ll keep doing that as it moves closer to release. You might have noticed that a few of the more popular posts here (e.g. How to Setup a 2D Camera in SpriteKit) have a very game-specific focus — now you know why!

Using Cocoapods from Swift

If you’ve been writing iOS apps for any length of time chances are good you’ve come across CocoaPods, the community-developed dependency manager for Objective-C. You’d be hard-pressed to find a significant iOS library or control that’s not primarily distributed via CocoaPods, and even harder-pressed to find iOS developers who don’t swear by it.

Integrating CocoaPods-distributed libraries into Objective-C projects is dead easy; unfortunately, we have to do a little extra work to access those same libraries from Swift. To show you how, I’m going to add Jonas Gessner’s JGProgressHUD to an existing Swift app. For this example I’m going to start with an empty Swift iOS application from Xcode’s templates.

First step is to add a ‘Podfile’ to the project; this is a file where you’ll list all of the CocoaPods-provided dependencies and versions that you want to use. Create an empty text file called ‘Podfile’ in same directory as your app’s .xcodeproj and paste in the following:

Next step is to run the CocoaPods utility to actually download and unpack our requested pod. If you haven’t yet installed CocoaPods, now would be a good time to do that (the TL;DR version: sudo gem install cocoapods in your Terminal). Bring up a Terminal, change into the directory that contains the Podfile we just created, then run:

pod install

This should think for a bit, then print out something like the following:


Analyzing dependencies
Downloading dependencies
Installing JGProgressHUD (1.2.2)
Generating Pods project
Integrating client project

[!] From now on use Your-App.xcworkspace.

That last bit seems like good advice. Close your Xcode project, and open up the newly created .xcworkspace in its place. You should see two subprojects, one for your existing application plus a new one called, helpfully, ‘Pods’.

Pods. What a helpful name.

Open up the CocoaPods-created .xcworkspace instead of your previous .xcodeproj

At this point we can build and run the app, and we’ll technically be building an app with JGProgressHUD linked in. If we had any Objective-C code in the app we could now access our newly installed Pod from there, but if we want to do so from Swift we’ve got to set up two more things: a bridging header and custom header search paths.

A bridging header is just an Objective-C header file that exposes one or more Objective-C classes to the Swift compiler, making them accessible from our Swift code. Create a new Objective-C header in your app project, and call it ‘Bridging-Header.h’:

Call it 'Bridging-Header.h'.

Call it ‘Bridging-Header.h’.

Open up your newly bridging header and add in a single #import statement to bring in your JGProgressHUD headers:

To actually use this header we need to tell the Swift compiler where it is, so open up your project’s build settings and find the Swift Compiler — Code Generation section. Change the project-level setting for Objective-C Bridging Header and change the value to point to our new header (e.g. Cocoapods-Example/Bridging-Header.h for a project called ‘Cocoapods-Example’.).

Configuring a bridging header. Obviously.

Configuring a bridging header. Obviously.

One last thing while we’re mucking about with our build settings: we need to tell Xcode where to look for the header files we’re listing in our bridging header. Find the Search Paths section, and change the project-level setting for User Header Search Paths, adding a recursive entry for the ‘Pods’ directory.

Recursive Pods are the best kind of Pods.

We can now make use of our new, CocoaPod-provided progress indicator as if it was any other piece of Cocoa code. For example, we could show a dark, brooding spinner whenever our main view controller appears on the screen (ViewController.swift):

If you got stuck anywhere in this tutorial you can always download the example project from this tutorial. Finally, here’s our progress indicator running in the world’s least-exciting Swift app:

Possibly the least-exciting iOS application ever developed.

Possibly the least-exciting iOS application ever developed.