Strings are a ubiquitous and diverse part of our computing lives. They comprise emails and essays, poems and novels—and indeed, every article on nshipster.com, the configuration files that shape the site, and the code that builds it.

Being able to pull apart strings and extract particular bits of data is therefore a powerful skill, one that we use over and over building apps and shaping our tools. Cocoa provides a powerful set of tools to handle string processing. In particular:

• string.componentsSeparatedByCharactersInSet / string.componentsSeparatedByString: Great for splitting a string into constituent pieces. Not so great at anything else.

• NSRegularExpression: Powerful for validating and extracting string data from an expected format. Cumbersome when dealing with complex serial input and finicky for parsing numeric values.

• NSDataDetector: Perfect for detecting and extracting dates, addresses, links, and more. Limited to its predefined types.

• NSScanner: Highly configurable and designed for scanning string and numeric values from loosely demarcated strings.

This week's article focuses on the last of these, NSScanner. Read on to learn about its flexibility and power.

Among Cocoa's tools, NSScanner serves as a wrapper around a string, scanning through its contents to efficiently retrieve substrings and numeric values. It offers several properties that modify an NSScanner instance's behavior:

• caseSensitiveBool: Whether to pay attention to the upper- or lower-case while scanning. Note that this property only applies to the string-matching methods scanString:intoString: and scanUpToString:intoString:—character sets scanning is always case-sensitive.
• charactersToBeSkippedNSCharacterSet: The characters to skip over on the way to finding a match for the requested value type.
• scanLocationInt: The current position of the scanner in its string. Scanning can be rewound or restarted by setting this property.
• localeNSLocale: The locale that the scanner should use when parsing numeric values (see below).

An NSScanner instance has two additional read-only properties: string, which gives you back the string the scanner is scanning; and atEnd, which is true if scanLocation is at the end of the string.

Note:NSScanner is actually the abstract superclass of a private cluster of scanner implementation classes. Even though you're calling alloc and init on NSScanner, you'll actually receive one of these subclasses, such as NSConcreteScanner. No need to fret over this.

Extracting Substring and Numeric Values

The raison d'être of NSScanner is to pull substring and numeric values from a larger string. It has fifteen methods to do this, all of which follow the same basic pattern. Each method takes a reference to an output variable as a paramter and returns a boolean value indicating success or failure of the scan:

letstringScanner=NSScanner(string:"John & Paul & Ringo & George.")stringScanner.charactersToBeSkipped=whitespaceAndPunctuationSetvarname:NSString?whilestringScanner.scanUpToCharactersFromSet(whitespaceAndPunctuationSet,intoString:&name),letname=name{println(name)}// John// Paul// Ringo// George

NSScanner*stringScanner=[[NSScanneralloc]initWithString:@"John & Paul & Ringo & George."];stringScanner.charactersToBeSkipped=whitespaceAndPunctuationSet;NSString*name;while([stringScannerscanUpToCharactersFromSet:whitespaceAndPunctuationSetintoString:&name]){NSLog(@"%@",name);}// John// Paul// Ringo// George

There are two

1) String Scanners

scanString:intoString: / scanCharactersFromSet:intoString:

Scans to match the string parameter or characters in the NSCharacterSet parameter, respectively. The intoString parameter will return containing the scanned string, if found. These methods are often used to advance the scanner's location—pass nil for the intoString parameter to ignore the output.

scanUpToString:intoString: / scanUpToCharactersFromSet:intoString:

Scans characters into a string until finding the string parameter or characters in the NSCharacterSet parameter, respectively. The intoString parameter will return containing the scanned string, if any was found. If the given string or character set are not found, the result will be the entire rest of the scanner's string.

2) Numeric Scanners

scanDouble: / scanFloat: / scanDecimal:

Scans a floating-point value from the scanner's string and returns the value in the referenced Double, Float, or NSDecimal instance, if found.

scanInteger: / scanInt: / scanLongLong: / scanUnsignedLongLong:

Scans an integer value from the scanner's string and returns the value in the referenced Int, Int32, Int64, or UInt64 instance, if found.

scanHexDouble: / scanHexFloat:

Scans a hexadecimal floating-point value from the scanner's string and returns the value in the referenced Double or Float instance, if found. To scan properly, the floating-point value must have a 0x or 0X prefix.

scanHexInt: / scanHexLongLong:

Scans a hexadecimal integer value from the scanner's string and returns the value in the referenced UInt32 or UInt64 instance, if found. The value may have a 0x or 0X prefix, but it is not required.

localizedScannerWithString / locale

Because it is a part of Cocoa, NSScanner has built-in localization support (of course). An NSScanner instance can work with either the user's locale when created via + localizedScannerWithString:, or a specific locale after setting its locale property. In particular, the separator for floating-point values will be correctly interpreted based on the given locale:

varprice=0.0letgasPriceScanner=NSScanner(string:"2.09 per gallon")gasPriceScanner.scanDouble(&price)// 2.09// use a german locale instead of the defaultletbenzinPriceScanner=NSScanner(string:"1,38 pro Liter")benzinPriceScanner.locale=NSLocale(localeIdentifier:"de-DE")benzinPriceScanner.scanDouble(&price)// 1.38

doubleprice;NSScanner*gasPriceScanner=[[NSScanneralloc]initWithString:@"2.09 per gallon"];[gasPriceScannerscanDouble:&price];// 2.09// use a german locale instead of the defaultNSScanner*benzinPriceScanner=[[NSScanneralloc]initWithString:@"1,38 pro Liter"];[benzinPriceScannersetLocale:[NSLocalelocaleWithLocaleIdentifier:@"de-DE"]];[benzinPriceScannerscanDouble:&price];// 1.38

Example: Parsing SVG Path Data

To take NSScanner out for a spin, we'll look at parsing the path data from an SVG path. SVG path data are stored as a string of instructions for drawing the path, where "M" indicates a "move-to" step, "L" stands for "line-to", and "C" stands for a curve. Uppercase instructions are followed by points in absolute coordinates; lowercase instructions are followed by coordinates relative to the last point in the path.

Here's an SVG path I happen to have lying around:

varsvgPathData="M28.2,971.4c-10,0.5-19.1,13.3-28.2,2.1c0,15.1,23.7,30.5,39.8,16.3c16,14.1,39.8-1.3,39.8-16.3c-12.5,15.4-25-14.4-39.8,4.5C35.8,972.7,31.9,971.2,28.2,971.4z"

Note that the point data are fairly irregular. Sometimes the x and y values of a point are separated by a comma, sometimes not, and likewise with points themselves. Parsing these data with regular expressions could turn into a mess pretty quickly, but with NSScanner the code is clear and straightforward.

We'll define a bezierPathFromData function that will convert a string of path data into an UIBezierPath. Our scanner is set up to skip commas and whitespace while scanning for values:

