I was talking to two Objective-C iOS developers recently who told me that they were starting to learn Swift. This got me thinking: what did I wish I knew when I was learning Swift? Here are eight tips that are opinionated: they are not designed to help you learn Swift, but they might help you to work with the language instead of against it.

1. Avoid force unwrapping and force casting

I’ve written about this before – and it annoys me that Xcode sometimes recommends force unwrapping Optionals as a fix-it. Force unwrapping with ! and force casting with as! will bite you in the end – don’t do it. (Possible exception – objects from Storyboards and interface builder files, as their types are defined at runtime).

2. Prefer guard let over if let

You’ll learn that the classical way to unwrap an Optional is to use if let. The problem with if let is that it can cause pyramids of doom of closing braces in your functions. Consider this example:

if let processedString = funcThatReturnsAnOptionalString("parameter") {
    if let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") {
        if !processedString.isEmpty && !secondProcessedString.isEmpty {
            //do stuff
        }
    }
} // yuk

Solution: use guard let introduced in Swift 2:

guard let processedString = funcThatReturnsAnOptionalString("parameter") else {
    //you may want to perform error handling here
    return
}
guard let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") {
    //handle error if necessary
    return
}
if !processedString.isEmpty && !secondProcessedString.isEmpty {
    //do stuff
} //goodbye pyramid of doom

This gives you a fail early pattern and allows you to avoid unnecessary indentation.

3. Unwrap multiple things at once

You’ll run in to another problem once you start using guard let: you’ll find your functions compress horizontally (less indentation) but will expand vertically (more lines of code). Solution: unwrap multiple things at once. Consider the example above compared with:

guard let processedString = funcThatReturnsAnOptionalString("parameter"), let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") else {
    //handle error if necessary
    return
}
if !processedString.isEmpty && !secondProcessedString.isEmpty {
    //do stuff
}

Caveat: I find that if I’m unwrapping more than three things at once, it’s a code smell and I need to refactor. Also: it’s possible to combine guard let with traditional guard statements with conditional clauses: although I’m on the fence whether this is a good idea or impedes readability, I do find that it works as long as I restrict it to conditionals that answer the question “is this thing valid enough for me to work on?”. This would be achieved with the following (make your own mind up if this is taking things too far):

guard let processedString = funcThatReturnsAnOptionalString("parameter"), let secondProcessedString = funcThatReturnsAnOptionalString("another parameter"), !processedString.isEmpty, !secondProcessedString.isEmpty else {
    //handle error if necessary
    return
}
//do stuff

4. Understand that optionals may cause your app to fail differently

To be fair this is less of a problem for Objective-C developers, who are used to the paradigm “sending a message to nil is grand, at least if you’re expecting an object in return, because you’ll just get nil back”. But for developers coming from object-oriented languages such as C++, Java, C#, etc. it might be a bit of a surprise that you get far fewer crashes in Swift apps if you don’t force unwrap, because the language can eliminate a whole class of “null pointer exception” crashes if you use it correctly. This is not the same as eliminating bugs due to unexpected input! Instead of bug reports “the app crashes when I tried to do this”, you’ll start to get reports of “nothing happened when I tried to do this”. Prepare accordingly.

5. Use structs (when you can)

Although Swift supports object-oriented programming with classes, it brings a new more powerful paradigm: protocol oriented programming. This works best with the value types struct and enum and also gets you extra benefits: default initialisers, thread safety, and a way out of the sometimes baroque structures that class inheritance can encourage. But there’s a caveat: note that the two popular object persistence methods used in Swift (Core Data and Realm) use classes. And at the UI layer, UIKit on iOS and AppKit on macOS are all class-based. So your potential for using structs may actually be quite limiting (which can be a bit confusing because most introductions to Swift focus on structs, not classes, which leaves you with a mismatch between learning the language and using it). That said, do try and use structs where you can, especially in the intermediate layers between your view controllers and your model objects.

6. Enum all the things

That’s the title of a talk given by Dave Sims at the Limerick iOS Developer meetup that was so good he famously ended up giving the talk at other meetups in Ireland and the US. Enums are first-class (pardon the pun) value types in Swift that can have functions, properties, and most of the things that structs can have, as well as associated types. They are a tremendously powerful tool when writing swift apps.

