Size classes in Xcode 8

More devices, split view controllers (introduced in iOS 8), slide over and split view multitasking modes (introduced in iOS 9) have all made adjusting a layout to its environment more and more complex.


Interested to know about Size classes in Interface Builder in Xcode 8?

Check out my article on Medium here.


Tagged with: ,
Posted in Swift

Sprite Kit Easing in Swift

It really is surprising that SpriteKit, Apple’s framework for building 2D games doesn’t have better easing algorithms available.

I’ve just updated my solution, SpriteKitEasingSwift, to Swift 3, and added Carthage support. Here it is at github and CocoaPods.


Kudos to buddingmonkey who built the Objective-C library this framework was originally based on.


Tagged with:
Posted in Swift

Xcode Keyboard Shortcut for CamelCase!

Sometimes it can be a pain moving around code in Xcode especially with long method and property names. Then I discovered an Xcode keyboard shortcut that rocks – move back and forward through camel case sub-words!

Use Control and Control to skip through camel case. Hold down shift to highlight as you go:


You may be wondering why this isn’t working on your machine – this does take a tweak to achieve, as the Xcode shortcut is usually usurped by an OS keyboard shortcut preference to move through full screen windows.

If you can handle removing full screen keyboard shortcuts to go left and right (you can just as easily swipe four keys on the trackpad) then open System Preferences > Keyboard > Shortcuts and deactivate the ‘Move left a space’ and ‘Move right a space’ shortcuts:

Screenshot 2016-09-30 17.18.51.png

Alernatively, if you’re not keen on losing those shortcuts, you can always change the shortcut in Xcode – just look for Move Subword Back and MoveSubword Forward in Xcode Key Bindings Preferences.

Tagged with: ,
Posted in Swift

Why Swift?

With Swift 3 coming out of beta, some are still asking the question ‘Why Swift?’

Maybe you’re already an Objective-C developer – why learn a new language when the old one works fine?

Or maybe you’re learning iOS development and are facing the daunting question – should I learn Objective-C, the stalwart language that’s been around for many years, or Swift, the chic new up-and-coming language that keeps evolving!

I wrote an article recently on this question recently for medium – ‘Why Swift‘ – go check it out!

The article is actually an excerpt from my new book, iOS Development with Swift.



iOS Development with Swift is Deal of the Day for today, September 20! 

Half off iOS Development with Swift. Use code dotd092016au at


Posted in Swift

Any vs AnyObject vs NSObject in Swift 3

What is the difference between these three enigmatic types? A sometimes confusing topic, and to confuse things further Swift 3 has shaken it up by removing implicit bridging between Foundation and native data types. Aagh!

Let’s look at the current situation with a good old Venn diagram:


Let’s take a closer look at distinguishing these types with an example using arrays.

You probably know Swift is a type-safe language. For this reason, the compiler won’t permit you to type infer an array of different types that don’t share a common root:

//Error: Type of expression is ambiguous without more context
var test = ["a",0]

Strings and Ints in Swift don’t share a common root, so the compiler doesn’t know what you want it to do when type inferring the array.

There are three tricks for removing this error:

Solution 1: Array of NSObjects

If you import UIKit and cast the string as an NSString and the Int as an NSNumber the error goes away. Why?

import UIKit
//No error, test inferred to be [NSObject]
var test =  ["a" as NSString,0 as NSNumber]

UIKit Framework includes the Foundation framework. If you have imported the Foundation framework you can explicitly bridge common Swift data types to their Foundation Objective-C counterparts. (this bridging was automatic pre-Swift 3) String for example, bridges to NSString and Int can bridge to NSNumber.
Unlike in Swift, in Objective-C, most data types do have a root: NSObject is an actual class (docs here), that is the root of most classes if you’re using the Foundation framework.

If you option-click on the test variable, you’ll find that it has defaulted to [NSObject].

But then – out of curiosity – what happens if you add another variable to the array that does not have NSObject as a root, such as a class of your own?

class Test {}
var test = [Test(),"a" as NSString,0 as NSNumber]

The compiler can no longer find a root class to infer the array’s data type. You would need a way to indicate to the compiler that you know that the elements of the array are incompatible, and you’re ok with that.

Solution 2: NSArray

One solution would be to type the array as Foundation data type NSArray. NSArray is less strict than its Swift countertype; NSArray doesn’t enforce that elements it contains are the same data type.

