Get started with iOS in Swift today

Grummitt-iOS-HIAre you thinking about getting into iOS in Swift, and are looking for an all-in-one guide?

I have just the book for you.

iOS Development with Swift brings you into the world of developing iOS apps, using Apple’s Swift programming language. No prior experience with Swift required, as we explore what’s new and exciting about this language in a lightning tour.

After covering some basics of iOS, we will build up an app from idea through to publishing our app on the App Store. On the way we’ll look at solving common iOS problems, laying out your app interface in code or using a storyboard, structuring your code in iOS, working with data on the device and in iCloud, best practices and what to do when things don’t go to plan.

Start learning iOS today! Look for your 42% off discount code below:

Tagged with:
Posted in Swift

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

My book: iOS Development with Swift – Early access Deal of the Day!

I’m pleased to announce that I am half way through writing a book on iOS development with Swift, to be published by Manning Publications.

The great news if you have experience in programming is that this book skips over all the basics, and skips straight to the juicy bits – such as “What’s new and different in Swift?” After introductory material, the book will take you through the process of building a sophisticated app in iOS from concept through to beta testing and the App Store.

Extra special news is that it is Deal of the Day for today (July 28) and early access is available for half-price.

Use code dotd072816au at

Posted in Swift

Keyboards, text views and first responders

If you’re moving your app’s interface from under the keyboard when it appears, you’re probably doing the following:
1. Get a reference to the relevant text field in the UITextFieldDelegate‘s textFieldDidBeginEditing method.
2. Listen to a relevant keyboard notification (possibly UIKeyboardWillShow or UIKeyboardWillHide but probably the best to use is UIKeyboardWillChangeFrame, as this covers all your bases). Get the size of the keyboard from the userInfo property and move the textField up out of the way.

Great, this works because when the user taps on a text field, the events occur in this order:
1. textFieldDidBeginEditing
2. UIKeyboardWillChangeFrame

But then when you happen to implement a text view you’ll discover that the events occur in the opposite order:
1. UIKeyboardWillChangeFrame
2. textViewDidBeginEditing

Whaaa? Well, that messes up the steps we were following – when we get the UIKeyboardWillChangeFrame notification, we don’t yet have a reference to the relevant text view to move it!

How to solve this? Here are three approaches:
1. Use UIKeyboardDidChangeFrame (Did, not Will) instead, to be sure we get it in the right order. Problem – we can no longer animate interface changes simultaneously with the keyboard, rather animations will happen in sequence.
2. Store the keyboard size in a property in the UIKeyboardWillHide selector. Call a method (let’s call it moveInterface() ) after both steps that will move the interface out of the way. The moveInterface() method will only work when it has references to both the keyboard size, and the relevant text field / text view.
3. Here’s another option, thinking outside the box:

The reason why we need to get a reference to the text field/view in the …didBeginEditing method, is that Apple hasn’t given us a simple way to get a reference to the current field/view being edited (also known as the firstResponder). However, Apple has given us an isFirstResponder() method that will tell you if a view is currently the fist responder. Great! We can use that method to recursively iterative through a view’s subviews and determine the current first responder.

If we know the first responder, we don’t need the …didBeginEditing methods at all, and can skip straight to dealing with moving the interface when we receive the UIKeyboardWillChangeFrame notification.

Here’s a UIView extension to add a computed property that returns the first responder from a view’s subviews:

import UIKit
extension UIView {
    var firstResponder:UIView? {
        if self.isFirstResponder() {
            return self
        for view in self.subviews {
            if let firstResponder = view.firstResponder {
                return firstResponder
        return nil

And here’s a UIViewController extension to get the scene’s first responder:

extension UIViewController {
    var firstResponder:UIView? {
        return view.firstResponder
Tagged with: , , , ,
Posted in Swift