7. Avoid AnyObject, and start to think about protocols and generics

Say you have two UITableViews in your app, which are mostly similar – you might be tempted to write one UITableViewController to avoid code duplication. What do you use as your datasource? One way might be to use an array of AnyObjects (AnyObject is a special type which means an instance of any class). Any time you’re relying on run-time type checking is a good prompt to think about protocol orientated programming. At its simplest, create a protocol and make your two types conform to it (they can even be blank). Add any common properties to allow the Swift compiler to check the validity of your code. Generics offer another powerful way of avoiding code duplication and increasing compile time safety. You can even create generic protocols using Protocols with Associated Types.

8. Add defaults to function parameters

Finally a quick one – if a function you’ve written almost solves your current problem, but needs an extra parameter, add it to the existing function with a default value instead of creating a new function. The default value will mean that existing calls to that function won’t break. I’ve often found that making the parameter an Optional type and setting its default value to nil allows an if let in the function body to neatly deal with the extra parameter.

Conclusion

Swift is still a young language, and best practices are by no means settled. To take an example from Erica Sadun’s excellent book Swift Style: An Opinionated Guide to an Opinionated Language, the Swift Standard library team prefer a space either side of a colon in declarations:

class userDetailViewController : UIViewController {

where the Apple developer docs team prefer left-hugging colons almost everywhere:

class userDetailViewController: UIViewController {

(for what it’s worth I prefer the second approach). I don’t even follow all the recommendations listed in this article all of the time in my own code. What’s important is that as you learn the language, you’re aware of working with the language and its opinions, rather than against it.

(tl;dr: force unwrapping in Swift with ! is bad)

At our last iOS Developer meetup in Limerick, my Worst Case Scenario podcast co-host Dave Sims gave an excellent talk on Optionals in Swift. I’m hoping that Dave will put the content online some day as he really managed to provide a simple yet powerful overview of what Optionals are. He also ended up being invited to give his talk to the CocoaHeads meetup in Indianapolis via Skype – check out Worst Case Scenario Episode 36 for the details about how that came about.

Dave mentioned in his talk that force unwrapping Optionals is generally a bad idea. Xcode doesn’t help the matter though by actually encouraging programmers to force-unwrap optionals:

This is terrible advice for programmers new (or not-so-new…) to Swift. Force unwrapping a nil optional will cause a runtime crash. The whole point of optionals is you make a whole class of bug, where a nil creeps in and causes havoc down the line, impossible. Force-unwrapping throws all of this away with the dubious upside of saving a line or two (and shutting up the compiler). You can argue that the Apple documentation is pretty clear about force unwrapping being a bad idea, but I feel the tools should be encouraging best behaviour. Dave mentioned three common unwrapping techniques:

1. if let
2. guard let
3. The ?? nil coalescing operator to provide a default value

Dave also mentioned Chris Lattner’s recent appearance on Accidental Tech Podcast where Swift’s creator talked about the purpose of the guard statement was to allow early exit (Overcast link that jumps directly to that segment), a style which he is personally in favour of. I also like this style – it reduces the indentation for the main bit of the code. You just have to remember to actually exit the block, either by asserting or returning a default value.

My fellow podcast hosts on Worst Case Scenario had both got smart home gear for Christmas. I was feeling a bit left out so I wanted to hack together a low-budget version. Here it is in action:

Now I can use Siri (or the iOS Home app) to turn on my Christmas lights from anywhere!

Ingredients:

• Raspberry Pi
• Relay shield from the gear we bought for the hackathon last year (it’s marked FE_SR1y)
• Christmas lights

The relay shield has a transistor and a diode built in, so I didn’t need to do any fandaglement with a circuit, just hooked up the + to 5v on the Pi, – to Ground, and the switching pin to one of the GPIO pins.

On the Pi, I installed the excellent Homebridge which allowed me to create a HomeKit accessory that Siri can talk to. I used the homebridge-gpio-wpi plugin to talk to the GPIO pins.

It’s obviously super fast on my home wifi network but it’s also surprisingly speedy going through the phone network: iPhone -> phone network -> Apple’s servers -> Apple TV -> Raspberry Pi -> lights takes about 1.3 seconds.

I am toying with the idea of creating a low-budget connected home using 433MHz RF remote controlled sockets which I could control from the Pi with a transmitter board. The other two lads on Worst Case Scenario are also expanding their systems based on the Amazon Echo – subscribe and keep up to date with how we’re getting on!

An interesting problem I had recently was to check to see if a string was valid word or not, comparing against a word list with over 170,000 entries.

Checking the string is easy, after loading the words into an NSArray, you can just call containsObject:

NSString *wordToFind = @“the”;
BOOL wordIsValid = [wordArray containsObject:wordToFind];

The code above takes 0.0310 seconds on my iPhone 5s.

It’s even faster with an NSSet:

NSString *wordToFind = @“the”;
BOOL wordIsValid = [wordSet containsObject:wordToFind];

Using an NSSet is over 300x faster than NSArray in this instance: 0.00001s!

Blankety blank

What if you wanted to search to see if the word was valid using blanks, like in Scrabble? NSPredicate makes this very easy:

NSString *wordToFind = @“th?”;
NSPredicate = [NSPredicate predicateWithFormat:@“SELF LIKE %@“,wordToFind];
NSArray *filteredArray = [wordArray filteredArrayUsingPredicate:predicate];

But then I looked at how long it took: 0.44 seconds. Ouch! It’s not acceptable to block the main thread for that long.  There’s a similar method for NSSet:

NSString *wordToFind = @“th?”;
NSPredicate = [NSPredicate predicateWithFormat:@“SELF LIKE %@“,wordToFind];
NSSet *filteredSet = [wordSet filteredSetUsingPredicate:predicate];

which took 0.47 seconds – even worse!

Benchmarking

At this point I decided to benchmark the results by running the test on 500 randomly selected words, where 5% of the letters were turned into blanks. Here’s a sample from my test word list of 500 words:

unclu?tered
succumbs
piggeries
pseu?opregnant
combat?ve

(I have no idea what ‘pseudopregnant’ means…).

Running the test with 500 different words and measuring the time it took to do each test enabled me to record the mean, minimum, maximum and standard deviation of each method. Unfortunately I had to run these tests on the iOS simulator – turns out there’s a subtle bug when repeatedly running an NSPredicate which causes a huge number of NSComparisonPredicate objects to be malloc’ed and not freed, causing the tests above to blow up due to memory pressure on my 5S.

Using the simulator, here’s the results of the test with filteredArrayUsingPredicate: and filteredSetUsingPredicate:

Method	Average	Min	Max	Standard Deviation
filteredArrayUsingPredicate:	0.15	0.12	0.34	0.03
filteredSetUsingPredicate:	0.16	0.14	0.54	0.03

Other in-memory methods

I then tried a litany of various methods on NSSet and NSArray to see if I could come up with something faster.

 Using blocks: indexOfObjectPassingTest

    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    NSUInteger index = [wordArray indexOfObjectPassingTest:^BOOL(id obj, NSUInteger idx, BOOL *stop) {
        return [predicate evaluateWithObject:obj];
    }];
    if(index != NSNotFound)
    {
//can return the found word using index
}

Prefiltering NSArray

This method pre-filters the word list by narrowing it down to only words which have the same first letter (unless we have a blank as the first letter) as the word we’re trying to match.

    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    
    NSString *firstLetter = [wordToCheck substringToIndex:1];
    NSArray *smallerArray;
    //prefiltering on first letter will only work if first letter is not blank
    if([firstLetter isEqualToString:@"?"])
    {
        smallerArray = wordArray;
    }
    else
    {
        NSPredicate *firstLetterPredicate = [NSPredicate predicateWithFormat:@"SELF BEGINSWITH %@",firstLetter];
        smallerArray = [wordArray filteredArrayUsingPredicate:firstLetterPredicate];
    }
    
    NSArray *filteredArray = [smallerArray filteredArrayUsingPredicate:predicate];
    if([filteredArray count] > 0)
    {
//return matched word here if needed
}

Prefiltering NSSet

    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    
    NSString *firstLetter = [wordToCheck substringToIndex:1];
    //prefiltering on first letter will only work if first letter is not blank
    NSSet *smallerSet;
    if([firstLetter isEqualToString:@"?"])
    {
        smallerSet = wordSet;
    }
    else
    {
        NSPredicate *firstLetterPredicate = [NSPredicate predicateWithFormat:@"SELF BEGINSWITH %@",firstLetter];
        smallerSet = [wordSet filteredSetUsingPredicate:firstLetterPredicate];
    }
    
    NSSet *filteredSet = [smallerSet filteredSetUsingPredicate:predicate];
    if([filteredSet count] > 0)
    {
//return matched word
}

Using a compound predicate on NSArray

What if we combined the above two methods into a compound predicate – where we check to see if the first letter is the same AND the word is like the word we’re searching for. This might result in a faster match as we can avoid using the expensive LIKE predicate if the first letters are not matching:

    NSPredicate *predicate;
    //if first letter is blank we have to fall back to using normal predicate
    if([firstLetter isEqualToString:@"?"])
    {
        predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    }
    else
    {
        predicate = [NSPredicate predicateWithFormat:@"SELF BEGINSWITH %@ AND SELF LIKE %@",firstLetter,wordToCheck];
    }
    
    
    NSArray *filteredArray = [wordArray filteredArrayUsingPredicate:predicate];
    if([filteredArray count] > 0)
    {
//retrieve matched word here
}

Using a compound predicate on NSSet

    NSString *firstLetter = [wordToCheck substringToIndex:1];
    NSPredicate *predicate;
    //if first letter is blank we have to fall back to using normal predicate
    if([firstLetter isEqualToString:@"?"])
    {
        predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    }
    else
    {
        predicate = [NSPredicate predicateWithFormat:@"SELF BEGINSWITH %@ AND SELF LIKE %@",firstLetter,wordToCheck];
    }
    
    NSSet *filteredSet = [wordSet filteredSetUsingPredicate:predicate];
    if([filteredSet count] > 0)
    {
//match word here
}

NSArray concurrent enumeration

NSArray also has a method:

- (void)enumerateObjectsWithOptions:(NSEnumerationOptions)opts 
                         usingBlock:(void (^)(ObjectType obj, NSUInteger idx, BOOL *stop))block;

which allows concurrent enumeration when you pass the NSEnumerationConcurrent option:

__block NSString *stringToReturn;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    [wordArray enumerateObjectsWithOptions:NSEnumerationConcurrent
                                usingBlock:^(id obj, NSUInteger idx, BOOL *stop)  {
                                    if([predicate evaluateWithObject:obj])
                                    {
                                        stringToReturn = obj;
                                        *stop = YES;
                                    }
                                }];
    if(stringToReturn)
    {
}

NSSet concurrent enumeration

NSSet offers an almost identical method, except there is no index parameter as NSSets are unordered:

    __block NSString *stringToReturn;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"SELF LIKE %@",wordToCheck];
    [wordSet enumerateObjectsWithOptions:NSEnumerationConcurrent
                                usingBlock:^(id obj, BOOL *stop)  {
                                    if([predicate evaluateWithObject:obj])
                                    {
                                        stringToReturn = obj;
                                        *stop = YES;
                                    }
                                }];
    if(stringToReturn)
    {
}

Results

Method	Average	Min	Max	Standard Deviation
indexOfObjectPassingTest	0.07	0.0001	0.31	0.04
Prefiltering NSArray	0.07	0.04	0.24	0.03
Prefiltering NSSet	0.08	0.05	0.41	0.03
NSArray compound predicate	0.09	0.06	0.33	0.03
NSSet compound predicate	0.10	0.08	0.26	0.03
NSArray concurrent enumeration	0.10	0.004	0.36	0.06
NSSet concurrent enumeration	0.10	0.01	0.31	0.06

We have managed to do a bit better with some of these methods, but we’re still nowhere near acceptable performance. Maybe Core Data might have some under-the-hood optimisations that might help us:

Core Data

I set up a simple Core Data stack, with one entity “Word” which had one attribute “word” (naming things is hard…). Here’s the method to retrieve a matching word in my data controller:

-(Word *)wordMatchingString:(NSString *)stringToMatch
{
    Word *wordToReturn;
    NSFetchRequest *request = [[NSFetchRequest alloc]init];
    //we want to retrieve all things
    NSEntityDescription *e = [[[persistenceController mom]entitiesByName]objectForKey:@"Word"];
    //set the entity description to the fetch request
    [request setEntity:e];
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"word LIKE %@",stringToMatch];
    [request setPredicate:predicate];
    //limit to one result
    [request setFetchLimit:1];
    