//No error: test defined as NSArray
var test:NSArray =  [Test(), "a",0]

Solution 3: [Any] or [AnyObject]

If you specifically define the array as [Any], you are indicating to the compiler that you are aware that the elements are not of the same data type, and you are ok with that.

class Test {}
//No error, test is defined as [Any]
var test:[Any] = [Test(),"a",0]

You may be surprised to learn that unlike NSObject, Any is not actually a concrete data type. You won’t find a type description for it in documentation. Rather Any is an alias for any data type.

Similarly, AnyObject is an alias for any data type derived from a class. You can use it to define an array that contains more than one object derived from a class, that don’t share a common root class:

class Test {}
class Test2 {}
//No error, test is defined as [AnyObject]
var test:[AnyObject] = [Test(),Test2()]

(You could of course have used [Any] as well – [AnyObject] is just a little more specific.

Passing in a string and an integer for example, to an AnyObject array will cause an error, as these data types are structs in Swift.

//Error: String does not conform to element type 'AnyObject'
var test:[AnyObject] = ["a",0]

Of course, an Array which could contain any data type is unlikely to pop up in your code, and if it does, maybe you should double-check you’re following best practices!
Rather, this has been an exercise to explore Any, AnyObject, NSObject, NSArray and how Swift 3 now requires explicit bridging between Foundation and native data types. Hopefully this helps!

Tagged with: ,
Posted in Swift

Parsing XML in Swift 3

Parsing XML has always bothered me in Swift. The NSXMLParser class doesn’t actually parse the XML structure into Swift objects, rather it traverses the XML structure, pinging its delegate whenever it discovers something new, like an XML element or attribute, and then leaves it up to you to make something of it.

There are several solutions out there for parsing XML to Swift objects, such as AEXML or SwiftyXML, but nothing seemed to do exactly what I was after, or had problems in Swift 3.

I decided to write my own XML Parser, and I’ve called it SwiftXML. Check it out here!


Tagged with:
Posted in Swift

Sorting strings in Swift

Sorting an array of strings in Swift is a bit of an iceberg topic – it seems fairly manageable, you just call the sort function right? Then you dig a little deeper and find a whole lot more lurking under the surface!

Let’s start with the example in Apple’s Swift Programming Language guide:

(Apple sorts the data in reverse order, for simplicity I’ve swapped it)

let names = ["Chris", "Alex", "Ewa", "Barry", "Daniella"]
let sortedNames = names.sorted(by: { $0 < $1 } )
// Prints "["Alex", "Barry", "Chris", "Daniella", "Ewa"]"

Great, but what happens if “Alex” starts with a lower case letter? Alex gets shunted to the end of the list – probably not what you’re after!
“Barry”, “Chris”, “Daniella”, “Ewa”, “alex”

To ignore case, compare the lower case versions of the names:

let sortedNames = names.sorted(by: {
    $0.lowercased() < $1.lowercased() } )

The rules for ordering strings can vary for different languages and locales. From Apple’s iOS String Programming Guide:

Important: For user-visible sorted lists, you should always use localized comparisons.

Fortunately, strings have another property called localizedLowercase.

let lowercaseSortedNames = names.sorted(by: {
    $0.localizedLowercase &lt; $1.localizedLowercase } )

Now let’s add some complexity to this problem. Let’s say we have a Person class, that contains a first name and a last name, and an array of people:

struct Person {
    var firstName: String
    var lastName: String
let people = [
    Person(firstName: "Kylie", lastName: "Minogue"),
    Person(firstName: "Dannie", lastName: "Minogue"),
    Person(firstName: "Paul", lastName: "Kelly"),
    Person(firstName: "Ned", lastName: "Kelly")

Sorting them by last name is easy enough, just be sure to include the lastName property:

let sortedPeople = people.sorted(by: {
    $0.lastName.localizedLowercase < $1.lastName.localizedLowercase } )

Screenshot 2016-08-05 12.57.30

Obviously the first names need to be compared as well. You can achieve this by putting the two comparisons into a tuple:

let sortedPeople = people.sorted(by: {
    ($0.lastName.localizedLowercase,$0.firstName.localizedLowercase) <
} )

Screenshot 2016-08-05 13.02.11

Tagged with:
Posted in Swift