“We should do (as wise programmers aware of our limitations) our utmost best to … make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.”

—Edsger W. Dijkstra, “Go To Considered Harmful”

Recently, Swift 2.0 introduced two new control statements that aim to simplify and streamline the programs we write: guard and defer. While the first by its nature makes our code more linear, the other defers execution of its contents. How should we approach these new control statements? How can guard and defer help us clarify the correspondence between the program and the process?

Let’s defer defer and first take on guard.

guard

If the multiple optional bindings syntax introduced in Swift 1.2 heralded a renovation of the pyramid of doom, guard statements tear it down altogether.

guard is a new conditional statement that requires execution to exit the current block if the condition isn’t met. Any new optional bindings created in a guard statement’s condition are available for the rest of the function or block, and the mandatory else must exit the current scope, by using return to leave a function, continue or break within a loop, or a @noreturn function like fatalError():

forimageNameinimageNamesList{guardletimage=UIImage(named:imageName)else{continue}// do something with image}

Let’s take a before-and-after look at how guard can improve our code and help prevent errors. As an example, we’ll build a new string-to-UInt8 initializer. UInt8 already declares a failable initializer that takes a String, but if the conversion fails we don’t learn the reason—was the format invalid or was the value out of bounds for the numeric type? Our new initializer throws a ConversionError that provides more information.

enumConversionError:ErrorType{caseInvalidFormat,OutOfBounds,Unknown}extensionUInt8{init(fromStringstring:String)throws{// check the string's formatiflet_=string.rangeOfString("^\\d+$",options:[.RegularExpressionSearch]){// make sure the value is in boundsifstring.compare("\(UInt8.max)",options:[.NumericSearch])!=NSComparisonResult.OrderedAscending{throwConversionError.OutOfBounds}// do the built-in conversionifletvalue=UInt8(string){self.init(value)}else{throwConversionError.Unknown}}throwConversionError.InvalidFormat}}

Note how far apart the format check and the invalid format throw are in this example. Not ideal. Moreover, the actual initialization happens two levels deep, inside a nested if statement. And if that isn’t enough, there’s a bug in the logic of this initializer that isn’t immediately apparent. Can you spot the flaw? What’s really going to bake your noodle later on is, would you still have noticed it if I hadn’t said anything?

Next, let’s take a look at how using guard transforms this initializer:

extensionUInt8{init(fromStringstring:String)throws{// check the string's formatguardlet_=string.rangeOfString("^\\d+$",options:[.RegularExpressionSearch])else{throwConversionError.InvalidFormat}// make sure the value is in boundsguardstring.compare("\(UInt8.max)",options:[.NumericSearch])!=NSComparisonResult.OrderedDescendingelse{throwConversionError.OutOfBounds}// do the built-in conversionguardletvalue=UInt(string)else{throwConversionError.Unknown}self.init(value)}}

Much better. Each error case is handled as soon as it has been checked, so we can follow the flow of execution straight down the left-hand side.

Even more importantly, using guard prevents the logic flaw in our first attempt: that final throw is called every time because it isn’t enclosed in an else statement. With guard, the compiler forces us to break scope inside the else-block, guaranteeing the execution of that particular throw only at the right times.

Also note that the middle guard statement isn’t strictly necessary. Since it doesn’t unwrap an optional value, an if statement would work perfectly well. Using guard in this case simply provides an extra layer of safety—the compiler ensures that you leave the initializer if the test fails, leaving no way to accidentally comment out the throw or introduce another error that would lose part of the initializer’s logic.

defer

Between guard and the new throw statement for error handling, Swift 2.0 certainly seems to be encouraging a style of early return (an NSHipster favorite) rather than nested if statements. Returning early poses a distinct challenge, however, when resources that have been initialized (and may still be in use) must be cleaned up before returning.

The new defer keyword provides a safe and easy way to handle this challenge by declaring a block that will be executed only when execution leaves the current scope. Consider this snippet of a function working with vImage from the Accelerate framework, taken from the newly-updated article on image resizing:

funcresizeImage(url:NSURL)->UIImage?{// ...letdataSize:Int=...letdestData=UnsafeMutablePointer<UInt8>.alloc(dataSize)vardestBuffer=vImage_Buffer(data:destData,...)// scale the image from sourceBuffer to destBuffervarerror=vImageScale_ARGB8888(&sourceBuffer,&destBuffer,...)guarderror==kvImageNoErrorelse{destData.dealloc(dataSize)// 1returnnil}// create a CGImage from the destBufferguardletdestCGImage=vImageCreateCGImageFromBuffer(&destBuffer,&format,...)else{destData.dealloc(dataSize)// 2returnnil}destData.dealloc(dataSize)// 3// ...}

Here an UnsafeMutablePointer<UInt8> is allocated for the destination data early on, but we need to remember to deallocate at both failure points and once we no longer need the pointer.

Error prone? Yes. Frustratingly repetitive? Check.

A defer statement removes any chance of forgetting to clean up after ourselves while also simplifying our code. Even though the defer block comes immediately after the call to alloc(), its execution is delayed until the end of the current scope:

funcresizeImage(url:NSURL)->UIImage?{// ...letdataSize:Int=...letdestData=UnsafeMutablePointer<UInt8>.alloc(dataSize)defer{destData.dealloc(dataSize)}vardestBuffer=vImage_Buffer(data:destData,...)// scale the image from sourceBuffer to destBuffervarerror=vImageScale_ARGB8888(&sourceBuffer,&destBuffer,...)guarderror==kvImageNoErrorelse{returnnil}// create a CGImage from the destBufferguardletdestCGImage=vImageCreateCGImageFromBuffer(&destBuffer,&format,...)else{returnnil}// ...}

Thanks to defer, destData will be properly deallocated no matter which exit point is used to return from the function.

Safe and clean. Swift at its best.

defer blocks are executed in the reverse order of their appearance. This reverse order is a vital detail, ensuring everything that was in scope when a deferred block was created will still be in scope when the block is executed.

(Any Other) Defer Considered Harmful

As handy as the defer statement is, be aware of how its capabilities can lead to confusing, untraceable code. It may be tempting to use defer in cases where a function needs to return a value that should also be modified, as in this typical implementation of the postfix ++ operator:

postfixfunc++(inoutx:Int)->Int{letcurrent=xx+=1returncurrent}

In this case, defer offers a clever alternative. Why create a temporary variable when we can just defer the increment?

postfixfunc++(inoutx:Int)->Int{defer{x+=1}returnx}

Clever indeed, yet this inversion of the function’s flow harms readability. Using defer to explicitly alter a program’s flow, rather than to clean up allocated resources, will lead to a twisted and tangled execution process.

“As wise programmers aware of our limitations,” we must weigh the benefits of each language feature against its costs. A new statement like guard leads to a more linear, more readable program; apply it as widely as possible. Likewise, defer solves a significant challenge but forces us to keep track of its declaration as it scrolls out of sight; reserve it for its minimum intended purpose to guard against confusion and obscurity.

With 2015 behind us and the new year begun, it’s time again for an NSHipster tradition: reader submissions! As inyear’spast, this installment is chock full of tips and tricks that can help ease your days working with Xcode, Swift, and Objective-C.

Many thanks to Cédric Luthi, Josip Ćavar, Juraj Hilje, Kyle Van Essen, Luo Jie, Mathew Huusko V, Nicolás Jakubowski, Nolan O’Brien, Orta Therox, Ray Fix, Stephen Celis, Taylor Franklin, Ursu Dan, Matthew Flint, @biggercoffee, and @vlat456 for their contributions!

Swift’s defer in Objective-C

From Nolan O’Brien:

With the excellent addition of defer to Swift we Objective-C holdouts can’t help but feel envious of the improvements happening so rapidly to the Swift language. Until Apple officially adds @defer devs can actually implement defer support simply enough with a macro in Objective-C. Below I’ve outlined how one can go about doing a defer today in Objective-C. Personally, having Apple add @defer seem like an easy win for Objective-C, but we’ll see what happens. :)

Nolan’s macro uses the GCC (cleanup()) attribute to execute a block when scope exits:

// some helper declarations#define _nob_macro_concat(a, b) a##b
    #define nob_macro_concat(a, b) _nob_macro_concat(a, b)
    typedefvoid(^nob_defer_block_t)();NS_INLINEvoidnob_deferFunc(__strongnob_defer_block_t*blockRef){nob_defer_block_tactualBlock=*blockRef;actualBlock();}// the core macro#define nob_defer(deferBlock) \
    __strong nob_defer_block_t nob_macro_concat(__nob_stack_defer_block_, __LINE__) __attribute__((cleanup(nob_deferFunc), unused)) = deferBlock
    

Blocks used with nob_defer are executed in reverse order, just like Swift defer statements:

#include <nob_defer.h>
    -(void)dealWithFile{FILE*file=fopen(…);nob_defer(^{if(file){fclose(file);}});// continue code where any scope exit will// lead to the defer being executed}-(void)dealWithError{__blockNSError*scopeError=nil;nob_defer(^{if(scopeError){[selfperformCustomErrorHandling:scopeError];}});// assign any errors to "scopeError" to handle the error// on exit, no matter how you exit}#define NOBDeferRelease(cfTypeRef) nob_defer(^{ if (cfTypeRef) { CFRelease(cfTypeRef); } })
    -(void)cleanUpCFTypeRef{CFStringRefstringRef=...somecodetocreateaCFStringRef...;NOBDeferRelease(stringRef);// continue working without having to worry// about the CFTypeRef needing to be released}

I’ve been using my custom defer macro in production code since June and it is really the Bee’s Knees!

Swift Protocol Extensions

From Juraj Hilje:

Keep inheritance trees shallow and use protocol composition:

protocolHello{funcsayHello()->String}extensionHello{funcsayHello()->String{return"Hello, stranger"}}classMyClass:Hello{}letc=MyClass()c.sayHello()// "Hello, stranger"

Public Read-only Variables

From Stephen Celis:

Classes commonly have public, read-only properties but need the ability privately modify them. I’ve come across the following pattern a few times:

publicclassPerson{publicvarname:String{return_name}privatevar_name:String// ...}

Luckily, there’s a better, oft-overlooked way that avoids the extra variable:

publicclassPerson{publicprivate(set)varname:String// ...}

Swift where Everywhere

From Taylor Franklin:

The addition of the where clause has made my code simple and compact while remaining readable. In addition, it has a broad application in Swift, so that it can be applied in nearly any kind of control-flow statement, such as for loop, while loop, if, guard, switch, and even in extension declarations. One simple way I like to use it is in my prepareForSegue method:

ifletsegueID=segue.identifierwheresegueID=="mySegue"{...}

The combo of unwrapping and performing a condition check is most commonly where I use the where clause. The where clause is not going to change your life, but it should be an easy and useful addition to your Swift skills.

Improved Optional Binding

From Ursu Dan:

The improved optional binding in Swift is amazing and I use it virtually everywhere now and avoid the pyramid of doom:

ifleturl=NSBundle.mainBundle().URLForResource("users",withExtension:"json"),data=NSData(contentsOfURL:url),deserialized=try?NSJSONSerialization.JSONObjectWithData(data,options:[]),userList=deserializedas?[[String:AnyObject]]{foruserDictinuserList{ifletid=userDict["id"]as?Int,name=userDict["name"]as?String,username=userDict["username"]as?String,email=userDict["email"]as?String,phone=userDict["phone"]as?String,address=userDict["address"]as?[String:AnyObject]{users.append(User(id:id,name:name,...))}}}

Unbuffered xcodebuild Output

From Cédric Luthi:

Using xcpretty because the output of xcodebuild test is unreadable? Unfortunately, the output of the test results becomes buffered when piped. Solution: set the NSUnbufferedIO environment variable for a smooth experience. 😎

env NSUnbufferedIO=YES xcodebuild [flags] | xcpretty
    

Multiline Labels in a Table View

From Ray Fix:

Using autolayout to toggle a label in a table view from one line to many:

tableView.beginUpdates()label.numberOfLines=label.numberOfLines==0?1:0tableView.endUpdates()

You can see Ray’s technique in action in an example project:

AmIRunningAsAnExtension

Another from Nolan O’Brien:

With extensions in iOS, it is critical that frameworks that can be linked to both extensions and apps be cognizant of their uses so they don’t call any APIs that might not be available to an extension (like UIApplication). Here’s a function to help determine if you are running in an extension at runtime:

(Per Apple, an extension will have a top level “NSExtension” dictionary in the info.plist.)

letNOBAmIRunningAsAnExtension:Bool={letextensionDictionary:AnyObject?=NSBundle.mainBundle().infoDictionary?["NSExtension"]returnextensionDictionary?.isKindOfClass(NSDictionary.self)??false}()

FOUNDATION_EXTERNBOOLAmIRunningAsAnExtension()__attribute__((const));BOOLNOBAmIRunningAsAnExtension(){staticBOOLsIsExtension;staticdispatch_once_tsOnceToken;dispatch_once(&sOnceToken,^{NSDictionary*extensionDictionary=[[NSBundlemainBundle]infoDictionary][@"NSExtension"];sIsExtension=[extensionDictionaryisKindOfClass:[NSDictionaryclass]];});returnsIsExtension;}

That frees you to do things like this:

-(void)startBackgroundTask{#if TARGET_OS_IPHONE
    if(!NOBAmIRunningAsAnExtension()){ClassUIApplicationClass=NSClassFromString(@"UIApplication");idsharedApplication=[UIApplicationClasssharedApplication];self.backgroundTaskIdentifier=[sharedApplicationbeginBackgroundTaskWithExpirationHandler:^{if(self.backgroundTaskIdentifier!=UIBackgroundTaskInvalid){[sharedApplicationendBackgroundTask:self.backgroundTaskIdentifier];self.backgroundTaskIdentifier=UIBackgroundTaskInvalid;}}];}#endif
    }-(void)endBackgroundTask{#if TARGET_OS_IPHONE
    if(self.backgroundTaskIdentifier!=UIBackgroundTaskInvalid){NSAssert(!NOBAmIRunningAsAnExtension());ClassUIApplicationClass=NSClassFromString(@"UIApplication");idsharedApplication=[UIApplicationClasssharedApplication];[sharedApplicationendBackgroundTask:self.backgroundTaskIdentifier];self.backgroundTaskIdentifier=UIBackgroundTaskInvalid;}#endif
    }

Beyond Breakpoints

From Matthew Flint:

This has been my year of truly appreciating Xcode breakpoints, beyond the standard “break at this line” type. It breaks my heart to see other developers not using them to their potential.

Right click on a breakpoint and choose Edit Breakpoint… for access to advanced features:

Particularly the ones with actions (such as logging to the console) that continue automatically without pausing any threads, because you can add/edit them without recompiling. I’ll never accidentally commit NSLogs again. :)

Fix Console po frame Printing

GitHub user @biggercoffee reminds us that po frame printing fails in the LLDB console by default:

Fix it mid-debugging session with expr @import UIKit, or fix it once and for all by adding a couple lines to your “.lldbinit”. From the command line:

touch ~/.lldbinit
    echo display @import UIKit >> ~/.lldbinit
    echo target stop-hook add -o\"target stop-hook disable\">> ~/.lldbinit
    

Avoiding -DDEBUG in Swift

From GitHub user @vlat456:

For those, who like me, are trying to avoid the mess with -DDEBUG in Swift, but have to know which version of executable is running, Debug or Release.

// PreProcessorMacros.m:#include "PreProcessorMacros.h"
    #ifdef DEBUG
    BOOLconstDEBUG_BUILD=YES;#else
    BOOLconstDEBUG_BUILD=NO;#endif
    // PreProcessorMacros.h:#ifndef PreProcessorMacros_h
    #define PreProcessorMacros_h
    #include
    externBOOLconstDEBUG_BUILD;#endif /* PreProcessorMacros_h */// in Bridged header:#import "PreProcessorMacros.h"

And then from Swift:

ifDEBUG_BUILD{debugPrint("It's Debug build")}else{debugPrint("It's Release build")}

Checking For Null Blocks

From Nicolás Jakubowski:

This macro for checking block nullability before executing them:

#define BLOCK_EXEC(block, ...) if (block) { block(__VA_ARGS__); };
    

Old and busted:

if(completionBlock){completionBlock(arg1,arg2);}

New and shiny:

BLOCK_EXEC(completionBlock,arg1,arg2);

Swiftier GCD

From Luo Jie:

You can use enums and protocol extensions to provide a GCD convenience API:

protocolExcutableQueue{varqueue:dispatch_queue_t{get}}extensionExcutableQueue{funcexecute(closure:()->Void){dispatch_async(queue,closure)}}enumQueue:ExcutableQueue{caseMaincaseUserInteractivecaseUserInitiatedcaseUtilitycaseBackgroundvarqueue:dispatch_queue_t{switchself{case.Main:returndispatch_get_main_queue()case.UserInteractive:returndispatch_get_global_queue(QOS_CLASS_USER_INTERACTIVE,0)case.UserInitiated:returndispatch_get_global_queue(QOS_CLASS_USER_INITIATED,0)case.Utility:returndispatch_get_global_queue(QOS_CLASS_UTILITY,0)case.Background:returndispatch_get_global_queue(QOS_CLASS_BACKGROUND,0)}}}enumSerialQueue:String,ExcutableQueue{caseDownLoadImage="myApp.SerialQueue.DownLoadImage"caseUpLoadFile="myApp.SerialQueue.UpLoadFile"varqueue:dispatch_queue_t{returndispatch_queue_create(rawValue,DISPATCH_QUEUE_SERIAL)}}

Downloading something then could be written like this:

Queue.UserInitiated.execute{leturl=NSURL(string:"http://image.jpg")!letdata=NSData(contentsOfURL:url)!letimage=UIImage(data:data)Queue.Main.execute{imageView.image=image}}

_ObjectiveCBridgeable

From Mathew Huusko V:

Using Swift’s _ObjectiveCBridgeable (implicit castability between types) to create a generic protocol for Obj-C compatible objects that wrap pure Swift structs (keeping Swift framework API clean, but Obj-C compatible for as long as desired).

This first part defines an extension with default implementations for the bridging bookkeeping methods:

publicprotocolBackedObjectType:AnyObject{typealiasBackingvarbackingObject:Backing{get}init(_backingObject:Backing)}publicprotocolObjectBackable:_ObjectiveCBridgeable{typealiasBacked:BackedObjectType}publicextensionObjectBackablewhereBacked.Backing==Self{staticfunc_isBridgedToObjectiveC()->Bool{returntrue}staticfunc_getObjectiveCType()->Any.Type{returnBacked.self}func_bridgeToObjectiveC()->Backed{returnBacked(self)}staticfunc_forceBridgeFromObjectiveC(source:Backed,inoutresult:Self?){result=source.backingObject}staticfunc_conditionallyBridgeFromObjectiveC(source:Backed,inoutresult:Self?)->Bool{_forceBridgeFromObjectiveC(source,result:&result)returntrue}functoBridgedObject()->Backed{return_bridgeToObjectiveC()}}

Here the Swift struct SomeModel and Objective-C class M5SomeModel are declared and bridged. Bridging between them is accomplished with an as cast:

publicstructSomeModel{publicletID:Intpublicletname:Stringpublicletcategory:String}extensionSomeModel:ObjectBackable{publictypealiasBacked=M5SomeModel}@objcpublicfinalclassM5SomeModel:NSObject,BackedObjectType{publicletbackingObject:SomeModelpublicinit(_backingObject:SomeModel){self.backingObject=backingObject}publicvarID:Int{returnbackingObject.ID}publicvarname:String{returnbackingObject.name}publicvarcategory:String{returnbackingObject.category}}// Usage:letmodel=SomeModel(ID:2,name:"awesome",category:"music")letobjcCompatibleModel=modelasM5SomeModelletoriginalModel=objcCompatibleModelasSomeModel

Phantom Types

Josip Ćavar writes in about getting additional type safety with phantom types. In the example below, Kilometer and Meter are used to constrain what kinds of DistanceT instances can be added together:

structKilometer{}structMeter{}structDistanceT<T>{privateletvalue:Intinit(value:Int){self.value=value}}func+<T>(left:DistanceT<T>,right:DistanceT<T>)->DistanceT<T>{returnDistanceT(value:left.value+right.value)}extensionInt{varkm:DistanceT<Kilometer>{returnDistanceT<Kilometer>(value:self)}varm:DistanceT<Meter>{returnDistanceT<Meter>(value:self)}}letdistanceKilometers=5.kmletdistanceMeters=15.mletnewDistance=distanceKilometers+distanceKilometers// OkletnewDistance=distanceKilometers+distanceMeters// Compiler error

Easier Configuration

From Kyle Van Essen by way of Orta Therox comes a function that streamlines multi-step initialization and configuration processes.

@warn_unused_resultpublicfuncInit<Type>(value:Type,@noescapeblock:(object:Type)->Void)->Type{block(object:value)returnvalue}funcexample(){letlabel=Init(UILabel()){$0.font=UIFont.boldSystemFontOfSize(13.0)$0.text="Hello, World"$0.textAlignment=.Center}}

Well, that rounds out this year’s list—thanks again to all who contributed!

Happy New Year! May your code continue to compile and inspire.

Make no mistake, a tiny keyboard on a slab of glass doesn’t always lend itself to perfect typing. Whether for accuracy or hilarity, anyone typing on an iOS device notices when autocorrect steps in to help out. You might not know, however, that UIKit includes a class to help you with your user’s typing inside your app.

First introduced in iOS 3.2 (or should we call it iPhone OS 3.2, given the early date?), UITextChecker does exactly what it says: it checks text. Read on to learn how you can use this class for spell checking and text completion.

Spell Checking

What happens if you mistype a word in iOS? Type “hipstar” into a text field and iOS will offer to autocorrect to “hipster” most of the time.

We can find the same suggested substitution using UITextChecker:

importUIKitletstr="hipstar"lettextChecker=UITextChecker()letmisspelledRange=textChecker.rangeOfMisspelledWordInString(str,range:NSRange(0..<str.utf16.count),startingAt:0,wrap:false,language:"en_US")ifmisspelledRange.location!=NSNotFound,letguesses=textChecker.guessesForWordRange(misspelledRange,inString:str,language:"en_US")as?[String]{print("First guess: \(guesses.first)")// First guess: hipster}else{print("Not found")}

NSString*str=@"hipstar";UITextChecker*textChecker=[[UITextCheckeralloc]init];NSRangemisspelledRange=[textCheckerrangeOfMisspelledWordInString:strrange:NSMakeRange(0,[strlength])startingAt:0wrap:NOlanguage:@"en_US"];NSArray*guesses=[NSArrayarray];if(misspelledRange.location!=NSNotFound){guesses=[textCheckerguessesForWordRange:misspelledRangeinString:strlanguage:@"en_US"];NSLog(@"First guess: %@",[guessesfirstObject]);// First guess: hipster}else{NSLog(@"Not found");}

The returned array of strings might look like this one:

["hipster","hip star","hip-star","hips tar","hips-tar"]

Or it might not—UITextChecker produces context- and device-specific guesses. According to the documentation, guessesForWordRange(_:inString:language:)“returns an array of strings, in the order in which they should be presented, representing guesses for words that might have been intended in place of the misspelled word at the given range in the given string.”

So no guarantee of idempotence or correctness, which makes sense for a method with guesses... in the name. How can NSHipsters trust a method that changes its return value? We’ll find the answer if we dig further.

Learning New Words

Let’s assume that you want your users to be able to type "hipstar" exactly. Let your app know that by telling it to learn the word, using the UITextChecker.learnWord(_:) class method:

UITextChecker.learnWord(str)

[UITextCheckerlearnWord:str];

"hipstar" is now a recognized word for the whole device and won’t show up as misspelled in further checks.

letmisspelledRange=textChecker.rangeOfMisspelledWordInString(str,range:NSRange(0..<str.utf16.count),startingAt:0,wrap:false,language:"en_US")// misspelledRange.location == NSNotFound

NSRangemisspelledRange=[textCheckerrangeOfMisspelledWordInString:strrange:NSMakeRange(0,[strlength])startingAt:0wrap:NOlanguage:@"en_US"];// misspelledRange.location == NSNotFound

As expected, the search above returns NSNotFound, for UITextChecker has learned the word we created. UITextChecker also provides class methods for checking and unlearning words: UITextChecker.hasLearnedWord(_:) and UITextChecker.unlearnWord(_:).

Suggesting Completions

There’s one more UITextChecker API, this time for finding possible completions for a partial word:

letpartial="hipst"letcompletions=textChecker.completionsForPartialWordRange(NSRange(0..<partial.utf16.count),inString:partial,language:"en_US")// completions == ["hipster", "hipsters"]

NSString*partial=@"hipst";NSArray*completions=[textCheckercompletionsForPartialWordRange:NSMakeRange(0,[partiallength])inString:partiallanguage:@"en_US"];// completions == ["hipster", "hipsters"]

completionsForPartialWordRange gives you an array of possible words from a group of initial characters. Although the documentation states that the returned array of strings will be sorted by probability, UITextChecker only sorts the completions alphabetically. UITextChecker’s OS X-based sibling, NSSpellChecker, does behave as it describes.

You won’t see any of the custom words you’ve taught UITextChecker show up as possible completions. Why not? Since vocabulary added via UITextChecker.learnWord(_:) is global to the device, this prevents your app’s words from showing up in another app’s autocorrections.

Building an app that leans heavily on a textual interface? Use UITextChecker to make sure the system isn’t flagging your own vocabulary. Writing a keyboard extension? With UITextChecker and UILexicon, which provides common and user-defined words from the system-wide dictionary and first and last names from the user’s address book, you can support nearly any language without creating your own dictionaries!

This year’s WWDC edition of the NSHipster Pub Quiz was held on June 14th, once again testing the assembled developers with questions both random and obscure. We’re enormously grateful to Realm, who hosted the quiz for the second year in a row, with delicious food and drink and enough tables to seat nearly two hundred contestants.

Competition was as fierce as always. Laughs and groans were heard. And after the points were tallied, team “Hey Siri” won the evening and the mustache medallions with a score of 31 out of a possible 43 points. A hearty congratulations to Alek Åström, Cezary Wojcik, Kyle Sherman, Marcus Brissman, Marius Rackwitz, Melissa Huang, Nevyn Bengtsson, and Rob Stevenson!

Now it’s time for you to play along with the home edition—sharpen your pencil and give it your best!

• Four rounds of ten questions
• Record your answers on a separate sheet of paper
• Each correct answer earns 1 point (unless otherwise specified)
• Play with friends for maximum enjoyment
• Don’t be lame and look things up on the internet or in Xcode

Round 1: General Knowledge

1. In the WWDC keynote, Apple introduced the new OS X, er… macOS Sierra. The actual Sierra mountain range is home to the highest peak in the contiguous US. What is the name of that mountain?
2. The Sierra were one focal point of a mass migration to California. What San Francisco sports team has ties to the Sierra during that period in history?
3. Another highlight of the keynote was when Bozoma Saint John introduced the new Apple Music and got the crowd singing along to “Rapper’s Delight”—who recorded the song, and in what year? (2 points)
4. Which version of iPhoto first introduced “Faces and Places?”
5. As part of Foundation’s Swiftification, many classes have lost their NS prefixes. Which of these classes remains unchanged so far: NSBundle, NSCalendar, NSExpression, or NSOperation?

6. More than just class names have changed—write the new Swift signature for this NSString method:

   funcstringByReplacingCharactersInRange(_range:NSRange,        withStringreplacement:String)->String

7. Write the Swift 3 code to execute an asynchronous “Hello, world!” using GCD.
8. Swift went open source in November and the pace of community contributions has been amazing to see. Within 100, how many pull requests (open, closed, or merged) has the Swift project received on GitHub?
9. Swift was released to the public just over two years ago, but was clearly under development long before that at Apple. What were the month and year of the first commit to the Swift repository?
10. After Chris Lattner, who was the second contributor to Swift? When was their first commit?

Round 2: Name That Framework

Foundation classes are losing their NS prefixes left and right. What would it look like if we got rid of prefixes in every framework? For each question in this round, you’ll be given three classes with their identifying prefix removed. Name the framework that contains all three.

1. Statistic, Sample, Correlation
2. CallObserver, Transaction, Provider
3. Visit, Heading, Region
4. Conversation, Session, Sticker
5. IndexSet, ValueTransformer, Scanner
6. Participant, Reminder, StructuredLocation
7. Circle, LocalSearch, GeodesicPolyline
8. LabeledValue, PhoneNumber, SocialProfile
9. Quadtree, NoiseSource, MonteCarloStrategist
10. RideStatus, PaymentMethod, CarAirCirculationModeResolutionResult

Round 3: Who Is That?

Many Apple advertisements over the years have featured celebrity voiceovers intoning words of wisdom, inspiration, or at times something else entirely. So pop in your earbuds and for each of the ads below, name the person(s) providing their voice talents.

Round 4: Easy as 1, 2, 3

Swift is an easy language to learn and use, but its breakneck speed of development has meant breaking changes with each release. For the following snippets of code, answer with the version of Swift that will compile and give the desired result. Because some snippets can run in more than one version, some questions may be worth up to 2 points. Only the major versions are required—for example, if a snippet will run in Swift 2.2, “Swift 2” is a scoring answer.

1

leta=["1","2","3","four","5"]letnumbers=map(a){$0.toInt()}letonlyNumbers=filter(numbers){$0!=nil}letsum=reduce(onlyNumbers,0){$0+$1!}// sum == 11

2

leta=["1","2","3","four","5"]letsum=a.flatMap{Int($0)}.reduce(0,combine:+)// sum == 11

3

vara=[8,6,7,5,3,0,9]a.sort()print(a)// [0, 3, 5, 6, 7, 8, 9]

4

vara=[8,6,7,5,3,0,9]sort(a)print(a)// [0, 3, 5, 6, 7, 8, 9]

5

vara=[8,6,7,5,3,0,9]a.sort()print(a)// [8, 6, 7, 5, 3, 0, 9]

6

foriinstride(from:3,to:10,by:3){print(i)}// 3// 6// 9

7

foriin3.stride(to:10,by:3){print(i)}// 3// 6// 9

8

enumMyError:ErrorProtocol{caseOverflowcaseNegativeInput}funcsquare(_value:inoutInt)throws{guardvalue>=0else{throwMyError.NegativeInput}let(result,overflow)=Int.multiplyWithOverflow(value,value)guard!overflowelse{throwMyError.Overflow}value=result}varnumber=11try!square(&number)// number == 121

9

enumMyError:ErrorType{caseOverflowcaseNegativeInput}funcsquareInPlace(inoutvalue:Int)throws{guardvalue>=0else{throwMyError.NegativeInput}let(result,overflow)=Int.multiplyWithOverflow(value,value)guard!overflowelse{throwMyError.Overflow}value=result}varnumber=11try!squareInPlace(&number)// number == 121

10

vara:Int[]=[1,2,3,4,5]letb=aa[0]=100// b == [100, 2, 3, 4, 5]

That’s all! When you’re finished, scroll down a bit for the answers.

.

.

.

Answers

Round 1: General Knowledge

1. Mount Whitney
2. San Francisco 49ers
3. The Sugarhill Gang, 1979 (2 points for both)
4. iPhoto ’09
5. NSExpression

6. One of:

   // 1replacingCharacters(in:NSRange,with:String)// 2funcreplacingCharacters(inrange:NSRange,        withreplacement:String)->String

7. One of:

   // 1letqueue=DispatchQueue(label:"quiz")queue.async{print("Hello, world!")}// 2DispatchQueue.main.async{print("Hello, world!")}

8. 3,012 as of June 14th, 2016 (correct if between 2,912 and 3,112)—check here for the current stats
9. July 2010 (1 point if correct year, 2 if both)
10. Doug Gregor, July 2011 (2 points)

Round 2: Name That Framework

1. HealthKit
2. CallKit
3. Core Location
4. Messages
5. Foundation
6. EventKit
7. MapKit
8. Contacts
9. GamePlayKit
10. Intents

Round 3: Who Is That?

1. Jimmy Fallon & Justin Timberlake (2 points for both)
2. Martin Scorsese
3. Jeff Goldblum
4. Lake Bell
5. Kiefer Sutherland
6. Robin Williams
7. Jony Ive
8. Jeff Daniels
9. Richard Dreyfuss
10. Drunk Jeff Goldblum

Round 4: Easy as 1, 2, 3

If you listed multiple versions, all must be correct for the answer to score.

1. Swift 1
2. Swift 2 or 3 (2 points for both)
3. Swift 3
4. Swift 1
5. Swift 2
6. Swift 1 or 3 (2 points for both)
7. Swift 2
8. Swift 3
9. Swift 2
10. Initial beta release of Swift

How’d you do? Tweet out your score to see how you stack up to your peers!

“Some people, when confronted with a problem, think ‘I know, I’ll use NSRegularExpression.’ Now they have three problems.”

Regular expressions fill a controversial role in the programming world. Some find them impenetrably incomprehensible, thick with symbols and adornments, more akin to a practical joke than part of a reasonable code base. Others rely on their brevity and their power, wondering how anyone could possibly get along without such a versatile tool in their arsenal.

Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has the most long-winded and byzantine regular expression interface you’re ever likely to come across. Don’t believe me? Let’s try extracting the links from this snippet of HTML, first using Ruby:

htmlSource="Questions? Corrections? <a href=\"https://twitter.com/NSHipster\">@NSHipster</a> or <a href=\"https://github.com/NSHipster/articles\">on GitHub</a>."linkRegex=/<a\s+[^>]*href="([^"]*)"[^>]*>/ilinks=htmlSource.scan(linkRegex)puts(links)# https://twitter.com/NSHipster# https://github.com/NSHipster/articles

Two or three lines, depending on how you count—not bad. Now we’ll try the same thing in Swift using NSRegularExpression:

lethtmlSource="Questions? Corrections? <a href=\"https://twitter.com/NSHipster\">@NSHipster</a> or <a href=\"https://github.com/NSHipster/articles\">on GitHub</a>."letlinkRegexPattern="<a\\s+[^>]*href=\"([^\"]*)\"[^>]*>"letlinkRegex=try!NSRegularExpression(pattern:linkRegexPattern,options:.caseInsensitive)letmatches=linkRegex.matches(in:htmlSource,range:NSMakeRange(0,htmlSource.utf16.count))letlinks=matches.map{result->StringinlethrefRange=result.rangeAt(1)letstart=String.UTF16Index(hrefRange.location)letend=String.UTF16Index(hrefRange.location+hrefRange.length)returnString(htmlSource.utf16[start..<end])!}print(links)// ["https://twitter.com/NSHipster", "https://github.com/NSHipster/articles"]

The prosecution rests.

This article won’t get into the ins and outs of regular expressions themselves (you may need to learn about wildcards, backreferences, lookaheads and the rest elsewhere), but read on to learn about NSRegularExpression, NSTextCheckingResult, and a particularly sticky point when bringing it all together in Swift.

NSString Methods

The simplest way to use regular expressions in Cocoa is to skip NSRegularExpression altogether. The range(of:...) method on NSString (which is bridged to Swift’s native String type) switches into regular expression mode when given the .regularExpression option, so lightweight searches can be written easily:

letsource="For NSSet and NSDictionary, the breaking..."// Matches anything that looks like a Cocoa type:// UIButton, NSCharacterSet, NSURLSession, etc.lettypePattern="[A-Z]{3,}[A-Za-z0-9]+"iflettypeRange=source.range(of:typePattern,options:.regularExpression){print("First type: \(source[typeRange])")// First type: NSSet}

NSString*source=@"For NSSet and NSDictionary, the breaking...";// Matches anything that looks like a Cocoa type:// UIButton, NSCharacterSet, NSURLSession, etc.NSString*typePattern=@"[A-Z]{3,}[A-Za-z0-9]+";NSRangetypeRange=[sourcerangeOfString:typePatternoptions:NSRegularExpressionSearch];if(typeRange.location!=NSNotFound){NSLog(@"First type: %@",[sourcesubstringWithRange:typeRange]);// First type: NSSet}

Replacement is also a snap using replacingOccurrences(of:with:...) with the same option. Watch how we surround each type name in our text with Markdown-style backticks using this one weird trick:

letmarkedUpSource=source.replacingOccurrences(of:typePattern,with:"`$0`",options:.regularExpression)print(markedUpSource)// "For `NSSet` and `NSDictionary`, the breaking...""

NSString*markedUpSource=[sourcestringByReplacingOccurrencesOfString:typePatternwithString:@"`$0`"options:NSRegularExpressionSearchrange:NSMakeRange(0,source.length)];NSLog(@"%@",markedUpSource);// "For `NSSet` and `NSDictionary`, the breaking...""

This approach to regular expressions can even handle subgroup references in the replacement template. Lo, a quick and dirty Pig Latin transformation:

letourcesay=source.replacingOccurrences(of:"([bcdfghjklmnpqrstvwxyz]*)([a-z]+)",with:"$2$1ay",options:[.regularExpression,.caseInsensitive])print(ourcesay)// "orFay etNSSay anday ictionaryNSDay, ethay eakingbray..."

NSString*ourcesay=[sourcestringByReplacingOccurrencesOfString:@"([bcdfghjklmnpqrstvwxyz]*)([a-z]+)"withString:@"$2$1ay"options:NSRegularExpressionSearch|NSCaseInsensitiveSearchrange:NSMakeRange(0,source.length)];NSLog(@"%@",ourcesay);// "orFay etNSSay anday ictionaryNSDay, ethay eakingbray..."

These two methods will suffice for many places you might want to use regular expressions, but for heavier lifting, we’ll need to work with NSRegularExpression itself. First, though, let’s sort out a minor complication when using this class from Swift.

NSRange and Swift

Swift provides a more comprehensive, more complex interface to a string’s characters and substrings than does Foundation’s NSString. The Swift standard library provides four different views into a string’s data, giving you quick access to the elements of a string as characters, Unicode scalar values, or UTF-8 or UTF-16 code units.

How does this relate to NSRegularExpression? Well, many NSRegularExpression methods use NSRanges, as do the NSTextCheckingResult instances that store a match’s data. NSRange, in turn, uses integers for its location and length, while none of String’s views use integers as an index:

letrange=NSRange(location:4,length:5)// Not one of these will compile:source[range]source.characters[range]source.substring(with:range)source.substring(with:range.toRange()!)

Confusion. Despair.

But don’t give up! Everything isn’t as disconnected as it seems—the utf16 view on a Swift String is meant specifically for interoperability with Foundation’s NSString APIs. As long as Foundation has been imported, you can create new indices for a utf16 view directly from integers:

letstart=String.UTF16Index(range.location)letend=String.UTF16Index(range.location+range.length)letsubstring=String(source.utf16[start..<end])!// substring is now "NSSet"

With that in mind, here are a few additions to String that will make straddling the Swift/Objective-C divide a bit easier:

extensionString{/// An `NSRange` that represents the full range of the string.varnsrange:NSRange{returnNSRange(location:0,length:utf16.count)}/// Returns a substring with the given `NSRange`,/// or `nil` if the range can't be converted.funcsubstring(withnsrange:NSRange)->String?{guardletrange=nsrange.toRange()else{returnnil}letstart=UTF16Index(range.lowerBound)letend=UTF16Index(range.upperBound)returnString(utf16[start..<end])}/// Returns a range equivalent to the given `NSRange`,/// or `nil` if the range can't be converted.funcrange(fromnsrange:NSRange)->Range<Index>?{guardletrange=nsrange.toRange()else{returnnil}letutf16Start=UTF16Index(range.lowerBound)letutf16End=UTF16Index(range.upperBound)guardletstart=Index(utf16Start,within:self),letend=Index(utf16End,within:self)else{returnnil}returnstart..<end}}

We’ll put these to use in the next section, where we’ll finally see NSRegularExpression in action.

NSRegularExpression& NSTextCheckingResult

If you’re doing more than just searching for the first match or replacing all the matches in your string, you’ll need to build an NSRegularExpression to do your work. Let’s build a miniature text formatter that can handle *bold* and _italic_ text.

Pass a pattern and, optionally, some options to create a new instance. miniPattern looks for an asterisk or an underscore to start a formatted sequence, one or more characters to format, and finally a matching character to end the formatted sequence. The initial character and the string to format are both captured:

letminiPattern="([*_])(.+?)\\1"letminiFormatter=try!NSRegularExpression(pattern:miniPattern,options:.dotMatchesLineSeparators)// the initializer throws an error if the pattern is invalid

NSString*miniPattern=@"([*_])(.+?)\\1";NSError*error=nil;NSRegularExpression*miniFormatter=[NSRegularExpressionregularExpressionWithPattern:miniPatternoptions:NSRegularExpressionDotMatchesLineSeparatorserror:&error];

The initializer throws an error if the pattern is invalid. Once constructed, you can use an NSRegularExpression as often as you need with different strings.

lettext="MiniFormatter handles *bold* and _italic_ text."letmatches=miniFormatter.matches(in:text,options:[],range:text.nsrange)// matches.count == 2

NSString*text=@"MiniFormatter handles *bold* and _italic_ text.";NSArray<NSTextCheckingResult*>*matches=[miniFormattermatchesInString:textoptions:kNilOptionsrange:NSMakeRange(0,text.length)];// matches.count == 2

Calling matches(in:options:range:) fetches an array of NSTextCheckingResult, the type used as the result for a variety of text handling classes, such as NSDataDetector and NSSpellChecker. The resulting array has one NSTextCheckingResult for each match.

The information we’re most interested are the range of the match, stored as range in each result, and the ranges of any capture groups in the regular expression. You can use the numberOfRanges property and the rangeAt(_:)method to find the captured ranges—range 0 is always the full match, with the ranges at indexes 1 up to, but not including, numberOfRanges covering each capture group.

Using the NSRange-based substring method we declared above, we can use these ranges to extract the capture groups:

formatchinmatches{letstringToFormat=text.substring(with:match.rangeAt(2))!switchtext.substring(with:match.rangeAt(1))!{case"*":print("Make bold: '\(stringToFormat)'")case"_":print("Make italic: '\(stringToFormat)'")default:break}}// Make bold: 'bold'// Make italic: 'italic'

for(NSTextCheckingResult*matchinmatches){NSString*delimiter=[textsubstringWithRange:[matchrangeAtIndex:1]];NSString*stringToFormat=[textsubstringWithRange:[matchrangeAtIndex:2]];if([delimiterisEqualToString:@"*"]){NSLog(@"Make bold: '%@'",stringToFormat);}elseif([delimiterisEqualToString:@"_"]){NSLog(@"Make italic: '%@'",stringToFormat);}}// Make bold: 'bold'// Make italic: 'italic'

For basic replacement, head straight to stringByReplacingMatches(in:options:range:with:), the long-winded version of String.replacingOccurences(of:with:options:). In this case, we need to use different replacement templates for different matches (bold vs. italic), so we’ll loop through the matches ourselves (moving in reverse order, so we don’t mess up the ranges of later matches):

varformattedText=textFormat:formatchinmatches.reversed(){lettemplate:Stringswitchtext.substring(with:match.rangeAt(1))??""{case"*":template="<strong>$2</strong>"case"_":template="<em>$2</em>"default:breakFormat}letmatchRange=formattedText.range(from:match.range)!// see aboveletreplacement=miniFormatter.replacementString(for:match,in:formattedText,offset:0,template:template)formattedText.replaceSubrange(matchRange,with:replacement)}// 'formattedText' is now:// "MiniFormatter handles <strong>bold</strong> and <em>italic</em> text."

NSMutableString*formattedText=[NSMutableStringstringWithString:text];for(NSTextCheckingResult*matchin[matchesreverseObjectEnumerator]){NSString*delimiter=[textsubstringWithRange:[matchrangeAtIndex:1]];NSString*template=[delimiterisEqualToString:@"*"]?@"<strong>$2</strong>":@"<em>$2</em>";NSString*replacement=[miniFormatterreplacementStringForResult:matchinString:formattedTextoffset:0template:template];[formattedTextreplaceCharactersInRange:[matchrange]withString:replacement];}// 'formattedText' is now:// @"MiniFormatter handles <strong>bold</strong> and <em>italic</em> text."

Calling miniFormatter.replacementString(for:in:...) generates a replacement string specific to each NSTextCheckingResult instance with our customized template.

Expression and Matching Options

NSRegularExpression is highly configurable—you can pass different sets of options when creating an instance or when calling any method that performs matching.

NSRegularExpression.Options

Pass one or more of these as options when creating a regular expression.

• .caseInsensitive: Turns on case insensitive matching. Equivalent to the i flag.
• .allowCommentsAndWhitespace: Ignores any whitespace and comments between a # and the end of a line, so you can format and document your pattern in a vain attempt at making it readable. Equivalent to the x flag.
• .ignoreMetacharacters: The opposite of the .regularExpression option in String.range(of:options:)—this essentially turns the regular expression into a plain text search, ignoring any regular expression metacharacters and operators.
• .dotMatchesLineSeparators: Allows the . metacharacter to match line breaks as well as other characters. Equivalent to the s flag.
• .anchorsMatchLines: Allows the ^ and $ metacharacters (beginning and end) to match the beginnings and ends of lines instead of just the beginning and end of the entire input string. Equivalent to the m flag.
• .useUnixLineSeparators, .useUnicodeWordBoundaries: These last two opt into more specific line and word boundary handling: UNIX line separators

NSRegularExpression.MatchingOptions

Pass one or more of these as options to any matching method on an NSRegularExpression instance.

• .anchored: Only match at the start of the search range.
• .withTransparentBounds: Allows the regex to look past the search range for lookahead, lookbehind, and word boundaries (though not for actual matching characters).
• .withoutAnchoringBounds: Makes the ^ and $ metacharacters match only the beginning and end of the string, not the beginning and end of the search range.
• .reportCompletion, .reportProgress: These only have an effect when passed to the method detailed in the next section. Each option tells NSRegularExpression to call the enumeration block additional times, when searching is complete or as progress is being made on long-running matches, respectively.

Partial Matching

Finally, one of the most powerful features of NSRegularExpression is the ability to scan only as far into a string as you need. This is especially valuable on a large string, or when using an pattern that is expensive to run.

Instead of using the firstMatch(in:...) or matches(in:...) methods, call enumerateMatches(in:options:range:using:) with a closure to handle each match. The closure receives three parameters: the match, a set of flags, and a pointer to a Boolean that acts as an out parameter, so you can stop enumerating at any time.

We can use this method to find the first several names in Dostoevsky’s Brothers Karamazov, where names follow a first and patronymic middle name style (e.g., “Ivan Fyodorovitch”):

letnameRegex=try!NSRegularExpression(pattern:"([A-Z]\\S+)\\s+([A-Z]\\S+(vitch|vna))")letbookString=...varnames:Set<String>=[]nameRegex.enumerateMatches(in:bookString,range:bookString.nsrange){(result,_,stopPointer)inguardletresult=resultelse{return}letname=nameRegex.replacementString(for:result,in:bookString,offset:0,template:"$1 $2")names.insert(name)// stop once we've found six unique namesstopPointer.pointee=ObjCBool(names.count==6)}// names.sorted():// ["Adelaïda Ivanovna", "Alexey Fyodorovitch", "Dmitri Fyodorovitch",//  "Fyodor Pavlovitch", "Pyotr Alexandrovitch", "Sofya Ivanovna"]

NSString*namePattern=@"([A-Z]\\S+)\\s+([A-Z]\\S+(vitch|vna))";NSRegularExpression*nameRegex=[NSRegularExpressionregularExpressionWithPattern:namePatternoptions:kNilOptionserror:&error];NSString*bookString=...NSMutableSet*names=[NSMutableSetset];[nameRegexenumerateMatchesInString:bookStringoptions:kNilOptionsrange:NSMakeRange(0,[bookStringlength])usingBlock:^(NSTextCheckingResult*result,NSMatchingFlagsflags,BOOL*stop){if(result==nil)return;NSString*name=[nameRegexreplacementStringForResult:resultinString:bookStringoffset:0template:@"$1 $2"];[namesaddObject:name];// stop once we've found six unique names*stop=(names.count==6);}];

With this approach we only need to look at the first 45 matches, instead of nearly 1300 in the entirety of the book. Not bad!

Once you get to know it, NSRegularExpression can be a truly useful tool. In fact, you may have used it already to find dates, addresses, or phone numbers in user-entered text—NSDataDetector is an NSRegularExpression subclass with patterns baked in to identify useful info. Indeed, as we’ve come to expect of text handling throughout Foundation, NSRegularExpression is thorough, robust, and has surprising depth beneath its tricky interface.

The term “boilerplate” goes back to the early days of print media. Small regional newspapers had column inches to fill, but typically lacked the writing staff to make this happen, so many of them turned to large print syndicates for a steady flow of content that could be added verbatim into the back pages of their dailies. These stories would often be provided on pre-set plates, which resembled the rolled sheets of steel used to make boilers, hence the name.

Through a process of metonymy, the content itself came to be known as “boilerplate”, and the concept was appropriated to encompass standardized, formulaic text in contracts, form letters, and, most relevant to this week’s article on NSHipster, code.

Not all code can be glamorous. In fact, a lot of the low-level infrastructure that makes everything work is a slog of boilerplate.

This is true of the Swift standard library, which includes families of types like signed integers (Int8, Int16, Int32, Int64) whose implementation varies only in the size of the respective type.

Copy-pasting code may work as a one-off solution (assuming you manage to get it right the first time), but it’s not sustainable. Each time you want to make changes to these derived implementations, you risk introducing slight inconsistencies that cause the implementations to diverge over time — not unlike the random mutations responsible for the variation of life on Earth.

Languages have various techniques to cope with this, from C++ templates and Lisp macros to eval and C preprocessor statements.

Swift doesn’t have a macro system, and because the standard library is itself written in Swift, it can’t take advantage of C++ metaprogramming capabilities. Instead, the Swift maintainers use a Python script called gyb.py to generate source code using a small set of template tags.

GYB is an acronym for “Generate Your Boilerplate”, a reference to another Python tool, GYP, or “Generate Your Projects”.

How GYB Works

GYB is a lightweight templating system that allows you to use Python code for variable substitution and flow control:

• The sequence %{ <#code#> } evaluates a block of Python code
• The sequence % <#code#>: ... % end manages control flow
• The sequence ${ <#code#> } substitutes the result of an expression

All other text is passed through unchanged.

A good example of GYB can be found in Codable.swift.gyb. At the top of the file, the base Codable types are assigned to an instance variable:

%{codable_types=['Bool','String','Double','Float','Int','Int8','Int16','Int32','Int64','UInt','UInt8','UInt16','UInt32','UInt64']}%

Later on, in the implementation of SingleValueEncodingContainer, these types are iterated over to generate the methods declarations for the protocol’s requirements:

%fortypeincodable_types:mutatingfuncencode(_value:${type},forKeykey:Key)throws%end

Evaluating the GYB template results in the following declarations:

mutatingfuncencode(_value:Bool)throwsmutatingfuncencode(_value:String)throwsmutatingfuncencode(_value:Double)throwsmutatingfuncencode(_value:Float)throwsmutatingfuncencode(_value:Int)throwsmutatingfuncencode(_value:Int8)throwsmutatingfuncencode(_value:Int16)throwsmutatingfuncencode(_value:Int32)throwsmutatingfuncencode(_value:Int64)throwsmutatingfuncencode(_value:UInt)throwsmutatingfuncencode(_value:UInt8)throwsmutatingfuncencode(_value:UInt16)throwsmutatingfuncencode(_value:UInt32)throwsmutatingfuncencode(_value:UInt64)throws

This pattern is used throughout the file to generate similarly formulaic declarations for methods like encode(_:forKey:), decode(_:forKey:), and decodeIfPresent(_:forKey:). In total, GYB reduces the amount of boilerplate code by a few thousand LOC:

$wc-l Codable.swift.gyb
          2183 Codable.swift.gyb
          $wc-l Codable.swift
          5790 Codable.swift
          

Important: A valid GYB template may not generate valid Swift code. If compilation errors occur in derived files, it may be difficult to determine the underlying cause.

Using GYB in Xcode

GYB isn’t part of the standard Xcode toolchain, so you won’t find it with xcrun. Instead, you can download the source code and then use the chmod command to make gyb executable (the default installation of Python on macOS should be able to run gyb):

$ wget https://github.com/apple/swift/raw/master/utils/gyb
          $ wget https://github.com/apple/swift/raw/master/utils/gyb.py
          $chmod +x gyb
          

Move these somewhere that can be accessed from your Xcode project, but keep them separate from your source files. For example, a Vendor directory at your project root.

In Xcode, click on the blue project file icon in the navigator, select the active target in your project, and navigate to the “Build Phases” panel. At the top, you’ll see a + symbol that you can click to add a new build phase. Select “Add New Run Script Phase”, and enter the following into the source editor:

find .-name'*.gyb' |                                               \while read file;do\
          ./path/to/gyb --line-directive''-o"${file%.gyb}""$file";\done

Make sure to order the GYB build phase before Compile Sources.

Now when you build your project any file with the .swift.gyb file extension is evaluated by GYB, which outputs a .swift file that’s compiled along with the rest of the code in the project.

When to Use GYB

As with any tool, knowing when to use it is just as important as knowing how. Here are some examples of when you might open your toolbox and reach for GYB.

Generating Formulaic Code

Are you copy-pasting the same code for elements in a set or items in a sequence? A for-in loop with variable substitution might be the solution.

As seen in the example with Codable from before, you can declare a collection at the top of your GYB template file and then iterate over that collection for type, property, or method declarations:

%{abilities=['strength','dexterity','constitution','intelligence','wisdom','charisma']}classCharacter{varname:String%forabilityinabilities:var${type}:Int%end}

Just be aware that a lot of repetition is a code smell, and may indicate that there’s a better way to accomplish your task. Built-in language feature like protocol extensions and generics can eliminate a lot of code duplication, so be on the lookout to use these instead of brute-forcing with GYB.

Generating Code Derived from Data

Are you writing code based on a data source? Try incorporating GYB into your development!

GYB files can import of Python packages like json, xml, and csv, so you can parse pretty much any kind of file you might encounter:

%{importcsv}%withopen('path/to/file.csv')asfile:%forrowincsv.DictReader(file):

If you want to see this in action, check out Currencies.swift.gyb which generates Swift enumerations for each of the currencies defined by the ISO 4217 specification.

Keep compilation fast and deterministic by downloading data to files that can be checked into source control rather than making HTTP requests or database queries in GYB files.

Code generation makes it trivial to keep your code in sync with the relevant standards. Simply update the data file and re-run GYB.

Swift has done a lot to cut down on boilerplate recently with the addition of compiler synthesis of Encodable and Decodable in 4.0, Equatable and Hashable in 4.1, and CaseIterable in 4.2. We hope that this momentum is carried in future updates to the language.

In the meantime, for everything else, GYB is a useful tool for code generation.

Another great tool from the community for this is Sourcery, which allows you to write templates in Swift (via Stencil) rather than Python.

“Don’t Repeat Yourself” may be a virtue in programming, but sometimes you have to say things a few times to make things work. When you do, you’ll be thankful to have a tool like GYB to say it for you.

“File a radar.” It’s a familiar refrain for those of us developing on Apple platforms.

It’s what you hear when you complain about a wandering UIKit component.
It’s the response you get when you share some hilariously outdated documentation.
It’s that voice inside your head when you reopen Xcode for the twelfth time today.

If you’ve ever been told to “file a Radar” and wondered what that meant, this week’s article has just the fix.

Radar is Apple’s bug tracking software. Any employee working in an engineering capacity interacts with it on a daily basis.

Radar is used to track features and bugs alike, in software, hardware, and everything else: documentation, localization, web properties — heck, even the responses you get from Siri.

When an Apple engineer hears the word “Radar”, one of the first things that come to mind is the iconic purple anteater of Radar.app. But more important than the app or even the database itself, Radar is a workflow that guides problems from report to verification across the entire organization.

When a Radar is created, it’s assigned a unique, permanent ID. Radar IDs are auto-incrementing integers, so you can get a general sense of when a bug was filed from the number alone. (At the time of writing, new Radars have 9-digit IDs starting with 4.)

Radar.app uses the rdar:// custom URL scheme. If an Apple employee clicks a rdar://xxxxxxxxx link with an ID, it’ll open directly to that Radar. Otherwise, clicking this link pops up a dialog box with the message “There is no application set to open the URL rdar://xxxxxxxxx.”

Reporting Bugs as External Developers

Unfortunately for all of us not working at Apple, we can’t access Radar directly. Instead, we have to file bugs through systems that interface with it indirectly.

Apple Bug Reporter

Apple Bug Reporter is the primary interface to Radar for external developers. To file a bug, you must be an Apple Developer Program member.

Bug Reporter was recently updated to a modern web app that resembles Mail and other apps on iCloud.com. For anyone who remembers its predecessor, I think you’ll agree that this is a huge improvement.

Choose the product related to the problem you’re reporting and enter a descriptive title. If it’s a bug, specify whether the kind of bug (Performance, Crash/Hang/Data Loss, UI/Usability, etc.) and how often you can produce it. Finally, write a description of the problem, including a summary, steps to reproduce, expected vs. actual results, and information about the configuration and version of your system.

This information is compiled into a Radar that is then triaged, assigned, prioritized, and scheduled by engineers.

Feedback Assistant

If you’re participating in the Apple Beta Software Program, and encounter a problem with your prerelease OS, you can alternatively report it using Feedback Assistant (find it on macOS and iOS with Spotlight).

Feedback Assistant offers a more streamlined experience that’s optimized for providing feedback about the platform you’re living on. It automatically captures a sysdiagnose and other information about your system in order to diagnose the problem you’re encountering more accurately.

Whereas Bug Reporter is your first choice for problems directly related to your work, Feedback Assistant is often a more convenient option for any bumps you encounter in your day-to-day.

Third-Party Bug Reporting Tools

When developers encounter a problem, they’re motivated to do something about it rather than merely complain. This is the reason they file bug reports in the first place.

This is, incidentally, the same motivation that compels us to create tools to fix problems that we find in the bug reporting process itself.

Here are some essential tools for bug reporting from the Apple developer community:

Open Radar

The fundamental problem with Radar as an external developer is lack of transparency. One of the ways this manifests itself is that there’s no way to know what anyone else has reported. All too often, you’ll invest a good deal of time writing up a detailed summary and creating a reproducible test case only to have the bug unceremoniously closed as a duplicate.

OpenRadar, created by Tim Burks, is a public database of bugs reported to Apple. Over the many years of its existence, OpenRadar has become the de facto way for us to coordinate our bug reports.

When you file a Radar with apple, you’re encouraged to also file it with OpenRadar (unless it’s something that shouldn’t be disclosed publicly). Your contribution can help anyone else who might have the same problem in the future.

Brisk

Although the recently-overhauled Bug Reporter web app is quite nice to use, there’s no replacement for a native app.

Brisk, created by Keith Smiley, is a macOS app for filing Radars through Apple’s Bug Reporter. It’s a fully-featured app, with support for two-factor authentication, saving radars as drafts, automatically duping radars by ID, and even opening rdar:// URLs. But it’s killer feature is the ability to cross-post bug reports to Open Radar.

To get started, download the latest release from GitHub or install via Homebrew with the following command:

$ brew cask install Brisk

Advice for Writing a Good Bug Report

So now that you know how to write a bug report let’s talk about how to write a good one.

One Problem, One Bug Report

You won’t be doing anyone any favors by reporting multiple bugs in the same report. Each additional concern you raise makes it both more difficult to understand and less actionable for the assigned engineer.

Instead, file multiple Radars and reference any related problems by ID in your summary.

Choose a Title Strategically

Before an issue can start to be resolved by an engineer, it needs to find its way to them. The best way to ensure things get to the right person is to surface the most important information in the title.

• For problems about an API, put the fully-qualified symbol name in the title (for example, URLSession.dataTaskWithRequest(_:)).
• For problems related to documentation, include the full list of navigation breadcrumbs in the title (for example, “Foundation > URL Loading System > URLSession > dataTaskWithRequest:”).
• For problems with a particular app, reference the app name, version, and build number, which are found in the “About” info box (for example, “Xcode 10.0 beta (10L176w)”).

Don’t Be Antagonistic

Chances are, you’re not at your cheeriest when you’re writing a bug report.

It’s unacceptable that this doesn’t work as expected. You wasted hours trying to debug this problem. Apple doesn’t care about software quality anymore.

That sucks. We get it.

However, none of that is going to solve your problem any faster. If anything, hostility will make an engineer less likely to address your concern.

Remember that there’s a person on the other end of your bug report. Practice empathy.

Peter Steinberger has more great advice on the subject in this blog post.

How to Signal Boost Bug Reports

External developers may often liken the experience of filing a Radar to sending a message into a black hole. With thousands of new Radars coming in every hour, the odds of the right person seeing your bug report in a timely manner seem impossibly small.

Fortunately, there are a few things you can do to help your chances:

Duplicating Existing Radars

In Apple’s bug triage workflow, each problem is (ideally) tracked by a single Radar. If multiple Radars seem to report the same underlying problem, the oldest or most specific one is kept around while the others are closed as duplicates. This resolution can be frustrating for external developers, as this is often the last word they hear about a problem they’re having — particularly if the original Radar isn’t visible to them.

That said, having your bug closed as a duplicate isn’t always a bad thing. You can knowingly file a duplicate of an existing Radar as a way to say “I have this problem, too” and “Please fix this first”. However annoying this might be for the Apple engineer responsible for triage, part of me can’t help projecting a courage to those doomed bug reports, who courageously sacrifice themselves in the name of software quality. Semper fidelis, buggos.

Twitter

Some teams within Apple are quite responsive to feedback on Twitter. It’s hard to stay in-the-loop when you’re in The Loop, so engineers and higher-ups alike often tune in to channel the vox populi.

Due to the chilling nature of Apple’s social media policies, you’re unlikely ever to hear anything back. But rest assured that your Tweets are showing up on a saved Twitter search somewhere in Cupertino.

Blogging

Apple engineers are developers like you or me, and many of them pay attention to what we’re writing about. In addition to being helpful to fellow developers, a simple write-up may be just the thing that convinces that one engineer to take another look.

Speaking from my personal experience working at Apple, Radar is far and away the best bug tracking systems I’ve ever used. So it can be frustrating to be back on the outside looking in, knowing full well what we’re missing out on as external developers.

In contrast to open source software, which empowers anyone to fix whatever bugs they might encounter, the majority of Apple software is proprietary; there’s often very little that we can do. Our only option is to file a bug report and hope for the best.

Fortunately, things have gotten better. The new Bug Reporter site is excellent, and the process itself appears to be moving towards greater transparency:

Encouraging change on @apple’s bug reporter… I’ve been hearing of people now getting notified when an original is “awaiting verification”, and not just “closed”” Dave DeLong (@davedelong) via Twitter

The only way things continue to improve is if we communicate.

So the next time you find something amiss, remember: “file a radar”.

It’s no wonder why hipsters obsess over artisanal this and handcrafted that. Whether it’s a thick slice of avocado toast, a bottle of small batch (nondairy) golden milk, or a perfect cup of pour-over coffee — there’s no replacement for a human touch.

In stark contrast, good passwords are the opposite of artisanal. Unless it’s the title of a hacker movie from the 90’s or the solution to an escape room puzzle, a password should be utterly devoid of meaning.

With Safari in iOS 12 and macOS Mojave, it’ll be easier than ever to generate the strongest, most meaningless, most impossible-to-guess passwords imaginable — all thanks to a few new features.

An ideal password policy is simple: Enforce a minimum number of characters (at least 8) and allow for longer passwords (64 or more).

Anything more elaborate, be it pre-selected security questions, periodic password expiration, or arcane character requirements do little more than annoy the people these policies try to protect.

But don’t take my word for it — I’m not a security expert.

Instead, check out the latest Digital Identity Guidelines from NIST (published June 2017).

The good news is that more companies and organizations are starting to pay attention to security best practices. The bad news is that it took a series of massive data breaches affecting millions of people in order for things to change. And the ugly truth is that because corporations and governments take forever to do anything, many of the aforementioned security anti-patterns aren’t going away anytime soon.

Automatic Strong Passwords

Safari AutoFill has been able to generate passwords since iOS 8, but one of its shortcomings was that it couldn’t guarantee that a generated password satisfied the requirements of a particular service.

Apple aims to solve this problem with a new Automatic Strong Passwords feature in Safari, iOS 12, and macOS Mojave.

WebKit engineer Daniel Bates submitted this proposal for consideration to the WHATWG on March 1st. On June 6th, the WebKit team announced Safari Technology Preview Release 58, with support for strong password generation using the new passwordrules attribute. This announcement coincided with the release iOS 12 beta SDKs at WWDC, which included a new UITextInputPasswordRules API, along with a number of other password management features, including Security Code AutoFill and federated authentication.

Password Rules

Password rules are like a recipe for password generators. By following a few simple rules, the password generator can randomly generate new, secure passwords that comply with the particular requirements of the service provider.

Password rules consist of one or more key-value pairs in the following form:

required: lower; required: upper; required: digit; allowed: ascii-printable; max-consecutive: 3;

Keys

Each rule may specify one of the following keys:

• required: The kinds of characters that are required
• allowed: The kinds of characters that are allowed
• max-consecutive: The maximum number of consecutive characters allowed
• minlength: The minimum password length
• maxlength: The maximum password length

The required and allowed keys have one of the character classes listed below as their value. The max-consecutive, minlength, and maxlength keys have a nonnegative integer as their value.

Character Classes

The required and allowed keys may have any one of the following named character classes as their value.

• upper (A-Z)
• lower (a-z)
• digits (0-9)
• special (-~!@#$%^&\*\_+=`|(){}[:;"'<>,.? ] and space)
• ascii-printable (U+0020 — 007f)
• unicode (U+0 — 10FFFF)

In addition to these presets, you may specify a custom character class with ASCII characters surrounded by square brackets (for example, [abc]).

Apple’s Password Rules Validation Tool allows you to experiment with different rules and get real-time feedback of their results. You can even generate and download passwords by the thousands to use during development and testing!

For more information about Password Rules syntax, check out Apple’s “Customizing Password AutoFill Rules”.

Specifying Password Rules

On iOS, you set the passwordRules property of a UITextField with a UITextInputPasswordRules object (you should also set the textContentType to .newPassword while you’re at it):

letnewPasswordTextField=UITextField()newPasswordTextField.textContentType=.newPasswordnewPasswordTextField.passwordRules=UITextInputPasswordRules(descriptor:"required: upper; required: lower; required: digit; max-consecutive: 2; minlength: 8;")

On the web, you set the passwordrules attribute to an <input> element with type="password":

<inputtype="password"passwordrules="required: upper; required: lower; required: special; max-consecutive: 3;"/>

If unspecified, the default password rule is allowed: ascii-printable. Though if your form has a password confirmation field, it will automatically follow the rules from the preceding field.

Generating Password Rules in Swift

If the thought of working with a string-based format without a proper abstraction gives you the heebie-jeebies, you’re not alone.

Here’s one way to encapsulate Password Rules in a Swift API:

enumPasswordRule{enumCharacterClass{caseupper,lower,digits,special,asciiPrintable,unicodecasecustom(Set<Character>)}caserequired(CharacterClass)caseallowed(CharacterClass)casemaxConsecutive(UInt)caseminLength(UInt)casemaxLength(UInt)}extensionPasswordRule:CustomStringConvertible{vardescription:String{switchself{case.required(letcharacterClass):return"required: \(characterClass)"case.allowed(letcharacterClass):return"allowed: \(characterClass)"case.maxConsecutive(letlength):return"max-consecutive: \(length)"case.minLength(letlength):return"minlength: \(length)"case.maxLength(letlength):return"maxlength: \(length)"}}}extensionPasswordRule.CharacterClass:CustomStringConvertible{vardescription:String{switchself{case.upper:return"upper"case.lower:return"lower"case.digits:return"digits"case.special:return"special"case.asciiPrintable:return"ascii-printable"case.unicode:return"unicode"case.custom(letcharacters):return"["+String(characters)+"]"}}}

With this in place, we can now specify a series of rules in code and use them to generate a string with valid password rules syntax:

letrules:[PasswordRule]=[.required(.upper),.required(.lower),.required(.special),.minLength(20)]letdescriptor=rules.map{"\($0.description);"}.joined(separator:"")// "required: upper; required: lower; required: special; max-consecutive: 3;"

If you feel so inclined, you could even extend UITextInputPasswordRules to provide a convenience initializer that takes an array of PasswordRule values:

extensionUITextInputPasswordRules{convenienceinit(rules:[PasswordRule]){letdescriptor=rules.map{$0.description}.joined(separator:"; ")self.init(descriptor:descriptor)}}

If you’re the sentimental type when it comes to personal credentials, and enjoy name dropping your college or dog or favorite sports team behind the anonymous bullets of password input fields, please consider reforming your ways.

Speaking personally, I can’t imagine going about my day-to-day without my password manager. It’s hard to overstate the peace of mind you get by knowing that any information you ever needed is accessible to you — and only you — whenever you need it.

By taking this step now, you’ll be able to take full advantage of these improvements coming to Safari when iOS 12 and macOS Mojave arrive later this year.

“Never” is a proposition that an event doesn’t occur at any time in the past or future. It’s logical impossibility with a time axis; nothingness stretching out in all directions, forever.

…which is why it’s especially worrisome to encounter this comment in code:

// this will never happen

Every compiler textbook will tell you that a comment like this one can’t and won’t affect the behavior of compiled code. Murphy’s Law says otherwise.

How does Swift keep us safe in the unpredictable chaos that is programming? You’ll never believe the answer: nothing and crashing.

Never was proposed as a replacement for the @noreturn attribute in SE-0102: “Remove @noreturn attribute and introduce an empty Never type”, by Joe Groff.

Prior to Swift 3, functions that stop execution, like fatalError(_:file:line:), abort(), and exit(_:), were annotated with the @noreturn attribute, which told the compiler that there was no return to the caller site.

// Swift < 3.0@noreturnfuncfatalError(_message:()->String=String(),file:StaticString=#file,line:UInt=#line)

After the change, fatalError and its trapping cohorts were declared to return the Never type:

// Swift >= 3.0funcfatalError(_message:@autoclosure()->String=String(),file:StaticString=#file,line:UInt=#line)->Never

For a type to replace the functionality an annotation, it must be pretty complex, right? Nope! Actually, just the opposite — Never is arguably the simplest type in the entire Swift standard library:

enumNever{}

Uninhabited Types

Never is an uninhabited type, which means that it has no values. Or to put it another way, uninhabited types can’t be constructed.

Enumerations with no cases are the most common example of an uninhabited type in Swift. Unlike structures or classes, enumerations don’t receive an initializer. And unlike protocols, enumerations are concrete types that can have properties, methods, generic constraints, and nested types. Because of this, uninhabited enumeration types are used in the Swift standard library to namespace functionality and reason about generics in a clever way.

But Never isn’t like that. It doesn’t have any fancy bells or whistles. It’s special by virtue of it being what it is (or rather, isn’t).

Consider a function declared to return an uninhabited type: Because uninhabited types don’t have any values, the function can’t return normally. Instead, the function must either stop execution or run indefinitely.

Eliminating Impossible States in Generic Types

Sure, this is interesting from a theoretical perspective, but what practical use does Never have for us?

Not much — or at least not before the acceptance SE-0215: Conform Never to Equatable and Hashable.

In his proposal, Matt Diephouse explains the motivation behind conforming this obscure type to Equatable and other protocols this way:

Never is very useful for representing impossible code. Most people are familiar with it as the return type of functions like fatalError, but Never is also useful when working with generic classes. For example, a Result type might use Never for its Value to represent something that always errors or use Never for its Error to represent something that never errors.

Swift doesn’t have a standard Result type, but most of them look something like this:

enumResult<Value,Error:Swift.Error>{casesuccess(Value)casefailure(Error)}

Result types are used to encapsulate values and errors produced by functions that execute asynchronously (whereas synchronous functions can use throws to communicate errors).

For example, a function that makes an asynchronous HTTP request might use a Result type to store either a response or an error:

funcfetch(_request:Request,completion:(Result<Response,Error>)->Void){// ...}

When calling that method, you’d switch over result to handle .success and .failure separately:

fetch(request){resultinswitchresult{case.success(letvalue):print("Success: \(value)")case.failure(leterror):print("Failure: \(error)")}}

Now consider a function that’s guaranteed to always return a successful result in its completion handler:

funcalwaysSucceeds(_completion:(Result<String,Never>)->Void){completion(.success("yes!"))}

By specifying Never as the result’s Error type, we’re using the type system to signal that failure is not an option. What’s really cool about this is that Swift is smart enough to know that you don’ need to handle .failure for the switch statement to be exhaustive:

alwaysSucceeds{(result)inswitchresult{case.success(letstring):print(string)}}

You can see this effect played out to its logical extreme in the implementation conforming Never to Comparable:

extensionNever:Comparable{publicstaticfunc<(lhs:Never,rhs:Never)->Bool{switch(lhs,rhs){}}}

Because Never is an uninhabited type, there aren’t any possible values of it. So when we switch over lhs and rhs, Swift understands that there aren’t any missing cases. And since all cases (of which there aren’t any) return Bool, the method compiles without a problem.

Neat!

Never as a Bottom Type

As a corollary, the original Swift Evolution proposal for Never hints at the theoretical usefulness of the type with further enhancement:

An uninhabited type can be seen as a subtype of any other type — if evaluating an expression never produces a value, it doesn’t matter what the type of that expression is. If this were supported by the compiler, it would enable some potentially useful things…

Unwrap or Die

The forced unwrap operator (!) is one of the most controversial parts of Swift. At best, it’s a necessary evil. At worst, it’s a code smell that suggests sloppiness. And without additional information, it can be really tough to tell the difference between the two.

For example, consider the following code that assumes array to not be empty:

letarray:[Int]letfirstIem=array.first!

To avoid force-unwrapping, you could use a guard statement with conditional assignment instead:

letarray:[Int]guardletfirstItem=array.firstelse{fatalError("array cannot be empty")}

In the future, if Never is implemented as a bottom type, it could be used in the right-hand side of nil-coalescing operator expression.

// Future Swift? 🔮letfirstItem=array.first??fatalError("array cannot be empty")

If you’re really motivated to adopt this pattern today, you can manually overload the ?? operator thusly (however…):

func??<T>(lhs:T?,rhs:@autoclosure()->Never)->T{switchlhs{caseletvalue?:returnvaluecasenil:rhs()}}

In the rationale for SE-0217: Introducing the !! “Unwrap or Die” operator to the Swift Standard Library, Joe Groff notes that “[…] We found that overloading [?? for Never] had unacceptable impact on type-checking performance…”. Therefore, it’s recommended that you don’t add this to your codebase.

Expressive Throw

Similarly, if throw is changed from being a statement to an expression that returns Never, you could use throw on the right-hand side of ??:

// Future Swift? 🔮letfirstItem=array.first??throwError.empty

Typed Throws

Looking even further down the road: If the throws keyword in function declarations added support for type constraints, then the Never type could be used to indicate that a function won’t throw (similar to the Result example before):

// Future Swift? 🔮funcneverThrows()throws<Never>{// ...}neverThrows()// `try` unnecessary because it's guaranteed to succeed (perhaps)

Making a claim that something will never be the case can feel like an invitation for the universe to prove otherwise. Whereas modal or doxastic logics allow for face-saving compromise (“it was true at the time, or so I believed!”), temporal logic seems to hold propositions to a higher standard.

Fortunately for us, Swift lives up to this higher standard thanks to the unlikeliest of types, Never.

One of my favorite activities, when I travel, is to listen to people as they pass and try to guess what language they’re speaking. I’d like to think that I’ve gotten pretty good at it over the years (though I rarely get to know if I guessed right).

If I’m lucky, I’ll recognize a word or phrase as a cognate of a language I’m familiar with, and narrow things down from there. Otherwise, I try to build up a phonetic inventory, listening for what kinds of sounds are present. For instance, is the speaker mostly using voiced alveolar trills ⟨r⟩, flaps ⟨ɾ⟩, or postalveolar approximants ⟨ɹ⟩? Are the vowels mostly open / close; front / back? Any unusual sounds, like ⟨ʇ⟩?

…or at least that’s what I think I do. To be honest, all of this happens unconsciously and automatically – for all of us, and for all manner of language recognition tasks. And have only the faintest idea of how we get from input to output.

Computers operate in a similar manner. After many hours of training, machine learning models can predict the language of text with accuracy far exceeding previous attempts from a formalized top-down approach.

Machine learning has been at the heart of natural language processing in Apple platforms for many years, but it’s only recently that external developers have been able to harness it directly.

New in iOS 12 and macOS 10.14, the Natural Language framework refines existing linguistic APIs and exposes new functionality to developers.

NLTagger is NSLinguisticTagger with a new attitude. NLTokenizer is a replacement for enumerateSubstrings(in:options:using:) (neé CFStringTokenizer). NLLanguageRecognizer offers an extension of the functionality previously exposted through the dominantLanguage in NSLinguisticTagger, with the ability to provide hints and get additional predictions.

Recognizing the Language of Natural Language Text

Here’s how to use NLLanguageRecognizer to guess the dominant language of natural language text:

importNaturalLanguageletstring="""私はガラスを食べられます。それは私を傷つけません。
          """letrecognizer=NLLanguageRecognizer()recognizer.processString(string)recognizer.dominantLanguage// ja

First, create an instance of NLLanguageRecognizer and call the method processString(_:) passing a string. From there, the dominantLanguage property returns an NLLanguage object containing the BCP-47 language tag of the predicted language (for example "ja" for 日本語 / Japanese).

Getting Multiple Language Hypotheses

If you studied linguistics in college or joined the Latin club in high school, you may be familiar with some fun examples of polylingual homonymy between dialectic Latin and modern Italian.

For example, consider the readings of the following sentence:

CANE NERO MAGNA BELLA PERSICA!

To the chagrin of Max Fisher, Latin isn’t one of the languages supported by NLLanguageRecognizer, so any examples of confusable languages won’t be nearly as entertaining.

With some experimentation, you’ll find that it’s quite difficult to get NLLanguageRecognizer to guess incorrectly, or even with low precision. Beyond giving it a single cognate shared across members of a language family, it’s often able to get past 2σ to 95% certainty with a handful of words.

After some trial and error, we were finally able to get NLLanguageRecognizer to guess incorrectly for a string of non-trivial length by passing the Article I of the Universal Declaration of Human Rights in Norsk, Bokmål:

letstring="""
          Alle mennesker er født frie og med samme menneskeverd og menneskerettigheter.
          De er utstyrt med fornuft og samvittighet og bør handle mot hverandre i brorskapets ånd.
          """letlanguageRecognizer=NLLanguageRecognizer()languageRecognizer.processString(string)recognizer.dominantLanguage// da (!)

The Universal Declaration of Human Rights, is the among the most widely-translated documents in the world, with translations in over 500 different languages. For this reason, it’s often used for natural language tasks.

Danish and Norwegian Bokmål are very similar languages to begin with, so it’s unsurprising that NLLanguageRecognizer guessed incorrectly. (For comparison, here’s the equivalent text in Danish)

We can use the languageHypotheses(withMaximum:) method to get a sense of how confident the dominantLanguage guess was:

languageRecognizer.languageHypotheses(withMaximum:2)

At the time of writing, the languageHints property is undocumented, so it’s unclear how exactly it should be used. However, passing a weighted dictionary of probabilities seems to have the desired effect of bolstering the hypotheses with known priors:

languageRecognizer.languageHints=[.danish:0.25,.norwegian:0.75]

So what can you do once you know the language of a string?

Here are a couple of use cases for your consideration:

Checking Misspelled Words

Combine NLLanguageRecognizer with UITextChecker to check the spelling of words in any string:

Start by creating an NLLanguageRecognizer and initializing it with a string by calling the processString(_:) method:

letstring="""
          Wenn ist das Nunstück git und Slotermeyer?
          Ja! Beiherhund das Oder die Flipperwaldt gersput!
          """letlanguageRecognizer=NLLanguageRecognizer()languageRecognizer.processString(string)letdominantLanguage=languageRecognizer.dominantLanguage!// de

Then, pass the rawValue of the NLLanguage object returned by the dominantLanguage property to the language parameter of rangeOfMisspelledWord(in:range:startingAt:wrap:language:):

lettextChecker=UITextChecker()letnsString=NSString(string:string)letstringRange=NSRange(location:0,length:nsString.length)varoffset=0repeat{letwordRange=textChecker.rangeOfMisspelledWord(in:string,range:stringRange,startingAt:offset,wrap:false,language:dominantLanguage.rawValue)guardwordRange.location!=NSNotFoundelse{break}print(nsString.substring(with:wordRange))offset=wordRange.upperBound}whiletrue

When passed the The Funniest Joke in the World, the following words are called out for being misspelled:

• Nunstück
• Slotermeyer
• Beiherhund
• Flipperwaldt
• gersput

Synthesizing Speech

You can use NLLanguageRecognizer in concert with AVSpeechSynthesizer to hear any natural language text read aloud:

letstring="""
          Je m'baladais sur l'avenue le cœur ouvert à l'inconnu
          J'avais envie de dire bonjour à n'importe qui.
          N'importe qui et ce fut toi, je t'ai dit n'importe quoi
          Il suffisait de te parler, pour t'apprivoiser.
          """letlanguageRecognizer=NLLanguageRecognizer()languageRecognizer.processString(string)letlanguage=languageRecognizer.dominantLanguage!.rawValue// frletspeechSynthesizer=AVSpeechSynthesizer()letutterance=AVSpeechUtterance(string:string)utterance.voice=AVSpeechSynthesisVoice(language:language)speechSynthesizer.speak(utterance)

It doesn’t have the lyrical finesse of Joe Dassin, but ainsi va la vie.

In order to be understood, we first must seek to understand. And the first step to understanding natural language is to determine its language.

NLLanguageRecognizer offers a powerful new interface to functionality that’s been responsible for intelligent features throughout iOS and macOS. See how you might take advantage of it in your app to gain new understanding of your users.

When you make a Genius Bar reservation at an Apple Store, you’re instructed to show up at a particular time of day and check in with the concierge. After directing you to pull up a stool, the concierge adds you to the queue and makes a note about how to identify you.

According to anonymous reports from former retail employees, there are strict guidelines about how customers can be described. Nothing about their physical appearance is used: age, gender, ethnicity, height — not even hair color. Instead, all customers are described by their clothing, as in “Person with black turtleneck, jeans, and glasses”.

This practice of describing customers has a lot in common with a hashing function in programming. Like any good hashing function, it’s consistent and easy to compute, and can be used to quickly find what (or who) you’re looking for. Much better than a queue, I think you’ll agree!

Our topic this week is Hashable and its new related type, Hasher. Together, they comprise the functionality underlying two of Swift’s most beloved collection classes: Dictionary and Set

Let’s say you have a list of objects that can be compared for equality with one another. To find a particular object in that list, you iterate all the elements until you find a match As you add more elements to the array, the average amount of time necessary to find any one of them increases linearly (O(n)).

If you instead store those objects in a set, you can theoretically find any one of them in constant time (O(1)) — that is, a lookup on a set with 10 elements takes the same amount of time as a lookup on a set with 10,000^*. How does this work? Instead of storing objects sequentially, a set computes a hash as an index based on the contents of the object. When you perform a lookup of an object in a set, you use the same function to compute a new hash and look for the object there.

^* Two objects produce a hash collision when they have the same hash value but aren’t equal. When a collision occurs on insertion, they’re stored in a list at that address. The higher the rate of collision between objects, the more linear the performance of a hash collection becomes.

Hashable

In Swift, Array provides the standard interface for lists and Set for sets. In order for an object to be stored in a Set, its type must conform to Hashable (and by extension, Equatable). Swift’s standard map interface, Dictionary has a similar constraint on its associated Key type.

In previous versions of the language, it took quite a bit of boilerplate code to satisfy the requirements for storing a custom type in a Set or Dictionary.

Consider the following Color type, which represents a color using 8-bit values for red, green, and blue intensity:

structColor{letred:UInt8letgreen:UInt8letblue:UInt8}

To conform to Equatable, had to provide an implementation for the == operator. To conform to Hashable, had to provide an implementation of the computed hashValue property:

// Swift < 4.1extensionColor:Equatable{staticfunc==(lhs:Color,rhs:Color)->Bool{returnlhs.red==rhs.red&&lhs.green==rhs.green&&lhs.blue==rhs.blue}}extensionColor:Hashable{varhashValue:Int{returnself.red.hashValue^self.green.hashValue^self.blue.hashValue}}

For most developers, implementing Hashable was a speed bump on the way to getting real work done, so they’d simply XOR over all the stored properties and call it a day.

One downside to this approach is its high rate of hash collisions. Because XOR is commutative, colors as different as cyan and yellow produce a hash collision:

// Swift < 4.2letcyan=Color(red:0x00,green:0xFF,blue:0xFF)letyellow=Color(red:0xFF,green:0xFF,blue:0x00)cyan.hashValue==yellow.hashValue// false, no collision

Most of the time, this isn’t a problem; modern computers are so powerful that you have to get a lot of implementation details wrong in order to notice any decrease in performance.

But that’s not to say that details don’t matter — they often matter immensely. More on that later.

Automatic Synthesis of Hashable Conformance

As of Swift 4.1, the compiler automatically synthesizes conformance to the Equatable and Hashable protocols for types that adopt these protocols in their declaration if their members also conform to those protocols.

In addition to being a huge boost to developer productivity, this can drastically reduce the size of a codebase. For instance, our Color example from before — now ⅓ of its original size:

// Swift >= 4.1structColor:Hashable{letred:UInt8letgreen:UInt8letblue:UInt8}

Despite these unambiguous improvements to the language, there was still a lingering question about some of the implementation details.

In his Swift Evolution proposal SE-0185: Synthesizing Equatable and Hashable conformance, Tony Allevato offered this note about hashing functions:

The choice of hash function is left as an implementation detail, not a fixed part of the design; as such, users should not depend on specific characteristics of its behavior. The most likely implementation would call the standard library’s _mixInt function on each member’s hash value and then combine them with exclusive-or (^), which mirrors the way Collection types are hashed today.

Fortunately, it didn’t take long for Swift to settle on a hash function. We got our answer in the very next release:

Hasher

Swift 4.2 refines Hashable even further by introducing the Hasher type and adopting a new universal hashing function.

From the Swift Evolution proposal, SE-0206: Hashable Enhancements:

With a good hash function, simple lookups, insertions and removals take constant time on average. However, when the hash function isn’t carefully chosen to suit the data, the expected time of such operations can become proportional to the number of elements stored in the table.

As Karoy Lorentey and Vincent Esche note, the main draw of hash-based collections like Set and Dictionary is their ability to look up values in constant time. If the hash function doesn’t produce an even distribution of values, these collections effectively become linked lists.

Swift 4.2 implements hashing based on the SipHash family of pseudorandom functions, specifically SipHash-1-3 and SipHash-2-4, with 1 or 2 rounds of hashing per message block and 3 or 4 rounds of finalization, respectively.

Now if you want to customize how your type implements Hashable, you can override the hash(into:) method instead of hashValue. The hash(into:) method passes a Hasher object by reference, which you call combine(_:) on to add the essential state information of your type.

// Swift >= 4.2structColor:Hashable{letred:UInt8letgreen:UInt8letblue:UInt8// Synthesized by compilerfunchash(intohasher:inoutHasher){hasher.combine(self.red)hasher.combine(self.green)hasher.combine(self.blue)}// Default implementation from protocol extensionvarhashValue:Int{varhasher=Hasher()self.hash(into:&hasher)returnhasher.finalize()}}

By abstracting away low-level bit manipulation details, developers automatically take advantage of Swift’s built-in hashing function, which has the extra benefit of not reproducing the collisions we had with our original XOR-based implementation:

// Swift >= 4.2letcyan=Color(red:0x00,green:0xFF,blue:0xFF)letyellow=Color(red:0xFF,green:0xFF,blue:0x00)cyan.hashValue==yellow.hashValue// false, no collision

Customizing Hash Function

By default, Swift uses a universal hash function that reduces a sequence of bytes to a single integer.

However, you can improve on this by tailoring your hash function to your domain. For example, if you were writing a program to play a board game like chess or go, you might implement Zobrist hashing to quickly store the game state.

Guarding Against Hash-Flooding

Selecting a cryptographic algorithm like SipHash helps protect against hash-flooding DoS attacks, which deliberately try to generate hash collisions in an attempt to enforce the worst case of hashing data structures and cause a program to slow to a halt. This caused a bunch of problems for the web in the early 2010’s.

To make things even safer, Hasher generates random seed values each time an app is launched, to make hash values even less predictable.

You shouldn’t rely on specific hash values or save them across executions. On the rare occasion that you would need deterministic behavior, you can set the flag SWIFT_DETERMINISTIC_HASHING to disable random hash seeds,. You shouldn’t depend on consistent values, but you may want this to be deterministic for testing purposes.

The challenge of programming analogies is they normalize antisocial behavior by way of edge cases.

We excel as software engineers when they can think through all the ways that an attacker might leverage a particular behavior to some sinister end — as in the case of hash-flooding DoS attacks. But by doing so, we risk failing as humans when we apply that knowledge AFK.

That is to say… I’m not in any way encouraging you, dear reader, to coordinate outfits with your besties the next time you visit your local Apple retailer in an attempt to sow confusion and discord among Geniuses.

Please don’t.

Instead, please let your takeaway be this:

If you’re waiting at the Genius Bar, stay away from anyone wearing the same color shirt as you. It’ll make things a lot easier for everyone.

By the 1930’s, Rube Goldberg had become a household name, synonymous with the fantastically complicated and whimsical inventions depicted in comic strips like “Self-Operating Napkin.” Around the same time, Albert Einstein popularized the phrase “spooky action at a distance” in his critique of the prevailing interpretation of quantum mechanics by Niels Bohr.

Nearly a century later, modern software development has become what might be seen as the quintessence of a Goldbergian contraption — sprawling ever closer into that spooky realm by way of quantum computers.

As software developers, we’re encouraged to reduce action-at-a-distance in our code whenever possible. This is codified in impressive-sounding guidelines like the Single Responsibility Principle, Principle of Least Astonishment, and Law of Demeter. Yet despite their misgivings about code that produces side effects, there are sometimes occasions where such techniques may clarify rather than confound.

Such is the focus of this week’s article about property observers in Swift, which offer a built-in, lightweight alternative to more formalized solutions like model-view-viewmodel (MVVM) functional reactive programming (FRP).

There are two kinds of properties in Swift: stored properties, which associate state with an object, and computed properties, which perform a calculation based on that state. For example,

structS{// Stored Propertyvarstored:String="stored"// Computed Propertyvarcomputed:String{return"computed"}}

When you declare a stored property, you have the option to define property observers with blocks of code to be executed when a property is set. The willSet observer runs before the new value is stored and the didSet observer runs after. And they run regardless of whether the old value is equal to the new value.

structS{varstored:String{willSet{print("willSet was called")print("stored is now equal to \(self.stored)")print("stored will be set to \(newValue)")}didSet{print("stored is now equal to \(self.stored)")print("stored was previously set to \(oldValue)")}}}

For example, running the following code prints the resulting text to the console:

vars=S(stored:"first")s.stored="second"

• willSet was called
• stored is now equal to first
• stored will be set to second
• didSet was called
• stored is now equal to second
• stored was previously set to first

An important caveat is that observers don’t run when you set a property in an initializer. As of Swift 4.2, you can work around that by wrapping the setter call in a defer block, but that’s a bug that will soon be fixed, so you shouldn’t depend on this behavior.

Swift property observers have been part of the language from the very beginning. To better understand why, let’s take a quick look at how things work in Objective-C:

Properties in Objective-C

In Objective-C, all properties are, in a sense, computed. Each time a property is accessed through dot notation, the call is translated into an equivalent getter or setter method invocation. This, in turn, is compiled into a message send that executes a function that reads or writes an instance variable.

// Dot accessorperson.name=@"Johnny";// ...is equivalent to[personsetName:@"Johnny"];// ...which gets compiled toobjc_msgSend(person,@selector(setName:),@"Johnny");// ...whose synthesized implementation yieldsperson->_name=@"Johnny";

Side effects are something you generally want to avoid in programming because they make it difficult to reason about program behavior. But many Objective-C developers had come to rely on the ability to inject additional behavior into getter or setter methods as needed.

Swift’s design for properties formalized these patterns and created a distinction between side effects that decorate state access (stored properties) and those that redirect state access (computed properties). For stored properties, the willSet and didSet observers replace the code that you’d otherwise include alongside ivar access. For computed properties, the get and set accessors replace code that you might implement for @dynamic properties in Objective-C.

As a result, we get more consistent semantics and better guarantees about mechanisms like Key-Value Observing (KVO) and Key-Value Coding (KVC) that interact with properties.

So what can you do with property observers in Swift? Here are a couple ideas for your consideration:

Validating / Normalizing Values