    NSError *error;
    //execute the fetch request and store it in an array
    NSArray *result = [[persistenceController mainContext] executeFetchRequest:request error:&error];
    //if not successful, throw an exception with the error
    if(!result)
    {
        [NSException raise:@"Fetch failed" format:@"Reason: %@",[error localizedDescription]];
    }
    
    //return the only object in the array
    wordToReturn = [result lastObject];
    return wordToReturn;
}

And here’s the method to match the word:

    Word *foundWord = [[WSDataController sharedController]wordMatchingString:wordToCheck];
    if(foundWord)
    {
}

The results for this were all over the place:

Method	Average	Min	Max	Standard Deviation
Core Data	0.10	0.001	0.76	0.06

I had high hopes for Core Data but it’s just not fast or consistent enough for this application.

Descent into SQLite

I was about to give up at this point. I asked Dave Sims if he had any advice and he suggested implementing a Directed Acyclic Word Graph (DAWG) which would be very efficient for finding matches – despite the opportunity to make “yo dawg” jokes I reckoned it might be a bit above my pay grade for some weekend pottering.

I’d read about some iOS developers preferring to deal directly with SQLite for their persistent storage, rather than using Core Data (which uses SQLite as one of its storage options). Relishing the opportunity to type in all caps, I followed a tutorial to get a basic SQLite setup going (the tutorial has a small error in, which XCode will catch with a warning, the solution is to replace the offending line with if (sqlite3_step(compiledStatement) == SQLITE_DONE) { ). Here’s my SQLite query:

    //SQLite uses underscores as the single character wildcard
    NSString *underscoreString = [wordToCheck stringByReplacingOccurrencesOfString:@"?" withString:@"_"];
    NSString *query = [NSString stringWithFormat:@"SELECT word FROM words WHERE word LIKE '%@'",underscoreString];
    NSArray *resultsArray = [[NSArray alloc] initWithArray:[self.dbManager loadDataFromDB:query]];
    if([resultsArray count]>0)
    {
}

This gave the following results:

Method	Average	Min	Max	Standard Deviation
SQLite	0.017	0.0014	0.056	0.004

Success!

Using SQLite not only resulted in faster matching, it was also much more reliable than any of the other methods, with a very small standard deviation. Obviously matching a string in an array of 170,000 strings is an edge case, and for most cases any of the other methods would have sufficed.

It’s also worth noting that I was able to run the Core Data and SQLite tests on my own iPhone 5S as they do not suffer the same NSPredicate memory leak as the other methods. Here are the results on the phone:

Method	Average	Min	Max	Standard Deviation
Core Data (iPhone 5S)	0.35	0.002	0.78	0.19
SQLite (iPhone 5S)	0.037	0.036	0.042	0.0006

Full results

Method	Average	Min	Max	Standard Deviation
filteredArrayUsingPredicate:	0.15	0.12	0.34	0.03
filteredSetUsingPredicate:	0.16	0.14	0.54	0.03
indexOfObjectPassingTest	0.07	0.0001	0.31	0.04
Prefiltering NSArray	0.07	0.04	0.24	0.03
Prefiltering NSSet	0.08	0.05	0.41	0.03
NSArray compound predicate	0.09	0.06	0.33	0.03
NSSet compound predicate	0.10	0.08	0.26	0.03
NSArray concurrent enumeration	0.10	0.004	0.36	0.06
NSSet concurrent enumeration	0.10	0.01	0.31	0.06
Core Data	0.10	0.001	0.76	0.06
SQLite	0.017	0.0014	0.056	0.004
Core Data (iPhone 5S)	0.35	0.002	0.78	0.19
SQLite (iPhone 5S)	0.037	0.036	0.042	0.0006