funcbezierPathFromData(str:String)->UIBezierPath{letscanner=NSScanner(string:str)// skip commas and whitespaceletskipChars=NSMutableCharacterSet(charactersInString:",")skipChars.formUnionWithCharacterSet(NSCharacterSet.whitespaceAndNewlineCharacterSet())scanner.charactersToBeSkipped=skipChars// the resulting bezier pathvarpath=UIBezierPath()

With the setup out of the way, it's time to start scanning. We start by scanning for a string made up characters in the allowed set of instructions:

// instructions code can be upper- or lower-caseletinstructionSet=NSCharacterSet(charactersInString:"MCSQTAmcsqta")varinstruction:NSString?// scan for an instruction codewhilescanner.scanCharactersFromSet(instructionSet,intoString:&instruction){

The next section scans for two Double values in a row, converts them to a CGPoint, and then ultimately adds the correct step to the bezier path:

varx=0.0,y=0.0varpoints:[CGPoint]=[]// scan for pairs of Double, adding them as CGPoints to the points arraywhilescanner.scanDouble(&x)&&scanner.scanDouble(&y){points.append(CGPoint(x:x,y:y))}// new point for bezier pathswitchinstruction??""{case"M":path.moveToPoint(points[0])case"C":path.addCurveToPoint(points[2],controlPoint1:points[0],controlPoint2:points[1])case"c":path.addCurveToPoint(path.currentPoint.offset(points[2]),controlPoint1:path.currentPoint.offset(points[0]),controlPoint2:path.currentPoint.offset(points[1]))default:break}}returnpath}

Lo and behold, the result:

The required flipping, resizing, waxing, and twirling are left as an exercise for the reader.

Swift-Friendly Scanning

As a last note, working with NSScanner in Swift can feel almost silly. Really, NSScanner, I need to pass in a pointer just so you can return a Bool? I can't use optionals, which are pretty much designed for this exact purpose? Really?

With a simple extension converting the built-in methods to ones returning optional values, scanning becomes far more in sync with Swift's idiom. Our path data scanning example can now use optional binding instead of inout variables for a cleaner, easier-to-read implementation:

// look for an instruction codewhileletinstruction=scanner.scanCharactersFromSet(instructionSet){varpoints:[CGPoint]=[]// scan for pairs of Double, adding them as CGPoints to the points arraywhileletx=scanner.scanDouble(),y=scanner.scanDouble(){points.append(CGPoint(x:x,y:y))}// new point for bezier pathswitchinstruction{// ...}}

You've gotta have the right tools for every job. NSScanner can be the shiny tool to reach for when it's time to parse a user's input or a web service's data. Being able to distinguish which tools are right for which tasks helps us on our way to creating clear and accurate code.

Dates. More than any other data type, the gulf between the initial banality of dates and their true, multifaceted complexity looms terrifyingly large. Combining sub-second precision, overlapping units, geopolitical time zone boundaries, localization differences in both language and grammar, and Daylight Saving shifts and leap year adjustments that literally add and remove whole chunks of time from measured existence, there's a lot to process.

To embark on any date-heavy task, then, requires a solid understanding of the tools already at your fingertips. Better to use a Foundation method than to write the n-thousandth version of dateIsTomorrow. Are you using NSDateComponents? Did you specify all the right calendar units? Will your code still work correctly on February 28, 2100?

But here's the thing: the APIs you're already using have been holding out on you. Unless you're digging through release notes and API diffs, you wouldn't know that over the last few releases of OS X, NSCalendar has quietly built a powerful set of methods for accessing and manipulating dates, and that the latest release brought them all to iOS.

letcalendar=NSCalendar.currentCalendar()

NSCalendar*calendar=[NSCalendarcurrentCalendar];

From new ways of accessing individual date components and flexibly comparing dates to powerful date interpolation and enumeration methods, there's far too much to ignore. Make some room in your calendar and read on for more.

Convenient Component Access

Oh, NSDateComponents. So practical and flexible, yet so cumbersome when I just. Want to know. What the hour is. NSCalendar to the rescue!

lethour=calendar.component(.CalendarUnitHour,fromDate:NSDate())

NSIntegerhour=[calendarcomponent:NSCalendarUnitHourfromDate:[NSDatedate]];

That's much better. NSCalendar, what else can you do?

• getEra(_:year:month:day:fromDate:): Returns the era, year, month, and day of the given date by reference. Pass nil/NULL for any parameters you don't need.
• getEra(_:yearForWeekOfYear:weekOfYear:weekday:fromDate:): Returns the era, year (for week of year), week of year, and weekday of the given date by reference. Pass nil/NULL for any parameters you don't need.
• getHour(_:minute:second:nanosecond:fromDate:): Returns time information for the given date by reference. nil/NULL, you get the idea.

And just kidding, NSDateComponents, I take it all back. There are a couple methods for you, too:

• componentsInTimeZone(_:fromDate:): Returns an NSDateComponents instance with components of the given date shifted to the given time zone.
• components(_:fromDateComponents:toDateComponents:options:): Returns the difference between two NSDateComponents instances. The method will use base values for any components that are not set, so provide at the least the year for each parameter. The options parameter is unused; pass nil/0.

Date Comparison

While direct NSDate comparison has always been a simple matter, more meaningful comparisons can get surprisingly complex. Do two NSDate instances fall on the same day? In the same hour? In the same week?

Fret no more, NSCalendar has you covered with an extensive set of comparison methods:

• isDateInToday(_:): Returns true if the given date is today.
• isDateInTomorrow(_:): Returns true if the given date is tomorrow.
• isDateInYesterday(_:): Returns true if the given date is a part of yesterday.
• isDateInWeekend(_:): Returns true if the given date is part of a weekend, as defined by the calendar.
• isDate(_:inSameDayAsDate:): Returns true if the two NSDate instances are on the same day—delving into date components is unnecessary.
• isDate(_:equalToDate:toUnitGranularity:): Returns true if the dates are identical down to the given unit of granularity. That is, two date instances in the same week would return true if used with calendar.isDate(tuesday, equalToDate: thursday, toUnitGranularity: .CalendarUnitWeekOfYear), even if they fall in different months.
• compareDate(_:toDate:toUnitGranularity:): Returns an NSComparisonResult, treating as equal any dates that are identical down to the given unit of granularity.
• date(_:matchesComponents:): Returns true if a date matches the specific components given.

Date Interpolation

Next up is a set of methods that allows you to find the next date(s) based on a starting point. You can find the next (or previous) date based on an NSDateComponents instance, an individual date component, or a specific hour, minute, and second. Each of these methods takes an NSCalendarOptions bitmask parameter that provides fine-grained control over how the next date is selected, particularly in cases where an exact match isn't found at first.

NSCalendarOptions

The easiest option of NSCalendarOptions is .SearchBackwards, which reverses the direction of each search, for all methods. Backward searches are constructed to return dates similar to forward searches. For example, searching backwards for the previous date with an hour of 11 would give you 11:00, not 11:59, even though 11:59 would technically come "before" 11:00 in a backwards search. Indeed, backward searching is intuitive until you think about it and then unintuitive until you think about it a lot more. That .SearchBackwards is the easy part should give you some idea of what's ahead.

The remainder of the options in NSCalendarOptions help deal with "missing" time instances. Time can be missing most obviously if one searches in the short window when time leaps an hour forward during a Daylight Saving adjustment, but this behavior can also come into play when searching for dates that don't quite add up, such as the 31st of February or April.

When encountering missing time, if NSCalendarOptions.MatchStrictly is provided, the methods will continue searching to find an exact match for all components given, even if that means skipping past higher order components. Without strict matching invoked, one of .MatchNextTime, .MatchNextTimePreservingSmallerUnits, and .MatchPreviousTimePreservingSmallerUnits must be provided. These options determine how a missing instance of time will be adjusted to compensate for the components in your request.

In this case, an example will be worth a thousand words:

// begin with Valentine's Day, 2015 at 9:00amletvalentines=cal.dateWithEra(1,year:2015,month:2,day:14,hour:9,minute:0,second:0,nanosecond:0)!// to find the last day of the month, we'll set up a date components instance with // `day` set to 31:letcomponents=NSDateComponents()components.day=31

NSDate*valentines=[calendardateWithEra:1year:2015month:2day:14hour:9minute:0second:0nanosecond:0];NSDateComponents*components=[[NSDateComponentsalloc]init];components.day=31;

Using strict matching will find the next day that matches 31, skipping into March to do so:

calendar.nextDateAfterDate(valentines,matchingComponents:components,options:.MatchStrictly)// Mar 31, 2015, 12:00 AM

NSDate*date=[calendarnextDateAfterDate:valentinesmatchingComponents:componentsoptions:NSCalendarMatchStrictly];// Mar 31, 2015, 12:00 AM

Without strict matching, nextDateAfterDate will stop when it hits the end of February before finding a match—recall that the highest unit specified was the day, so the search will only continue within the next highest unit, the month. At that point, the option you've provided will determine the returned date. For example, using .MatchNextTime will pick the next possible day:

calendar.nextDateAfterDate(valentines,matchingComponents:components,options:.MatchNextTime)// Mar 1, 2015, 12:00 AM

date=[calendarnextDateAfterDate:valentinesmatchingComponents:componentsoptions:NSCalendarMatchNextTime];// Mar 1, 2015, 12:00 AM

Similarly, using .MatchNextTimePreservingSmallerUnits will pick the next day, but will also preserve all the units smaller than the given NSCalendarUnitDay:

calendar.nextDateAfterDate(valentines,matchingComponents:components,options:.MatchNextTimePreservingSmallerUnits)// Mar 1, 2015, 9:00 AM

date=[calendarnextDateAfterDate:valentinesmatchingComponents:componentsoptions:NSCalendarMatchNextTimePreservingSmallerUnits];// Mar 1, 2015, 9:00 AM

And finally, using .MatchPreviousTimePreservingSmallerUnits will resolve the missing date by going the other direction, choosing the first possible previous day, again preserving the smaller units:

calendar.nextDateAfterDate(valentines,matchingComponents:components,options:.MatchPreviousTimePreservingSmallerUnits)// Feb 28, 2015, 9:00 AM

date=[calendarnextDateAfterDate:valentinesmatchingComponents:componentsoptions:NSCalendarMatchPreviousTimePreservingSmallerUnits];// Feb 28, 2015, 9:00 AM

Besides the NDateComponents version shown here, it's worth noting that nextDateAfterDate has two other variations:

// matching a particular calendar unitcal.nextDateAfterDate(valentines,matchingUnit:.CalendarUnitDay,value:31,options:.MatchStrictly)// March 31, 2015, 12:00 AM// matching an hour, minute, and secondcal.nextDateAfterDate(valentines,matchingHour:15,minute:30,second:0,options:.MatchNextTime)// Feb 14, 2015, 3:30 PM

// matching a particular calendar unitdate=[calendarnextDateAfterDate:valentinesmatchingUnit:NSCalendarUnitDayvalue:31options:NSCalendarMatchStrictly];// March 31, 2015, 12:00 AM// matching an hour, minute, and seconddate=[calendarnextDateAfterDate:valentinesmatchingHour:15minute:30second:0options:NSCalendarMatchNextTime];// Feb 14, 2015, 3:30 PM

Enumerating Interpolated Dates

Rather than using nextDateAfterDate iteratively, NSCalendar provides an API for enumerating dates with the same semantics. enumerateDatesStartingAfterDate(_:matchingComponents:options:usingBlock:) computes the dates that match the given set of components and options, calling the provided closure with each date in turn. The closure can set the stop parameter to true, thereby stopping the enumeration.

Putting this new NSCalendarOptions knowledge to use, here's one way to list the last fifty leap days:

letleapYearComponents=NSDateComponents()leapYearComponents.month=2leapYearComponents.day=29vardateCount=0cal.enumerateDatesStartingAfterDate(NSDate(),matchingComponents:leapYearComponents,options:.MatchStrictly|.SearchBackwards){(date:NSDate!,exactMatch:Bool,stop:UnsafeMutablePointer<ObjCBool>)inprintln(date)if++dateCount==50{// .memory gets at the value of an UnsafeMutablePointerstop.memory=true}}// 2012-02-29 05:00:00 +0000// 2008-02-29 05:00:00 +0000// 2004-02-29 05:00:00 +0000// 2000-02-29 05:00:00 +0000// ...

NSDateComponents*leapYearComponents=[[NSDateComponentsalloc]init];leapYearComponents.month=2;leapYearComponents.day=29;__blockintdateCount=0;[calendarenumerateDatesStartingAfterDate:[NSDatedate]matchingComponents:leapYearComponentsoptions:NSCalendarMatchStrictly|NSCalendarSearchBackwardsusingBlock:^(NSDate*date,BOOLexactMatch,BOOL*stop){NSLog(@"%@",date);if(++dateCount==50){*stop=YES;}}];// 2012-02-29 05:00:00 +0000// 2008-02-29 05:00:00 +0000// 2004-02-29 05:00:00 +0000// 2000-02-29 05:00:00 +0000// ...

Working for the Weekend

If you're always looking forward to the weekend, look no further than our final two NSCalendar methods:

• nextWeekendStartDate(_:interval:options:afterDate): Returns the starting date and length of the next weekend by reference via the first two parameters. This method will return false if the current calendar or locale doesn't support weekends. The only relevant option here is .SearchBackwards. (See below for an example.)
• rangeOfWeekendStartDate(_:interval:containingDate): Returns the starting date and length of the weekend containing the given date by reference via the first two parameters. This method returns false if the given date is not in fact on a weekend or if the current calendar or locale doesn't support weekends.

Localized Calendar Symbols

As if all that new functionality wasn't enough, NSCalendar also provides access to a full set of properly localized calendar symbols, making possible quick access to the names of months, days of the week, and more. Each group of symbols is further enumerated along two axes: (1) the length of the symbol and (2) its use as a standalone noun or as part of a date.

Understanding this second attribute is extremely important for localization, since some languages, Slavic languages in particular, use different noun cases for different contexts. For example, a calendar would need to use one of the standaloneMonthSymbols variants for its headers, not the monthSymbols that are used for formatting specific dates.

For your perusal, here's a table of all the symbols that are available in NSCalendar—note the different values for standalone symbols in the Russian column:

Note: These same collections are also available via NSDateFormatter.

Your Weekly Swiftification

It's becoming something of a feature here at NSHipster to close with a slightly Swift-ified version of the discussed API. Even in this brand-new set of NSCalendar APIs, there are some sharp edges to be rounded off, replacing UnsafeMutablePointer parameters with more idiomatic tuple return values.

With a useful set of NSCalendar extensions (gist here), the component accessing and weekend finding methods can be used without in-out variables. For example, getting individual date components from a date is much simpler:

// built-invarhour=0varminute=0calendar.getHour(&hour,minute:&minute,second:nil,nanosecond:nil,fromDate:NSDate())// swiftifiedlet(hour,minute,_,_)=calendar.getTimeFromDate(NSDate())

As is fetching the range of the next weekend:

// built-invarstartDate:NSDate?varinterval:NSTimeInterval=0letsuccess=cal.nextWeekendStartDate(&startDate,interval:&interval,options:nil,afterDate:NSDate())ifsuccess,letstartDate=startDate{println("start: \(startDate), interval: \(interval)")}// swiftifiedifletnextWeekend=cal.nextWeekendAfterDate(NSDate()){println("start: \(nextWeekend.startDate), interval: \(nextWeekend.interval)")}

So take that, complicated calendrical math. With these new additions to NSCalendar, you'll have your problems sorted out in no time.

Debugging can be an exercise in irony. We create programs that tell our pint-sized supercomputers to complete infinitely varied and incalculable tasks on our behalf, yet when trying to understand those same programs, we tell the computers to wait for us.

For example, suppose I'm trying to figure out why the UINavigationBar in my app doesn't appear as I expected. To investigate, I might use the debugger to look at the UIColor instance I'm setting on the navigation bar—what color is this, exactly?

Hold on! No more trying to figure out how those components add together. There's a better way.

Since version 5, Xcode has shipped with Quick Look display in the debugger. Just as you can inspect the contents of a file on the Desktop with a quick tap of the space bar, in Xcode you can use Quick Look to see a visual representation of a variety of datatypes. Tapping the space bar on our color variable gives an instant answer—no off-the-top-of-your-head RGB calculations required:

You can also invoke Quick Look while debugging directly from your code. Consider the following method, buildPathWithRadius(_:steps:loopCount:). It creates a UIBezierPath of some kind, but you've forgotten which, and does this code even work?

funcbuildPathWithRadius(radius:CGFloat,steps:CGFloat,loopCount:CGFloat)->UIBezierPath{letaway=radius/stepsletaround=loopCount/steps*2*CGFloat(M_PI)letpoints=map(stride(from:1,through:steps,by:1)){step->CGPointinletx=cos(step*around)*step*awaylety=sin(step*around)*step*awayreturnCGPoint(x:x,y:y)}letpath=UIBezierPath()path.moveToPoint(CGPoint.zeroPoint)forpointinpoints{path.addLineToPoint(point)}returnpath}

-(UIBezierPath*)buildPathWithRadius:(CGFloat)radiussteps:(CGFloat)stepsloopCount:(CGFloat)loopCount{CGFloatx,y;CGFloataway=radius/steps;CGFloataround=loopCount/steps*2*M_PI;UIBezierPath*path=[UIBezierPathbezierPath];[pathmoveToPoint:CGPointZero];for(inti=1;i<=steps;i++){x=cos(i*around)*i*away;y=sin(i*around)*i*away;[pathaddLineToPoint:CGPointMake(x,y)];}returnpath;}

To see the result, you could surely create a custom view for the bezier path or draw it into a UIImage. But better yet, you could insert a breakpoint at the end of the method and mouse over path:

Spiraltastic!

Built-In Types

Quick Look can be used with most of the datatypes you'll want to visualize right out of the box. Xcode already has you covered for the following types:

• Images:UIImage, NSImage, UIImageView, NSImageView, CIImage, and NSBitmapImageRep are all visible via Quick Look.
• Colors:UIColor and NSColor. (Sorry, CGColor.)
• Strings:NSString and NSAttributedString.
• Geometry:UIBezierPath and NSBezierPath along with CGPoint, CGRect, and CGSize.
• Locations:CLLocation gives a large, interactive view of the mapped location, with details about altitude and accuracy in an overlay.
• URLs:NSURL is represented by a view showing the local or remote content addressed by the URL.
• Cursors:NSCursor, for the cursored among us.
• SpriteKit:SKSpriteNode, SKShapeNode, SKTexture, and SKTextureAtlas are all represented.
• Data:NSData has a great view showing hex and ASCII values with their offset.
• Views: Last but not least, any UIView subclass will display its contents in a Quick Look popup—so convenient.

What's more, these Quick Look popups often include a button that will open the content in a related application. Image data (as well as views, cursors, and SpriteKit types) offer an option to open in Preview. Remote URLs can be opened in Safari; local ones can be opened in the related application. Finally, plain-text and attributed string data can likewise be opened in TextEdit.

Custom Types

For anything beyond these built-in types, Xcode 6 has added Quick Look for custom objects. The implementation couldn't be simpler—add a single debugQuickLookObject() method to any NSObject-derived class, and you're set. debugQuickLookObject() can then return any of the built-in types described above, configured for your custom type's needs:

funcdebugQuickLookObject()->AnyObject{letpath=buildPathWithRadius(radius,steps:steps,loopCount:loopCount)returnpath}

-(id)debugQuickLookObject{UIBezierPath*path=[selfbuildPathWithRadius:self.radiussteps:self.stepsloopCount:self.loopCount];returnpath;}

In sum, Quick Look enables a more direct relationship with the data we manipulate in our code by allowing us to iterate over smaller pieces of functionality. This direct view into previously obfuscated datatypes brings some of the immediacy of a Swift Playground right into our main codebase. Displaying images? Visualizing data? Rendering text? Computers are so good at all that! Let's let them do it from now on.

APIs do more than just exposing functionality to developers. They also communicate values about how the API should be used and why. This communication is what makes naming things one of the Hard Parts of computer science; it's what separates the good APIs from the great.

A reading of Swift's standard library shows a clear demarcation between the safety and reliability that Swift advertises on one side and the tools necessary for Objective-C interoperability on the other. Types with names like Int, String, and Array let you expect straightforward usage and unsurprising behavior, while it's impossible to create an UnsafeMutablePointer or Unmanaged instance without thinking "here be dragons."

Here we take a look at Unmanaged, a wrapper for unclearly-memory-managed objects and the hot-potatoesque way of properly handling them. But to start, let's rewind the clock a bit.

Automatic Reference Counting

Back in the Stone Age (aka 2011), reference counting in Objective-C was still a manual affair. Each reference-retaining operation needed to be balanced with a corresponding release, lest an application's memory take on an air of phantasmagoria, with zombies dangling and memory leaking... Gross. Carefully tending the reference count of one's objects was a constant chore for developers and a major hurdle for newcomers to the platform.

The advent of automatic reference counting (ARC) made all of that manual memory management unnecessary. Under ARC, the compiler inserts the retain/release/autorelease calls for you, reducing the cognitive load of applying the rules at every turn. If this graphic doesn't convince you of the boon of dropping manual memory management, nothing will:

Now, in this post-ARC world, all Objective-C and Core Foundation types returned from Objective-C methods are automatically memory managed, leaving Core Foundation types returned from C functions as the lone holdout. For this last category, management of an object's ownership is still done with calls to CFRetain() and CFRelease() or by bridging to Objective-C objects with one of the __bridge functions.

To help understand whether or not a C function returns objects that are owned by the caller, Apple uses naming conventions defined by the Create Rule and the Get Rule:

• The Create Rule states that a function with Create or Copy in its name returns ownerships to the call of the function. That is to say, the caller of a Create or Copy function will eventually need to call CFRelease on the returned object.

• The Get Rule isn't so much a rule of its own as it is a catch-all for everything that doesn't follow the Create Rule. A function doesn't have Create or Copy in its name? It follows the Get rule instead, returning without transferring ownership. If you want the returned object to persist, in most cases it's up to you to retain it.

If you're a belt-and-suspenders-and-elastic-waistband programmer like I am, check the documentation as well. Even when they follow the proper name convention, most APIs also explicitly state which rule they follow, and any exceptions to the common cases.

Wait—this article is about Swift. Let's get back on track.

Swift uses ARC exclusively, so there's no room for a call to CFRelease or __bridge_retained. How does Swift reconcile this "management-by-convention" philosophy with its guarantees of memory safety?

This occurs in two different ways. For annotated APIs, Swift is able to make the conventions explicit—annotated CoreFoundation APIs are completely memory-managed and provide the same promise of memory safety as do bridged Objective-C or native Swift types. For unannotated APIs, however, Swift passes the job to you, the programmer, through the Unmanaged type.

Managing Unmanaged

While most CoreFoundation APIs have been annotated, some significant chunks have yet to receive attention. As of this writing, the Address Book framework seems the highest profile of the unannotated APIs, with several functions taking or returning Unmanaged-wrapped types.

An Unmanaged<T> instance wraps a CoreFoundation type T, preserving a reference to the underlying object as long as the Unmanaged instance itself is in scope. There are two ways to get a Swift-managed value out of an Unmanaged instance:

• takeRetainedValue(): returns a Swift-managed reference to the wrapped instance, decrementing the reference count while doing so—use with the return value of a Create Rule function.

• takeUnretainedValue(): returns a Swift-managed reference to the wrapped instance without decrementing the reference count—use with the return value of a Get Rule function.

In practice, you're better off not even working with Unmanaged instances directly. Instead, take... the underlying instance immediately from the function's return value and bind that.

Let's take a look at this in practice. Suppose we wish to create an ABAddressBook and fetch the name of the user's best friend:

letbestFriendID=ABRecordID(...)// Create Rule - retainedletaddressBook:ABAddressBook=ABAddressBookCreateWithOptions(nil,nil).takeRetainedValue()iflet// Get Rule - unretainedbestFriendRecord:ABRecord=ABAddressBookGetPersonWithRecordID(addressBook,bestFriendID)?.takeUnretainedValue(),// Create Rule (Copy) - retainedname=ABRecordCopyCompositeName(bestFriendRecord)?.takeRetainedValue()as?String{println("\(name): BFF!")// Rhonda Shorsheimer: BFF!}

With Swift 1.2's improved optional bindings, it's a piece of cake to unwrap, take the underlying value, and cast to a Swift type.

Better Off Without

Now that we've looked at how to work with Unmanaged, let's look at how to get rid of it altogether. If Unmanaged references are returned from calls to your own C functions, you're better off using annotations. Annotations let the compiler know how to automatically memory-manage your return value: instead of an Unmanaged<CFString>, you receive a CFString, which is type-safe and fully memory-managed by Swift.

For example, let's take a function that combines two CFString instances and annotate that function to tell Swift how to memory-manage the resulting string. Following the naming conventions described above, our function will be called CreateJoinedString—that name communicates that the caller will own the returned string.

CFStringRefCreateJoinedString(CFStringRefstring1,CFStringRefstring2);

Sure enough, in the implementation you can see that this creates resultString with CFStringCreateMutableCopy and returns it without a balancing CFRelease:

CFStringRefCreateJoinedString(CFStringRefstring1,CFStringRefstring2){CFMutableStringRefresultString=CFStringCreateMutableCopy(NULL,0,string1);CFStringAppend(resultString,string2);returnresultString;}

In our Swift code, just as above, we still need to manage the memory manually. Our function is imported as returning an Unmanaged<CFString>!:

// imported declaration:funcCreateJoinedString(string1:CFString!,string2:CFString!)->Unmanaged<CFString>!// to call:letjoinedString=CreateJoinedString("First","Second").takeRetainedValue()asString

Since our function follows the naming conventions described in the Create Rule, we can turn on the compiler's implicit bridging to eliminate the Unmanaged wrapper. Core Foundation provides two macros—namely, CF_IMPLICIT_BRIDGING_ENABLED and CF_IMPLICIT_BRIDGING_DISABLED—that turn on and off the Clang arc_cf_code_audited attribute:

CF_IMPLICIT_BRIDGING_ENABLED// get rid of Unmanaged#pragma clang assume_nonnull begin      // also get rid of !sCFStringRefCreateJoinedString(CFStringRefstring1,CFStringRefstring2);#pragma clang assume_nonnull beginCF_IMPLICIT_BRIDGING_DISABLED

Because Swift now handles the memory management for this return value, our code is simpler and skips use of Unmanaged altogether:

// imported declaration:funcCreateJoinedString(string1:CFString,string2:CFString)->CFString// to call:letjoinedString=CreateJoinedString("First","Second")asString

Finally, when your function naming doesn't comply with the Create/Get Rules, there's an obvious fix: rename your function to comply with the Create/Get Rules. Of course, in practice, that's not always an easy fix, but having an API that communicates clearly and consistently pays dividends beyond just avoiding Unmanaged. If renaming isn't an option, there are two other annotations to use: functions that pass ownership to the caller should use CF_RETURNS_RETAINED, while those that don't should use CF_RETURNS_NOT_RETAINED. For instance, the poorly-named MakeJoinedString is shown here with manual annotations:

CF_RETURNS_RETAINED__nonnullCFStringRefMakeJoinedString(__nonnullCFStringRefstring1,__nonnullCFStringRefstring2);

One gets that feeling that Unmanaged is a stopgap measure—that is, a way to use CoreFoundation while the work of annotating the mammoth API is still in progress. As functions are revised to interoperate more cleanly, each successive Xcode release may allow you to strip takeRetainedValue() calls from your codebase. Yet until the sun sets on the last CFUnannotatedFunctionRef, Unmanaged will be there to help you bridge the gap.

Code structure and organization is a matter of pride for developers. Clear and consistent code signifies clear and consistent thought. Even though the compiler lacks a discerning palate when it comes to naming, whitespace, or documentation, it makes all of the difference for human collaborators.

Readers of NSHipster will no doubt remember the article about documentation published last year, but a lot has changed with Xcode 6 (fortunately, for the better, in most cases). So this week, we'll be documenting the here and now of documentation for aspiring Swift developers.

Let's dive in.

Since the early 00's, Headerdoc has been the documentation standard preferred by Apple. Starting off as little more than a Perl script parsing trumped-up Javadoc comments, Headerdoc would eventually be the engine behind Apple's developer documentation online and in Xcode.

With the announcements of WWDC 2014, the developer documentation was overhauled with a sleek new design that could accommodate switching between Swift & Objective-C. (If you've checked out any of the new iOS 8 APIs online, you've seen this in action)

What really comes as a surprise is that the format of documentation appears to have changed as well.

In the midst of Swift code, Headerdoc comments are not parsed correctly when invoking Quick Documentation (⌥ʘ):

/**    Lorem ipsum dolor sit amet.    @param bar Consectetur adipisicing elit.    @return Sed do eiusmod tempor.*/funcfoo(bar:String)->AnyObject{...}

What is parsed, however, is something markedly different:

/**    Lorem ipsum dolor sit amet.    :param: bar Consectetur adipisicing elit.    :returns: Sed do eiusmod tempor.*/funcfoo(bar:String)->AnyObject{...}

So what is this strange new documentation format? It turns out that SourceKit (the private framework powering Xcode, previously known for its high FPS crashes) includes a basic parser for reStructuredText. Only a subset of the specification is implemented, but there's enough in there to cover basic formatting.

Basic Markup

Documentation comments are distinguished by using /** ... */ for multi-line comments or /// ... for single-line comments. Inside comment blocks, paragraphs are separated by blank lines. Unordered lists can be made with several bullet characters: -, +, *, •, etc, while ordered lists use Arabic numerals (1, 2, 3, ...) followed by a period 1. or right parenthesis 1) or surrounded by parentheses on both sides (1):

/**    You can apply *italic*, **bold**, or `code` inline styles.    - Lists are great,    - but perhaps don't nest    - Sub-list formatting      - isn't the best.    1. Ordered lists, too    2. for things that are sorted;    3. Arabic numerals    4. are the only kind supported.*/

Definition & Field Lists

Defininition and field lists are displayed similarly in Xcode's Quick Documentation popup, with definition lists a little more compact:

/**    Definition list        A list of terms and their definitions.    Format        Terms left-justified, definitions indented underneath.    :Field header:        Field lists are spaced out a little more.    :Another field: Field lists can start the body immediately, without a line break and indentation.        Subsequent indented lines are treated as part of the body, too.*/

Two special fields are used to document parameters and return values: :param: and :returns:, respectively. :param: is followed by the name of the paramenter, then the description. Return values don't have a name, so the description begins immediately after :returns::

/**    Repeats a string `times` times.    :param: str     The string to repeat.    :param: times   The number of times to repeat `str`.    :returns: A new string with `str` repeated `times` times.*/funcrepeatString(str:String,times:Int)->String{returnjoin("",Array(count:times,repeatedValue:str))}

Code blocks

Code blocks can be embedded in documentation comments as well, which can be useful for demonstrating proper usage or implementation details. Inset the code block by at least two spaces:

/**    The area of the `Shape` instance.    Computation depends on the shape of the instance. For a triangle, `area` will be equivalent to:      let height = triangle.calculateHeight()      let area = triangle.base * height / 2*/vararea:CGFloat{get}

Documentation Is My New Bicycle

How does this look when applied to an entire class? Quite nice, actually:

importFoundation/// 🚲 A two-wheeled, human-powered mode of transportation.classBicycle{/**        Frame and construction style.        - Road: For streets or trails.        - Touring: For long journeys.        - Cruiser: For casual trips around town.        - Hybrid: For general-purpose transportation.    */enumStyle{caseRoad,Touring,Cruiser,Hybrid}/**        Mechanism for converting pedal power into motion.        - Fixed: A single, fixed gear.        - Freewheel: A variable-speed, disengageable gear.    */enumGearing{caseFixedcaseFreewheel(speeds:Int)}/**        Hardware used for steering.        - Riser: A casual handlebar.        - Café: An upright handlebar.        - Drop: A classic handlebar.        - Bullhorn: A powerful handlebar.    */enumHandlebar{caseRiser,Café,Drop,Bullhorn}/// The style of the bicycle.letstyle:Style/// The gearing of the bicycle.letgearing:Gearing/// The handlebar of the bicycle.lethandlebar:Handlebar/// The size of the frame, in centimeters.letframeSize:Int/// The number of trips travelled by the bicycle.private(set)varnumberOfTrips:Int/// The total distance travelled by the bicycle, in meters.private(set)vardistanceTravelled:Double/**        Initializes a new bicycle with the provided parts and specifications.        :param: style The style of the bicycle        :param: gearing The gearing of the bicycle        :param: handlebar The handlebar of the bicycle        :param: centimeters The frame size of the bicycle, in centimeters        :returns: A beautiful, brand-new, custom built just for you.    */init(style:Style,gearing:Gearing,handlebar:Handlebar,frameSizecentimeters:Int){self.style=styleself.gearing=gearingself.handlebar=handlebarself.frameSize=centimetersself.numberOfTrips=0self.distanceTravelled=0}/**        Take a bike out for a spin.        :param: meters The distance to travel in meters.    */functravel(distancemeters:Double){ifmeters>0{distanceTravelled+=meters++numberOfTrips}}}

Option-click on the Styleenum declaration, and the description renders beautifully with a bulleted list:

Open Quick Documentation for the method travel, and the parameter is parsed out into a separate field, as expected:

MARK / TODO / FIXME

In Objective-C, the pre-processor directive #pragma mark is used to divide functionality into meaningful, easy-to-navigate sections. In Swift, there are no pre-processor directives (closest are the similarly-octothorp'd build configurations), but the same can be accomplished with the comment // MARK:.

As of Xcode 6β4, the following comments will be surfaced in the Xcode source navigator:

• // MARK:(As with #pragma, marks followed by a single dash (-) will be preceded with a horizontal divider)
• // TODO:
• // FIXME:

Other conventional comment tags, such as NOTE and XXX are not recognized by Xcode.

To show these new tags in action, here's how the Bicycle class could be extended to adopt the Printable protocol, and implement description.

// MARK: PrintableextensionBicycle:Printable{vardescription:String{vardescriptors:[String]=[]switchself.style{case.Road:descriptors.append("A road bike for streets or trails")case.Touring:descriptors.append("A touring bike for long journeys")case.Cruiser:descriptors.append("A cruiser bike for casual trips around town")case.Hybrid:descriptors.append("A hybrid bike for general-purpose transportation")}switchself.gearing{case.Fixed:descriptors.append("with a single, fixed gear")case.Freewheel(letn):descriptors.append("with a \(n)-speed freewheel gear")}switchself.handlebar{case.Riser:descriptors.append("and casual, riser handlebars")case.Café:descriptors.append("and upright, café handlebars")case.Drop:descriptors.append("and classic, drop handlebars")case.Bullhorn:descriptors.append("and powerful bullhorn handlebars")}descriptors.append("on a \(frameSize)\" frame")// FIXME: Use a distance formatterdescriptors.append("with a total of \(distanceTravelled) meters traveled over \(numberOfTrips) trips.")// TODO: Allow bikes to be named?returnjoin(", ",descriptors)}}

Bringing everything together in code:

letbike=Bicycle(style:.Road,gearing:.Freewheel(speeds:8),handlebar:.Drop,frameSize:53)bike.travel(distance:1_500)// Trip around the townbike.travel(distance:200)// Trip to the storeprintln(bike)// "A road bike for streets or trails, with a 8-speed freewheel gear, and classic, drop handlebars, on a 53" frame, with a total of 1700.0 meters traveled over 2 trips."

Jazzy

Jazzy is an open-source command-line utility that transforms your documentation comments into a set of Apple-like HTML documentation.

Although the tooling and documentation around Swift is still rapidly evolving, one would be wise to adopt good habits early, by using the new light markup language conventions for documentation, as well as MARK: comments in Swift code going forward.

Go ahead and add it to your TODO: list.

Stop right there! Given the topic, wouldn't you rather read this article as a Playground? Download Now →

Play.

Given the association of play with childish exuberance, one could define play as the opposite of work. And yet, the elements of play are what we do in our line of work every day: experimentation, exploration, discovery.

Playgrounds aren't a feature of the Swift language per se—instead, they are a terrific showcase for all that Swift has to offer, from its efficiency and power to its opacity and depth. Playgrounds make it truly simple to create a working program—indeed, every new Playground starts with the soon-familiar "Hello, playground". At the same time, Playgrounds hide some of their most powerful features, leaving exploration as the only means to discovering their rapidly advancing capabilities.

This week, we'll take a look past the surface of Playgrounds, giving you tools to make them a powerful part of your development process. Read on for more about Playground sources and resources, captured values and extended execution, and integrated rich formatting that can transform a Playground into an interactive teaching tool.

Note: The digital version of the recently released NSHipster: Obscure Topics in Cocoa & Swift includes a package of Playgrounds—one for every chapter in the book. Each Playground provides a chance to explore and experiment with the concepts presented therein, including extended examples.

Sources

The revamped Playground package structure includes a "Sources" folder for code that is more stable than experimental. All files in the "Sources" directory are compiled (just once, not every time you press a key) into a single module and automatically imported into the Playground. In addition to simplifying the code in your Playground, this compilation drastically speeds up execution. This means that if I have defined a type, function, or global constant in those files with public accessibility, I can use it in a Playground without further ado:

To get started in your own Playground, open the Project Navigator (⌘1) and expand the Playground file to see the "Sources" directory.

Importing Frameworks

To import an external framework, create a new Xcode Workspace that contains both the framework project and your Playground. After building the framework, it can be imported with a standard import statement.

Resources

No playground is complete without a sandbox to play in, and Swift Playgrounds don't disappoint. Playgrounds have two places to keep associated resources: one local to each individual playground and a second shared amongst all of them. Being able to load and work with XML, JSON data, XIBs, and images extends the usefulness of your Playground experimentation.

Local

The Resources folder, embedded in the Playground package alongside Sources, is visible in the Project Navigator—simply drag and drop images or data files to use them in your Playground. The contents are then available via the main bundle. For example, we can easily load a JSON file filled with weather data:

letjsonPath=NSBundle.mainBundle().bundlePath.stringByAppendingPathComponent("weather.json")ifletjsonData=NSData(contentsOfFile:jsonPath),json=NSJSONSerialization.JSONObjectWithData(jsonData,options:nil,error:nil)as?[String:AnyObject]{// ...}

Shared

The contents of a "Shared Playground Data" directory inside your "Documents" folder are available to any Playground you create. Access the shared folder via the XCPSharedDataDirectoryPath constant.

To try this out yourself, you'll need to create the directory at "~/Documents/Shared Playground Data". Here we're attempting to load an image named "image.png":

letsharedImagePath=XCPSharedDataDirectoryPath.stringByAppendingPathComponent("image.png")ifletimage=UIImage(contentsOfFile:sharedImagePath){// ...}

Captured Values

A Playground normally shows the results of simple expressions immediately. Arrays, strings, numbers, and more have their values shown in the results pane as they are calculated. But what about values that change over time?

By using the XCPCaptureValue() function, we can build a graph of a changing value over a series of iterations. Returning to our weather sample, let's take a look at the hourly temperatures in the data, using XCPCaptureValue to display the value of temperature in the Assistant Editor's timeline view:

importXCPlaygroundforforecastinforecasts{iflettempString=forecast["temp"]?["english"]as?String,temperature=tempString.toInt(){XCPCaptureValue("Temperature",temperature)}}

Alternatively, choosing Editor → Show Result For Current Line will capture the current line's values and display the chart directly in the flow of the Playground:

Asynchronous Execution

Unlike most Swift code that is written as part of an app or framework, Playgrounds are treated as top-level code. Top-level code in a Playground is executed instruction-by-instruction in order, from top to bottom. This container-less style of execution provides immediate feedback, but there is one problem: execution halts as soon as it reaches the end of the Playground. Network requests, timers, and long-running background queues are abandoned before they can return to report on success or failure.

To keep execution going long enough to see the results of these kinds of asynchronous operations, the XCPlayground module includes a function that extends the length of the process:

importXCPlaygroundXCPSetExecutionShouldContinueIndefinitely(continueIndefinitely:true)leturl=NSURL(string:"http://httpbin.org/image/png")!lettask=NSURLSession.sharedSession().dataTaskWithURL(url){data,_,_inletimage=UIImage(data:data)// ...}task.resume()

In addition to the code in a Playground, Swift code run from the command line in a scripting file, in the Swift REPL, or in a project's optional "main.swift" file is also considered top-level code. Along with order-dependent execution, top-level code is the only kind that can contain statements outside of a function or encapsulated within a type.

Documentation

Beyond experimentation, Playgrounds are also powerful for demonstrating tools and frameworks in the Swift language. Special documentation sections can be rendered as rich text, giving clear narration to code that demonstrates a technique or the correct way to use a library.

Unlike Swift's other documentation syntax, Swift Playgrounds use Markdown for richly formatted text. (If you downloaded the Playground for this post, you're reading Markdown right now.) A colon (:) added to a single- or multi-line comment marker signifies a rich-text comment:

//: This line will have **bold** and *italic* text./*:## Headers of All Sizes### Lists of Links- [NSHipster](http://nshipster.com)- [ASCIIwwdc](http://asciiwwdc.org)- [SwiftDoc](http://swiftdoc.org)### Images, Too![Remote Image](http://nshipster.s3.amazonaws.com/alert.gif)![Local Image](bomb.gif) *Images in the Resources directory can be referenced locally**/

It's possible to toggle rich documentation rendering either by selecting the Editor → Show Rendered Markup menu item or by checking the Render Documentation checkbox in the File Inspector (⌘⌥1).

Playgrounds represent a major shift in the way we share and learn about tools for OS X and iOS. A Playground can demonstrate each feature and provide a space for potential users to discover and explore the library you've created. Trade out your static README.md for an interactive README.playground and let the play begin anew.

Reflection in Swift is a limited affair, providing read-only access to a subset of type metadata. While far from the rich array of run-time hackery familiar to seasoned Objective-C developers, Swift's tools enable the immediate feedback and sense of exploration offered by Xcode Playgrounds.

Perhaps Swift's strict type checking obviates the need for reflection. With variable types typically known at compile time, there might not be cause for further examination or branching. Then again, a hefty number of Cocoa APIs dole out AnyObject instances at the drop of a hat, leaving us to cast about for the matching type.

This week, we'll reflect on reflection in Swift, its mirror types, and MirrorType, the protocol that binds them together.

MirrorType

The entry point for reflection is the reflect function, which can take an instance of any type as its single parameter and returns a MirrorType. Now, MirrorType is something of an oddity for the Swift standard libary: a protocol used as a type. Other than the ubiquitous AnyObject, to date no other protocol is used this way. The particular MirrorType-conforming instance that you receive depends on the type passed to reflect—Swift's internals define mirrors for types such as Array, Dictionary, Optional, and Range, along with more generic mirrors for structs, classes, tuples, and metatypes.

MirrorType provides the nascent reflection API that Swift offers, wrapping a value along with its type information, information about its children, and different representations of the instance. Mirrors have the following properties:

• value: access to the original reflected value, but with type Any.
• valueType: the Type of the original reflected value—equivalent to value.dynamicType.
• count: the number of logical children. For a collection, like Array or Set, this is the number of elements; for a struct, this is the number of stored properties.
• disposition: a value from the MirrorDisposition enumeration, intended to help the IDE choose how to display the value. MirrorDisposition has eleven cases:
  • IndexContainer, KeyContainer, MembershipContainer, Container: used for collections.
  • Optional: used for optional values. Implicitly unwrapped optionals are skipped over by reflect() to fetch the reflection of the unwrapped value.
  • Aggregate: used for Swift types that bridge to Objective-C and for Objective-C types that have been augmented for use with Swift. For example, Float has an Aggregate disposition while the non-bridged Float80 returns Struct, and UIView (extended for Reflectable conformance), has an Aggregate disposition while the unadorned UIBarButtonItem returns ObjCObject.
  • ObjCObject: by contrast with Aggregate, used for unextended Objective-C classes.
  • Tuple: used for tuple values.
  • Struct, Class, Enum: used as fallback cases for types that don't fall into any of the above categories.
• objectIdentifier: the unique object identifier for a class or metatype instance.
• summary: a string description of the value.
• quickLookObject: a QuickLookObject instance holding a visual or text representation of the value. Its behavior is similar to the debugQuickLookObjectwe covered a few weeks back.

Additionally, a mirror has an Int-based subscript that returns a (String, MirrorType) tuple for each child. That's the name of the property/key/index and a mirror of the value.

So how can we put MirrorType to use? Let's suppose we have a group of numbers in a tuple that we want to use for a lottery ticket, but we need to convert them to an [Int] array first:

letlotteryTuple=(4,8,15,16,23,42)

Rather than extracting the pieces of the tuple one by one (i.e., lotteryType.0, lotteryTuple.1, etc.), we can use reflect() to iterate over the elements:

// create a mirror of the tupleletlotteryMirror=reflect(lotteryTuple)// loop over the elements of the mirror to build an arrayvarlotteryArray:[Int]=[]foriin0..<lotteryMirror.count{let(index,mirror)=lotteryMirror[i]ifletnumber=mirror.valueas?Int{lotteryArray.append(number)}}println(lotteryArray)// [4, 8, 15, 16, 23, 42]

Not bad.

Mapping a Mirror

If we could map over the elements in a mirror, reflecting over an instance's properties or elements would be a bit easier. Let's write a mapReflection function that takes an instance of any type and a transforming closure:

funcmapReflection<T,U>(x:T,@noescapetransform:(String,MirrorType)->U)->[U]{varresult:[U]=[]letmirror=reflect(x)foriin0..<mirror.count{result.append(transform(mirror[i]))}returnresult}

Now we can quite simply print all the logical children of any instance:

letprintChild:(String,MirrorType)->()={println("\($0): \($1.value)")}mapReflection(lotteryTuple,printChild)// .0: 4// .1: 8// ...mapReflection(lotteryArray,printChild)// [0]: 4// [1]: 8// ...mapReflection(CGRect.zeroRect,printChild)// origin: (0.0, 0.0)// size: (0.0, 0.0)

That output might look familiar to those who have used Swift's dump function before. dump uses reflection recursively to print out an instance's children, their children, and so on:

dump(CGRect.zeroRect)// ▿ (0.0, 0.0, 0.0, 0.0)//   ▿ origin: (0.0, 0.0)//     - x: 0.0//     - y: 0.0//   ▿ size: (0.0, 0.0)//     - width: 0.0//     - height: 0.0

Custom-Cut Mirrors

Beyond dump, Xcode also uses mirrors extensively for the display of values in a Playground, both in the results pane on the right side of a Playground window and in captured value displays. Custom types don't start out with a custom mirror, so their display can leave something to be desired. Let's look at the default behavior of a custom type in a Playground and then see how a custom MirrorType can improve that display.

For our custom type, we'll use a simple struct to hold information about a WWDC session:

/// Information for a single WWDC session.structWWDCSession{/// An enumeration of the different WWDC tracks.enumTrack:String{caseFeatured="Featured"caseAppFrameworks="App Frameworks"caseDistribution="Distribution"caseDeveloperTools="Developer Tools"caseMedia="Media"caseGraphicsAndGames="Graphics & Games"caseSystemFrameworks="System Frameworks"caseDesign="Design"}letnumber:Intlettitle:Stringlettrack:Trackletsummary:String?}letsession801=WWDCSession(number:801,title:"Designing for Future Hardware",track:.Design,summary:"Design for tomorrow's products today. See examples...")

By default, reflection on a WWDCSession instance uses the built-in _StructMirror type. This provides a property-based summary on the right (useful) but only the class name in a captured value pane (not so useful):

To provide a richer representation of a WWDCSession, we'll implement a new type, WWDCSessionMirror. This type must conform to MirrorType, including all the properties listed above:

structWWDCSessionMirror:MirrorType{privatelet_value:WWDCSessioninit(_value:WWDCSession){_value=value}varvalue:Any{return_value}varvalueType:Any.Type{returnWWDCSession.self}varobjectIdentifier:ObjectIdentifier?{returnnil}vardisposition:MirrorDisposition{return.Struct}// MARK: Child propertiesvarcount:Int{return4}subscript(index:Int)->(String,MirrorType){switchindex{case0:return("number",reflect(_value.number))case1:return("title",reflect(_value.title))case2:return("track",reflect(_value.track))case3:return("summary",reflect(_value.summary))default:fatalError("Index out of range")}}// MARK: Custom representationvarsummary:String{return"WWDCSession \(_value.number) [\(_value.track.rawValue)]: \(_value.title)"}varquickLookObject:QuickLookObject?{return.Text(summary)}}

In the summary and quickLookObject properties, we provide our custom representation of a WWDCSession—a nicely formatted string. Note, in particular, that the implementation of count and the subscript are completely manual. The default mirror types ignore private and internal access modifiers, so a custom mirror could be used to hide implementation details, even from reflection.

Lastly, we must link WWDCSession to its custom mirror by adding conformance to the Reflectable protocol. Conformance only requires a single new method, getMirror(), which returns a MirrorType—in this case, our shiny new WWDCSessionMirror:

extensionWWDCSession:Reflectable{funcgetMirror()->MirrorType{returnWWDCSessionMirror(self)}}

That's it! The Playground now uses our custom representation instead of the default:

In the absence of Printable conformance, println() and toString() will also pull the string representation from an instance's mirror.

In its current form, Swift reflection is more novelty than powerful feature. With new Swift functionality surely right around the corner at WWDC, this article may prove to have a very short shelf life indeed. But in the mean time, should you find the need for introspection, you'll know just where to look.

On June 9th, we organized the third annual WWDC edition of the NSHipster Pub Quiz, with topics ranging from pop cultural trivia to technical pedantry. A huge thanks to Realm, who opened their offices and hosted with aplomb the scores of developers who turned out for the quiz.

With dozens of teams competing for the prizes on offer, competition was fierce. After the final tally, Team "U+1F4A9" (aka "💩 PILE OF POO") took the top prize with a score of 35 points. Congratulations to Benjamin Encz, Dave Verwer, Emilio Peláez, Jeffrey Bergier, Michael Helmbrecht, and Warren Moore on the win!

As always, you can play along at home or at work with your colleagues. Here are the rules:

• Four rounds of ten questions each
• Record your answers on a separate sheet of paper
• Each correct answer to a question gets you 1 point (unless otherwise specified)
• Play with up to five friends for maximum enjoyment
• Don't be lame and look things up on the Internet or in Xcode

Round 1: General Knowledge

1. What 1989 movie introduces its protagonist free climbing El Capitan, to disastrous effect?
2. El Capitan looks down on a river that winds through Yosemite. What is the river’s name?
3. In the WWDC keynote, Tim Cook showed off a list of demands some Cleveland Indians players were using to ransom their teammate’s 100th home run ball. What item did Apple carefully remove from the list?
4. With WebKit already using WK, WatchKit had to find a different class prefix. What is the unusual prefix used for the most of the WatchKit framework?
5. The name "Swift" can be written using a ligature for its final two letters. What are the five Unicode-standard ligatures beginning with the letter "f"?
6. The typeface used for Apple Watch (and the new versions of iOS and OS X) is "San Francisco," but it isn’t the first custom font Apple has used by that name. What were the letters of the original "San Francisco" meant to resemble? For a bonus point, name the original font's designer.
7. What is reportedly the lock screen image on Jony Ive’s iPhone?
8. Apple made a splash when they announced that ResearchKit would be open source and hosted on GitHub. What was the first pull request accepted for ResearchKit?
9. ResearchKit also uses an unexpected class prefix. What is the prefix and what does it stand for?
10. Scott Forstall is back in the news, producing a Broadway musical that just won five Tonys. What is the name of the musical? For a bonus point, upon what author's memoir is the musical based?

Round 2: Name That Framework

How well do you know Cocoa? For each question in this round, you'll be given three classes with their identifying prefix removed. Name the framework which contains all three.

1. MultiPoint, Placemark, Polyline
2. Locale, NotificationCenter, NumberFormatter
3. Correlation, Statistics, Unit
4. Navigation, Preferences, UserScript
5. Switch, Timer, Map
6. URL, URLCache, URLCredential
7. Activity, Lexicon, DictationPhrase
8. ContentItem, MoviePlayerController, RemoteCommand
9. PaymentToken, PaymentMethod, ShippingMethod
10. Beacon, Floor, Visit

Round 3: Picture Round

1. Who is shown here sporting this unannounced gold link bracelet Apple Watch shortly before launch?

2. What TV show featured these watches? For a bonus point, what was the related catchphrase?

3. Hailing from the same era, what development tool is this?

4. What Apple Design Award-winning app is this?

5. What Apple Design Award-winning app is this?

6. What app is this?

7. What app is this?

8. Who is this?

9. Who is this?

10. What are the Unicode names for these Emoji?

Round 4: Anagrammable

NSAnagram has been ported to Swift as Anagrammable, still a vexing test of knowledge and concentration. Each question is an anagram, whose letters can be rearranged to form the name of a type or protocol in the Swift standard library. Good luck!

For timing, listen to these three songs play back to back:

1. Be Loud!
2. Forget No Ear
3. Too Plain
4. Oboe Penalty
5. Scalable Lube Item
6. Poets Win At Poetry
7. Ol’ Potty Licence
8. Unprofitable Tea Menus
9. Ram Placebo
10. Tin?

Answers

Round 1: General Knowledge

1. Star Trek V: The Final Frontier
2. Merced River
3. 50 gallon drum of lube
4. WKInterface
5. ff, fi, fl, ffi, ffl
6. A ransom note, by Susan Kare
7. A Playmobile figure of himself
8. A typo in the README.md
9. ORK: Open Research Kit
10. Fun Home, based on the memoir by Alison Bechdel

Round 2: Name That Framework

1. MapKit
2. Foundation or CoreFoundation (2 points for both)
3. HealthKit
4. WebKit
5. WatchKit
6. Foundation
7. UIKit
8. MediaPlayer
9. PassKit
10. CoreLocation

Round 3: Picture Round

1. Beyonce
2. Parker Lewis Can't Lose, "Synchronize Swatches"
3. ResEdit
4. Metamorphabet
5. Workflow
6. Meerkat
7. GIFs
8. Chris Lattner
9. Christian Laettner
10. Aubergine, Dancer, Clinking Beer Mugs

Round 4: Anagrammable

1. Double! (2 points if marked as an implicitly unwrapped optional)
2. GeneratorOf
3. Optional
4. BooleanType
5. MutableSliceable
6. RawOptionSetType
7. CollectionType
8. UnsafeMutablePointer
9. Comparable
10. Int? (2 points if marked as an Optional)

Well, how did you do this time? Tweet out your score to see how you stack up to your peers!

WWDC 2015 may not have packed quite as many fireworks as its predecessor, but neither was it short on the new and shiny. The introduction of watchOS 2, including a revamped WatchKit, access to the Apple Watch hardware, and support for complications. Major changes to the Swift language and the announcement of open source plans. Brand new frameworks, such as Contacts, ContactsUI, and CoreSpotlight, and new UIKit types like UIStackView and SFSafariViewController.

We'll surely delve into these major new components in the weeks and months to come. For now, however, let's take a look at some of the smaller changes that iOS 9 brings to the APIs we already know and love.

String Transformations

Up first is the news that string transformations, formerly housed in Core Foundation, have made their way to NSString and the Swift String type. This is a huge advance in discoverability and ease-of-use for this powerful Cocoa feature, because there is no longer any need to deal with the hassle of bridging to and from CFStringRef. Here's how some of our favorite transformations can be done along with the new NSStringTransform* constants that enable them:

Transliteration

"privet".stringByApplyingTransform(NSStringTransformLatinToCyrillic,reverse:false)// "привет""안녕하세요".stringByApplyingTransform(NSStringTransformLatinToHangul,reverse:true)// "annyeonghaseyo""annyeonghaseyo".stringByApplyingTransform(NSStringTransformLatinToHangul,reverse:false)// "안녕하세요"

NSLog(@"%@",[@"privet"stringByApplyingTransform:NSStringTransformLatinToCyrillicreverse:NO]);// "привет"NSLog(@"%@",[@"annyeonghaseyo"stringByApplyingTransform:NSStringTransformLatinToHangulreverse:NO]);// "안녕하세요"NSLog(@"%@",[@"안녕하세요"stringByApplyingTransform:NSStringTransformLatinToHangulreverse:YES]);// "annyeonghaseyo"

Unicode Names

"🐷".stringByApplyingTransform(NSStringTransformToUnicodeName,reverse:false)// "{PIG FACE}"

NSLog(@"%@",[@"🐷"stringByApplyingTransform:NSStringTransformToUnicodeNamereverse:NO]);// "{PIG FACE}"

Normalizing User Input

"Hello! こんにちは! สวัสดี! مرحبا! 您好!".stringByApplyingTransform(NSStringTransformToLatin,reverse:false)?.stringByApplyingTransform(NSStringTransformStripDiacritics,reverse:false)?.localizedLowercaseString.componentsSeparatedByCharactersInSet(NSCharacterSet.whitespaceCharacterSet())// ["hello!", "kon'nichiha!", "swasdi!", "mrhba!", "nin", "hao!"]

NSString*input=@"Hello! こんにちは! สวัสดี! مرحبا! 您好!";NSString*processing=[inputstringByApplyingTransform:NSStringTransformToLatinreverse:NO];processing=[processingstringByApplyingTransform:NSStringTransformStripDiacriticsreverse:NO];NSArray<NSString*>*output=[processing.localizedLowercaseStringcomponentsSeparatedByCharactersInSet:[NSCharacterSetwhitespaceCharacterSet]];NSLog(@"%@",output);// ["hello!", "kon'nichiha!", "swasdi!", "mrhba!", "nin", "hao!"]

For more on string transformations, be sure to check out Mattt's terrific article on CFStringTransform.

CLLocationManager.requestLocation

Core Location includes a nice new API for apps that simply need to fetch the user's location without continuous location updates. requestLocation() uses the same delegate methods as continuous updates, turning itself off after delivering the location with the desired accuracy:

classViewController:UIViewController,CLLocationManagerDelegate{letlocationManager=CLLocationManager()// ...overridefuncviewDidLoad(){super.viewDidLoad()locationManager.delegate=selflocationManager.desiredAccuracy=kCLLocationAccuracyHundredMeterslocationManager.requestLocation()}// MARK: - CLLocationManagerDelegatefunclocationManager(manager:CLLocationManager,didUpdateLocationslocations:[CLLocation]){ifletlocation=locations.first{print("Current location: \(location)")}else{// ...}}funclocationManager(manager:CLLocationManager,didFailWithErrorerror:NSError){print("Error finding location: \(error.localizedDescription)")}}

Swiftification

The Cocoa APIs in iOS 9 (and OS X 10.11) include thousands of minor changes designed to make Swift interoperability safer and cleaner. These changes start with the familiar nullability annotations, converting implicitly unwrapped parameters and return values to either true Optionals or simple, non-optional data types. But they also go much further.

For example, instead of marking NSArray return values as nullable, many APIs have been modified to return an empty array—semantically these have the same value (i.e., nothing), but a non-optional array is far simpler to work with. Moreover, many Cocoa APIs are gradually taking advantage of the new Objective-C generic syntax to provide typed arrays. The CLLocationManagerDelegate method locationManager(_:didUpdateLocations:) shown above is one such example: where the locations parameter used to be imported as an AnyObject array, it is now an array of CLLocation, eliminating the need for any casting in the method body.

Finally, some APIs that were completely inaccessible from Swift have been revised, such as methods for retrieving UIAppearance proxies that limit appearance to a particular containment hierarchy—UIKit's version of CSS-lite. The old appearanceWhenContainedIn: method is implemented with C variadic parameters, which Swift doesn't import; the new appearanceWhenContainedInInstancesOfClasses(_:) method simply takes an array of type objects:

UIBarButtonItem.appearanceWhenContainedInInstancesOfClasses([UINavigationController.self]).tintColor=UIColor.redColor()

[UIBarButtonItemappearanceWhenContainedInInstancesOfClasses:@[[UINavigationControllerclass]]].tintColor=[UIColorredColor];

Ironically enough, this method crashes at runtime when used from Swift. Betas gonna beta.

NSFormatter Additions

The new Contacts framework includes NSFormatter subclasses for localized formatting of contacts and addresses alongside a new Foundation NSPersonNameComponentsFormatter class. We'll cover those more in the weeks to come, but here let's highlight a few additions to two old favorites: NSNumberFormatter and NSDateFormatter.

NSNumberFormatter

First, NSNumberFormatter sees four additional styles in iOS 9, starting with .OrdinalStyle, used for converting numbers to their ordinal equivalent:

letformatter=NSNumberFormatter()formatter.numberStyle=.OrdinalStyleletnumbers=[1,2,3,4,5]numbers.map{formatter.stringFromNumber($0)!}// ["1st", "2nd", "3rd", "4th", "5th"]formatter.locale=NSLocale(localeIdentifier:"es")numbers.map{formatter.stringFromNumber($0)!}// ["1º", "2º", "3º", "4º", "5º"]

NSNumberFormatter*formatter=[[NSNumberFormatteralloc]init];formatter.numberStyle=NSNumberFormatterOrdinalStyle;NSArray<NSNumber*>*numbers=@[@1,@2,@3,@4,@5];for(NSNumber*numberinnumbers){NSLog(@"%@",[formatterstringFromNumber:number]);}// "1st", "2nd", "3rd", "4th", "5th"formatter.locale=[NSLocalelocaleWithLocaleIdentifier:@"es"];for(NSNumber*numberinnumbers){NSLog(@"%@",[formatterstringFromNumber:number]);}// "1º", "2º", "3º", "4º", "5º"

Next, the existing .CurrencyStyle gets some company with .CurrencyPluralStyle, .CurrencyISOCodeStyle, and .CurrencyAccountingStyle. When using these new styles, be sure your locale fully specifies both a language and a country, which it makes it possible for the formatter to choose the right currency and presentation:

letstyles:[NSNumberFormatterStyle]=[.CurrencyStyle,.CurrencyPluralStyle,.CurrencyISOCodeStyle,.CurrencyAccountingStyle]formatter.locale=NSLocale(localeIdentifier:"en_US")styles.map{formatter.numberStyle=$0returnformatter.stringFromNumber(-125)!}// ["-$125.00", "-125.00 US dollars", "-USD125.00", "($125.00)"]formatter.locale=NSLocale(localeIdentifier:"es_ES")styles.map{formatter.numberStyle=$0returnformatter.stringFromNumber(-125)!}// ["-125,00 €", "-125,00 euros", "-125,00 EUR", "-125,00 €"]

NSDateFormatter

Second—and I'll fess up—this new NSDateFormatter method is a bit of a cheat. setLocalizedDateFormatFromTemplate(_:) was introduced in iOS 8 but largely slid under the radar until this year's sessions on internationalization. This new-ish method makes it supremely easy to define a template for the date and time elements you want; however, it leaves the formatting up to the excellent localization built into NSDateFormatter:

letnow=NSDate()// full date and timeletfullFormatter=NSDateFormatter()fullFormatter.setLocalizedDateFormatFromTemplate("yyyyMMMMddhhmm")// month name and year onlyletshortFormatter=NSDateFormatter()shortFormatter.setLocalizedDateFormatFromTemplate("yyMMMM")fullFormatter.stringFromDate(now)// "June 23, 2015, 4:56 PM"shortFormatter.stringFromDate(now)// "June 15"// switch locales to "de_DE"fullFormatter.locale=NSLocale(localeIdentifier:"de_DE")shortFormatter.locale=NSLocale(localeIdentifier:"de_DE")fullFormatter.stringFromDate(now)// "Juni 23, 2015, 4:56 nachm."shortFormatter.stringFromDate(now)// "Juni 15"

Well, that's that for our quick tour through some of iOS 9's new APIs, though there are many more where those came from. What new features are you most excited about in iOS 9 or OS X 10.11? Check out Apple's diffs and let us know!

As an iOS developer, if you want to make an application on your own, you sometimes need to write back-end code. Even for the developer who can take that on, there is more than just the code, there's also maintenance. Your worst fear becomes not that people might not like your application, but that your server might fail under heavy traffic.

Fortunately, we now have CloudKit. Apple takes care of all these details, so you can focus on how to make your application great.

What is CloudKit?

Perhaps you've heard of iCloud Drive before—iCloud Drive is where we can store our user's data and files for easy access from other devices. CloudKit is the framework that helps us do this easily in the apps we create.

CloudKit offers tons of APIs to access iCloud. You can create a user model inside your application linked to a user's iCloud account. Meanwhile, you can have a public global database to store application-level data. You can also save large files and bulk data into iCloud Drive, so your users can use their data from their other devices. This works just like working on local files, but with all the operations sent to the cloud.

Overall, CloudKit is a framework that replaces back-end web services like old-school databases, file storage, and user authentication systems. With CloudKit's help you don't need to worry about any of these, so you can focus your energy on your application.

Get into CloudKit

Imagine that you're working on a check-in application where users can add "places" with their location and check in at these places. We'll talk about how to build some basic functions of the check-in application with CloudKit.

Enable CloudKit

We have already talked about how powerful CloudKit is, now it is the time to show you how to use it. It's simple. All you need is to turn on iCloud and check CloudKit in the project panel of Xcode:

Fundamental CloudKit Objects

There are 7 different fundamental objects in CloudKit. You may have seen this elsewhere in your programming career, but there are some slight differences.

• CKContainer: A container is like a sandbox. An application can only use the resources inside its container. The container is located at the very outer border and each application has one and only one separate container. (You can allow other applications to access your container by configuring CloudKit Dashboard.)

• CKDatabase: A database is the place that you put all your data. There are two different kinds of databases: private and public. The private database is where you store sensitive data, like user's information. The public database is where you store shared data. For example, in our check-in application, you would store a user's birthday and check-ins in the private database but store "places" information in the public database.

• CKRecord: A record is a piece of data inside your database. It is stored as a key-value pair. For now, you can save NSString, NSNumber, NSData, NSDate, CLLocation, CKReference, and CKAsset, as well as arrays of all the types listed above.

• CKRecordZone: Records are not stored scattered in a database, they are located in record zones. Every application has a default record zone, and you can also have your own custom record zones.

• CKRecordIdentifier: the unique label of a record, used for locating a particular record.

• CKReference: Reference is like the relationship in an RDBMS. In our check-in example, there may be many people checked in at the same place, so we'll need to establish a reference between places and check-ins.

• CKAsset: Assets are resources, like binary files or bulk data. For example, a user's picture should be stored as an asset.

Convenience API

CloudKit's convenience API is there for do basic operations such as reading, writing, and editing records.

Let's work on our check-in application. To get started, import the CloudKit framework and get a reference to the public database:

importCloudKit// ...letpublicDB=CKContainer.defaultContainer().publicCloudDatabase

#import <CloudKit/CloudKit.h>// ...CKDatabase*publicDB=[[CKContainerdefaultContainer]publicCloudDatabase];

Next, create a new place and save it:

letgreatID=CKRecordID(recordName:"GreatPlace")letplace=CKRecord(recordType:"Place",recordID:greatID)publicDB.saveRecord(place){savedRecord,errorin// handle errors here}

CKRecordID*greatID=[[CKRecordIDalloc]initWithRecordName:@"GreatPlace"];CKRecord*place=[[CKRecordalloc]initWithRecordType:@"Place"recordID:greatID];[publicDBsaveRecord:placecompletionHandler:^(CKRecord*savedPlace,NSError*error){// handle errors here}];

CloudKit will connect to the Internet asynchronously when saveRecord:completionHandler: method is invoked. Remember to handle the error in the block, since the user's connection may be unstable. A good application deserves perfect error handling logic.

You should check the error code of the NSError object to detect which kind of error you are dealing with. A CKErrorNetworkUnavailable error may occur if you were on a bad internet connection, and what you need to do is to retry the operation after failure. But when to retry? Immediately or 10 seconds later? Don't worry, CloudKit offers a suggestion in the error's userInfo dictionary with the key CKErrorRetryAfterKey:

ifletretryAfterValue=error.userInfo[CKErrorRetryAfterKey]as?NSTimeInterval{letretryAfterDate=NSDate(timeIntervalSinceNow:retryAfterValue)// ...}

doubleretryAfterValue=error.userInfo[CKErrorRetryAfterKey];NSDate*retryAfterDate=[NSDatedateWithTimeIntervalSinceNow:retryAfterValue];

Here I'll read the place's information back:

letgreatID=CKRecordID(recordName:"GreatPlace")publicDB.fetchRecordWithID(greatID){fetchedPlace,errorin// handle errors here}

CKRecordID*greatID=[[CKRecordIDalloc]initWithRecordName:@"GreatPlace"];[publicDBfetchRecordWithID:greatIDcompletionHandler:^(CKRecord*fetchedPlace,NSError*error){// handle errors here}];

And here I'll edit an existing place's information:

letgreatID=CKRecordID(recordName:"GreatPlace")publicDB.fetchRecordWithID(greatID){fetchedPlace,erroringuardletfetchedPlace=fetchedPlaceelse{// handle errors herereturn}letname=fetchedPlace["name"]as?String??"Unnamed Place"fetchedPlace["name"]=name+" Door A"publicDB.saveRecord(fetchedPlace){savedPlace,savedErrorin//...}}

CKRecordID*greatID=[[CKRecordIDalloc]initWithRecordName:@"GreatPlace"];[publicDBfetchRecordWithID:greatIDcompletionHandler:^(CKRecord*fetchedPlace,NSError*error){if(fetchedPlace!=nil){NSString*name=fetchedPlace[@"name"];fetchedPlace[@"name"]=[namestringByAppendingString:@" Door A"];[publicDBsaveRecord:fetchedPlacecompletionHandler:^(CKRecord*savedPlace,NSError*savedError){//...}];}else{// handle errors here}}];

The progress of editing a record is pretty simple: read, edit, then save. What you should really pay attention to is how to do the three-step updating process, especially when updating one record depends on fetching others.

A bad practice:

database.fetchRecordWithID(recordID,completionHandler:{record,errorin//...database.fetchRecordWithID(otherRecordID,completionHandler:{otherRecord,otherErrorin//...database.saveRecord(record!,completionHandler:{anotherRecord,anotherErrorin//...})})})

[databasefetchRecordWithID:recordIDcompletionHandler:^(CKRecord*record,NSError*error){//...[databasefetchRecordWithID:otherRecordIDcompletionHandler:^(CKRecord*otherRecord,NSError*otherError){//...[databasesaveRecord:recordcompletionHandler:^(CKRecord*anotherRecord,NSError*anotherError){//...}];}];}];

With very complex nested operations you may run into a dilemma: There are three (or more) blocks and three (or more) errors to handle, so where should you handle the errors? where should you retry the operation if an error occurs? All together it starts looking like kind of a disaster.

A better approach is to use NSOperation dependencies to manage the dependent tasks:

letfirstFetch=CKFetchRecordsOperation()letsecondFetch=CKFetchRecordsOperation()secondFetch.addDependency(firstFetch)letqueue=NSOperationQueue()queue.addOperations([firstFetch,secondFetch],waitUntilFinished:false)

CKFetchRecordsOperation*firstFetch=...;CKFetchRecordsOperation*secondFetch=...;[secondFetchaddDependency:firstFetch];NSOperationQueue*queue=[[NSOperationQueuealloc]init];[queueaddOperations:[firstFetch,secondFetch]waitUntilFinished:NO];

You can finish almost all the work you need to do with the convenience API. What do you think so far? It's much easier than writing backend code, maintaining a server, and writing the code to communicate with it.

Advanced Features

Queries

While powerful, the convenience APIs aren't quite enough to finish our check-in application—now it's time to add search functionality. To add a search function, you will need a query. A CKQuery object is made up of RecordType, NSPredicate and NSSortDescriptors.

NSPredicate plays an important role here, handling string matching, location and date ranging, and combinations of simple queries. Refer to the CKQuery documentation for more.

Let's say I want all places containing the name 'Apple Store':

letpredicate=NSPredicate(format:"name CONTAINS 'Apple Store'")letquery=CKQuery(recordType:"Place",predicate:predicate)publicDB.performQuery(query,inZoneWithID:nil){results,errorin// ...}

NSPredicate*predicate=[NSPredicatepredicateWithFormat:@"name CONTAINS 'Apple Store'"];CKQuery*query=[[CKQueryalloc]initWithRecordType:@"Place"predicate:predicate];[publicDBperformQuery:queryinZoneWithID:nilcompletionHandler:^(NSArray*results,NSError*error){// ...}];

Alternately, you could modify the query to retrieve all the places within one mile around the user.

Subscriptions

After adding queries, our application is almost complete. Or wait, did we forget something?

Yes: notifications. They're a critical part of any check-in application.

For example, a social person may want to be notified if someone mentions "party" around him or her. This is possible with CloudKit—the framework already provides something to achieve this using the CKSubscription class:

letpredicate=NSPredicate(format:"description CONTAINS 'party'")letsubscription=CKSubscription(recordType:"Checkin",predicate:predicate,options:.FiresOnRecordCreation)letinfo=CKNotificationInfo()info.alertLocalizationKey="NEW_PARTY_ALERT_KEY"info.soundName="NewAlert.aiff"info.shouldBadge=truesubscription.notificationInfo=infopublicDB.saveSubscription(subscription){subscription,errorin//...}

CKDatabase*publicDB=[[CKContainerdefaultContainer]publicCloudDatabase];NSPredicate*predicate=[NSPredicatepredicateWithFormat:@"description CONTAINS 'party'"];CKSubscription*subscription=[[CKSubscriptionalloc]initWithRecordType:@"Checkin"predicate:predicateoptions:CKSubscriptionOptionsFiresOnRecordCreation];CKNotificationInfo*info=[CKNotificationInfonew];info.alertLocalizationKey=@"NEW_PARTY_ALERT_KEY";info.soundName=@"NewAlert.aiff";info.shouldBadge=YES;subscription.notificationInfo=info;[publicDBsaveSubscription:subscriptioncompletionHandler:^(CKSubscription*subscription,NSError*error){//...}];

Receiving the notification is handled by the application delegate:

funcapplication(application:UIApplication,didReceiveRemoteNotificationuserInfo:[NSObject:AnyObject]){letckNotification=CKNotification(fromRemoteNotificationDictionary:userInfoas![String:NSObject])ifckNotification.notificationType==.Query,letqueryNotification=ckNotificationas?CKQueryNotification{letrecordID=queryNotification.recordID//...}}

-(void)application:(UIApplication*)applicationdidReceiveRemoteNotification:(NSDictionary*)userInfo{CKNotification*ckNotification=[CKNotificationnotificationFromRemoteNotificationDictionary:userInfo];if(ckNotification.notificationType==CKNotificationTypeQuery){CKQueryNotification*queryNotification=ckNotification;CKRecordID*recordID=[queryNotificationrecordID];// ...}}

More

As I said in the beginning, CloudKit can do much more than described in this article. You can allow your users to add pictures to their check-ins. References in CloudKit allow you to get all the related check-ins for certain places. Moreover, CloudKit has an API that allows you to find your users' friends who are also using your application via their address book.

Can't wait to try out CloudKit? It could free you from writing backend code, caring about server pressure, maintaining a large CDN network, renting a server, and more. But wait—what about the price? How much does it cost? The answer is: free. Apple allows using CloudKit for 10 GB of resource storage, 100 MB of data storage, and 2 GB of daily transfer, scaling with your user base up to to 1 petabyte of resources, 10 TB database, and 200 TB transfer.

Check out the CloudKit cost calculator at the bottom of the page for detailed free limits and pricing.

As of WWDC 2015, CloudKit is not only available on iOS or OS X. You can now integrate CloudKit JS with your website to make it possible for iCloud users to enjoy your service in a web browser or use the CloudKit web service to communicate with CloudKit servers directly via HTTP request. All this means it's now possible to use CloudKit from any other mobile or desktop platform!

CloudKit is an amazing thing. I can't wait to see the awesome applications you NSHipsters make with it.

Adding a new feature to a product is always a tradeoff. Will the added utility of a new feature be enough to offset the added complexity? Shortcuts would seem to side-step this issue—after all, they're simply a quicker alternative for features already in your app. But that creates another dilemma: what if a new feature is added and no one knows it's there?

When key commands for external keyboards debuted in iOS 7, there was no intrinsic way to learn of their existence. Unlike in OS X, where a user can gradually discover shortcuts for the menu items they use most often, an iOS app had few ways to communicate what key commands are available. Initial tours flash by and fade from memory; help screens are hidden out of sight. Without a way to make shortcuts visible in a timely and relevant manner, users were sure to miss out on useful features that developers had taken the time to implement.

No longer. As part of the push for greater productivity on the iPad, iOS 9 adds Discoverability, an overlay showing the currently available key commands inside an app. This small change suddenly makes key commands far more viable on the iPad and, with it, makes UIKeyCommand a necessary addition to your app.

UIKeyCommand

The UIKeyCommand class is in fact quite simple, with only four properties to configure:

• input: The character of the key you'd like to recognize, or the correct constant for the arrow and escape keys, which do not have characters themselves. The available constants are:

  • UIKeyInputUpArrow
  • UIKeyInputDownArrow
  • UIKeyInputLeftArrow
  • UIKeyInputRightArrow
  • UIKeyInputEscape

• modifierFlags: One or more UIKeyModifierFlags, describing the modifier keys that should be pressed in combination with input:

  • .Command, .Alternate, .Shift, .Control: The Command, Option, Shift, and Control keys, respectively.
  • .NumericPad: Indicates that input should come from the numeric keypad rather than the top row of the standard keyboard.
  • .AlphaShift: Indicates that the CapsLock key should be pressed as part of the combination, rather than just engaged.

• action: The selector to call when the key command is invoked, called with a UIKeyCommand as its only argument. The key event will travel up the responder chain until a matching selector is found.

• discoverabilityTitle(iOS 9 only): An optional label to display for the key command in the Discoverability layover. Only key commands with a title set will be listed.

Responding to Key Commands

Enabling key commands is as simple as providing an array of UIKeyCommand instances somewhere in the responder chain. Text inputs are automatically first responders, but perhaps more usefully, a view controller can respond to key commands by implementing canBecomeFirstResponder():

overridefunccanBecomeFirstResponder()->Bool{returntrue}

-(BOOL)canBecomeFirstResponder{returnYES;}

Next, provide a list of available key commands via the keyCommands property:

overridevarkeyCommands:[UIKeyCommand]?{return[UIKeyCommand(input:"1",modifierFlags:.Command,action:"selectTab:",discoverabilityTitle:"Types"),UIKeyCommand(input:"2",modifierFlags:.Command,action:"selectTab:",discoverabilityTitle:"Protocols"),UIKeyCommand(input:"3",modifierFlags:.Command,action:"selectTab:",discoverabilityTitle:"Functions"),UIKeyCommand(input:"4",modifierFlags:.Command,action:"selectTab:",discoverabilityTitle:"Operators"),UIKeyCommand(input:"f",modifierFlags:[.Command,.Alternate],action:"search:",discoverabilityTitle:"Find…"),]}// ...funcselectTab(sender:UIKeyCommand){letselectedTab=sender.input// ...}

-(NSArray<UIKeyCommand*>*)keyCommands{return@[[UIKeyCommandkeyCommandWithInput:@"1"modifierFlags:UIKeyModifierCommandaction:@selector(selectTab:)discoverabilityTitle:@"Types"],[UIKeyCommandkeyCommandWithInput:@"2"modifierFlags:UIKeyModifierCommandaction:@selector(selectTab:)discoverabilityTitle:@"Protocols"],[UIKeyCommandkeyCommandWithInput:@"3"modifierFlags:UIKeyModifierCommandaction:@selector(selectTab:)discoverabilityTitle:@"Functions"],[UIKeyCommandkeyCommandWithInput:@"4"modifierFlags:UIKeyModifierCommandaction:@selector(selectTab:)discoverabilityTitle:@"Operators"],[UIKeyCommandkeyCommandWithInput:@"f"modifierFlags:UIKeyModifierCommand|UIKeyModifierAlternateaction:@selector(search:)discoverabilityTitle:@"Find…"]];}// ...-(void)selectTab:(UIKeyCommand*)sender{NSString*selectedTab=sender.input;// ...}

In the Discoverability layover, accessed by holding down the Command key, key commands are listed in the order you specified:

Voila! Secrets, revealed!

Context Sensitivity

The keyCommands property is accessed whenever a key pressed, making it possible to provide context-sensitive responses depending on the state of your application. While this is similar to the way a menu item and its active/inactive state are configured in OS X, the recommendation for iOS is to omit inactive commands completely—that is, there are no grayed out commands in the Discoverability layover.

Here, a set of commands that are available to logged in users of an app are included only when appropriate:

letglobalKeyCommands=[UIKeyCommand(input:...),...]letloggedInUserKeyCommands=[UIKeyCommand(input:...),...]overridevarkeyCommands:[UIKeyCommand]?{ifisLoggedInUser(){returnglobalKeyCommands+loggedInUserKeyCommands}else{returnglobalKeyCommands}}

Although we don't take shortcuts when creating our apps, that doesn't mean our users won't find shortcuts useful. Adding key commands lets control of your app shift from the screen to the keyboard—your users will love the option.

“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: