We knew that the Earth was not flat long before 1492. Early navigators observed the way ships would dip out of view over the horizon many centuries before the Age of Discovery.

For many iOS developers, though, a flat MKMapView was a necessary conceit until recently.

What changed? The discovery of MKGeodesicPolyline, which is the subject of this week's article.

MKGeodesicPolyline was introduced to the Map Kit framework in iOS 7. As its name implies, it creates a geodesic—essentially a straight line over a curved surface.

On the surface of a sphereoblate spheroidgeoid, the shortest distance between two points on appears as an arc on a flat projection. Over large distances, this takes a pronounced, circular shape.

A MKGeodesicPolyline is created with an array of of 2 MKMapPoints or CLLocationCoordinate2Ds:

Creating an MKGeodesicPolyline

CLLocation*LAX=[[CLLocationalloc]initWithLatitude:33.9424955longitude:-118.4080684];CLLocation*JFK=[[CLLocationalloc]initWithLatitude:40.6397511longitude:-73.7789256];CLLocationCoordinate2Dcoordinates[2]={LAX.coordinate,JFK.coordinate};MKGeodesicPolyline*geodesicPolyline=[MKGeodesicPolylinepolylineWithCoordinates:coordinatescount:2];[mapViewaddOverlay:geodesicPolyline];

Although the overlay looks like a smooth curve, it is actually comprised of thousands of tiny line segments (true to its MKPolyline lineage):

NSLog(@"%d",geodesicPolyline.pointsCount)// 3984

Like any object conforming to the <MKOverlay> protocol, an MKGeodesicPolyline instance is displayed by adding to an MKMapView with -addOverlay: and implementing mapView:rendererForOverlay::

Rendering MKGeodesicPolyline on an MKMapView

#pragma mark - MKMapViewDelegate-(MKOverlayRenderer*)mapView:(MKMapView*)mapViewrendererForOverlay:(id<MKOverlay>)overlay{if(![overlayisKindOfClass:[MKPolylineclass]]){returnnil;}MKPolylineRenderer*renderer=[[MKPolylineRendereralloc]initWithPolyline:(MKPolyline*)overlay];renderer.lineWidth=3.0f;renderer.strokeColor=[UIColorblueColor];renderer.alpha=0.5;returnrenderer;}

For comparison, here's the same geodesic overlaid with a route created from MKDirections:

As the crow flies, it's 3,983 km.
As the wolf runs, it's 4,559 km—nearly 15% longer.
...and that's just distance; taking into account average travel speed, the total time is ~5 hours by air and 40+ hours by land.

Animating an MKAnnotationView on a MKGeodesicPolyline

Since geodesics make reasonable approximations for flight paths, a common use case would be to animate the trajectory of a flight over time.

To do this, we'll make properties for our map view and geodesic polyline between LAX and JFK, and add new properties for the planeAnnotation and planeAnnotationPosition (the index of the current map point for the polyline):

@interfaceMapViewController()<MKMapViewDelegate>@propertyMKMapView*mapView;@propertyMKGeodesicPolyline*flightpathPolyline;@propertyMKPointAnnotation*planeAnnotation;@propertyNSUIntegerplaneAnnotationPosition;@end

Next, right below the initialization of our map view and polyline, we create an MKPointAnnotation for our plane:

self.planeAnnotation=[[MKPointAnnotationalloc]init];self.planeAnnotation.title=NSLocalizedString(@"Plane",nil);[self.mapViewaddAnnotation:self.planeAnnotation];[selfupdatePlanePosition];

That call to updatePlanePosition in the last line ticks the animation and updates the position of the plane:

-(void)updatePlanePosition{staticNSUIntegerconststep=5;if(self.planeAnnotationPosition+step>self.flightpathPolyline.pointCount){return;}self.planeAnnotationPosition+=step;MKMapPointnextMapPoint=self.flightpathPolyline.points[self.planeAnnotationPosition];self.planeAnnotation.coordinate=MKCoordinateForMapPoint(nextMapPoint);[selfperformSelector:@selector(updatePlanePosition)withObject:nilafterDelay:0.03];}

We'll perform this method roughly 30 times a second, until the plane has arrived at its final destination.

Finally, we implement mapView:viewForAnnotation: to have the annotation render on the map view:

-(MKAnnotationView*)mapView:(MKMapView*)mapViewviewForAnnotation:(id<MKAnnotation>)annotation{staticNSString*PinIdentifier=@"Pin";MKAnnotationView*annotationView=[mapViewdequeueReusableAnnotationViewWithIdentifier:PinIdentifier];if(!annotationView){annotationView=[[MKAnnotationViewalloc]initWithAnnotation:annotationreuseIdentifier:PinIdentifier];};annotationView.image=[UIImageimageNamed:@"plane"];returnannotationView;}

Hmm.... close but no SkyMall Personalized Cigar Case Flask.

Let's update the rotation of the plane as it moves across its flightpath.

Rotating an MKAnnotationView along a Path

To calculate the plane's direction, we'll take the slope from the previous and next points:

MKMapPointpreviousMapPoint=self.flightpathPolyline.points[self.planeAnnotationPosition];self.planeAnnotationPosition+=step;MKMapPointnextMapPoint=self.flightpathPolyline.points[self.planeAnnotationPosition];self.planeDirection=XXDirectionBetweenPoints(previousMapPoint,nextMapPoint);self.planeAnnotation.coordinate=MKCoordinateForMapPoint(nextMapPoint);

XXDirectionBetweenPoints is a function that returns a CLLocationDirection (0 – 360 degrees, where North = 0) given two MKMapPoints.

We calculate from MKMapPoints rather than converted coordinates, because we're interested in the slope of the line on the flat projection.

staticCLLocationDirectionXXDirectionBetweenPoints(MKMapPointsourcePoint,MKMapPointdestinationPoint){doublex=destinationPoint.x-sourcePoint.x;doubley=destinationPoint.y-sourcePoint.y;returnfmod(XXRadiansToDegrees(atan2(y,x)),360.0f)+90.0f;}

That convenience function XXRadiansToDegrees (and its partner, XXDegreesToRadians) are simply:

staticinlinedoubleXXRadiansToDegrees(doubleradians){returnradians*180.0f/M_PI;}staticinlinedoubleXXDegreesToRadians(doubledegrees){returndegrees*M_PI/180.0f;}

That direction is stored in a new property, @property CLLocationDirection planeDirection; , calculated from self.planeDirection = CLDirectionBetweenPoints(currentMapPoint, nextMapPoint); in updatePlanePosition (ideally renamed to updatePlanePositionAndDirection with this addition). To make the annotation rotate, we apply a transform on annotationView:

annotationView.transform=CGAffineTransformRotate(self.mapView.transform,XXDegreesToRadians(self.planeDirection));

Ah much better! At last, we have mastered the skies with a fancy visualization, worthy of any travel-related app.

Perhaps more than any other system framework, MapKit has managed to get incrementally better, little by little with every iOS release [1][2]. For anyone with a touch-and-go relationship to the framework, returning after a few releases is a delightful experience of discovery and rediscovery.

I look forward to seeing what lies on the horizon with iOS 8 and beyond.

In programming, what often begins as a necessary instruction eventually becomes a vestigial cue for humans. In the case of Objective-C, #pragma directives, method type encodings, and all but the most essential storage classes have been rendered essentially meaningless, as the compiler becomes increasingly sophisticated. Discarded and disregarded during the compilation phase, they nonetheless remain useful to the development process as a whole, insofar as what they can tell other developers about the code itself.

For developers just starting with Cocoa & Cocoa Touch, the IBAction, IBOutlet, and IBOutletCollection macros are particularly bewildering examples of this phenomenon. With their raison d'être‎ has been obscured by decades of change, confusion by anyone without sufficient context is completely understandable.

As we'll learn in this week's article, though having outgrown their technical necessity, they remain a vibrant tradition in the culture of Objective-C development.

Unlike other two-letter prefixes, IB does not refer to a system framework, but rather Interface Builder.

Interface Builder can trace its roots to the halcyon days of Objective-C, when it and Project Builder comprised the NeXTSTEP developer tools (circa 1988). Before it was subsumed into Xcode 4, Interface Builder remained remarkably unchanged from its 1.0 release. An iOS developer today would feel right at home on a NeXTSTEP workstation, control-dragging views into outlets.

Back when they were separate applications, it was a challenge to keep the object graph represented in a .nib document in Interface Builder synchronized with its corresponding .h& .m files in Project Builder (what would eventually become Xcode). IBOutlet and IBAction were used as keywords, to denote what parts of the code should be visible to Interface Builder.

IBAction and IBOutlet are, themselves, computationally meaningless, as their macro definitions (in UINibDeclarations.h) demonstrate:

#define IBAction void#define IBOutlet

Well actually, there's more than meets the eye. Scrying the Clang source code, we see that they're actually defined by attribute-backed attributes:

#define IBOutlet __attribute__((iboutlet))#define IBAction __attribute__((ibaction))

IBAction

As early as 2004 (and perhaps earlier), IBAction was no longer necessary for a method to be noticed by Interface Builder. Any method with a signature -(void){name}:(id)sender would be visible in the outlets pane.

Nevertheless, many developers find it useful to still use the IBAction return type in method declarations to denote that a particular method is connected to an outlet. Even for projects not using Storyboards / XIBs may choose to employ IBAction to call out target / action methods.

Naming IBAction Methods

Thanks to strong, and often compiler-enforced conventions, naming is especially important in Objective-C, so the question of how to name IBAction methods is one not taken lightly. Though there is some disagreement, the preferred convention is as follows:

• Return type of IBAction.
• Method name of an active verb, describing the specific action performed. Method names like didTapButton: or didPerformAction: sound more like things a delegate might be sent.
• Required sender parameter of type id. All target / action methods will pass the sender of the action (usually the responder) to methods that take a parameter. If omitted in the method signature, things will still work.
• Optional event parameter of type UIEvent *, named withEvent:(iOS only). In UIKit, a second UIEvent * parameter, corresponding to the touch, motion, or remote control event triggering the responder, will be passed to target / action methods accepting this second parameter. The convention is to use withEvent: in the method signature, to match the UIResponder APIs.

For example:

// YES-(IBAction)refresh:(id)sender;-(IBAction)toggleVisibility:(id)senderwithEvent:(UIEvent*)event;// NO-(IBAction)peformSomeAction;-(IBAction)didTapButton:(id)sender;

IBOutlet

Unlike IBAction, IBOutlet is still required for hooking up properties in code with objects in a Storyboard or XIB.

An IBOutlet connection is usually established between a view or control and its managing view controller (this is often done in addition to any IBActions that a view controller might be targeted to perform by a responder). However, an IBOutlet can also be used to expose a top-level property, like another controller or a property that could then be accessed by a referencing view controller.

When to use @property or ivar

As with anything in modern Objective-C, properties are preferred to direct ivar access. The same is true of IBOutlets:

// YES@interfaceGallantViewController : UIViewController@property(nonatomic,weak)IBOutletUISwitch*switch;@end// NO@interfaceGoofusViewController : UIViewController{IBOutletUISwitch*_switch}@end

Since properties are the conventional way to expose and access members of a class, both externally and internally, they are preferred in this case as well, if only for consistency.

When to use weak or strong

One unfortunate consequence (if you want to call it that) of ARC is the ambiguity of when a IBOutlet@property should be declared as weak or strong. The ambiguity arises from the fact that most outlets have no discernible behavioral differences between weak or strong—it just works.

...except when it doesn't... and things crash, or the compiler warns about weak or strong use.

So what should one do? Always declare IBOutlet properties as weak, except when they need to be strong, as explained by Apple in their Resource Programming Guide section on Nib Files:

Outlets should be changed to strong when the outlet should be considered to own the referenced object:

• This is often the case with File’s Owner—top level objects in a nib file are frequently considered to be owned by the File’s Owner.
• You may in some situations need an object from a nib file to exist outside of its original container. For example, you might have an outlet for a view that can be temporarily removed from its initial view hierarchy and must therefore be maintained independently.

The reason why most IBOutlet views can get away with weak ownership is that they are already owned within their respective view hierarchy, by their superview. This chain of ownership eventually works its way up to the view owned by the view controller itself. Spurious use of strong ownership on a view outlet has the potential to create a retain cycle.

IBOutletCollection

IBOutlet's obscure step-cousin-in-law-once-removed is IBOutletCollection. Introduced in iOS 4, this pseudo-keyword allows collections of IBOutlets to be defined in Interface Builder, by dragging connections to its collection members.

IBOutletCollection is #define'd in UINibDeclarations.h as:

#define IBOutletCollection(ClassName)

...which is defined in a much more satisfying way, again, in the Clang source code:

#define IBOutletCollection(ClassName) __attribute__((iboutletcollection(ClassName)))

Unlike IBAction or IBOutlet, IBOutletCollection takes a class name as an argument, which is, incidentally, as close to Apple-sanctioned generics as one gets in Objective-C.

As a top-level object, an IBOutletCollection@property should be declared strong, with an NSArray * type:

@property(nonatomic,strong)IBOutletCollection(UIButton)NSArray*buttons;

There are two rather curious things to note about an IBOutletCollection array:

• Its order is not necessarily guaranteed. The order of an outlet collection appears to be roughly the order in which their connections are established in Interface Builder. However, there are numerous reports of that order changing across versions of Xcode, or as a natural consequence of version control. Nonetheless, having code rely on a fixed order is strongly discouraged.
• No matter what type is declared for the property, an IBOutletCollection is always an NSArray. In fact, any type can be declared: NSSet *, id <NSFastEnumeration>—heck, even UIColor * (depending on your error flags)! No matter what you put, an IBOutletCollection will always be stored as an NSArray, so you might as well have that type match up in your declaration to avoid compiler warnings.

With the advent of Objective-C object literals, IBOutletCollection has fallen slightly out of favor—at least for the common use case of convenience accessors, as in:

for(UILabel*labelinlabels){label.font=[UIFontsystemFontOfSize:14];}

Since declaring a collection of outlets is now as easy as comma-delimiting them within @[], it may make just as much sense to do that as create a distinct collection.

Where IBOutletCollection really shines is how it allows for multiple to define a unique collection of outlets under a shared identifier. Another advantage over a code-defined NSArray literal is that a collection can contain outlets that themselves are not connected to File's Owner.

The next time you're managing a significant or variable number of outlets in an iOS view, take a look at IBOutletCollection.

IBAction, IBOutlet, and IBOutletCollection play important roles in development, on both the compiler level and human level. As Objective-C continues to rapidly evolve as a platform, it is likely that they may someday be as completely vestigial as the wings of flightless birds or eyes of cavefish.

For now, though, it's important to understand what they are, and how to use them, if you plan on creating apps in any capacity.

This past weekend, I had the honor of speaking at NSNorth, in Ottawa, Ontario. The conference focused on the aspects of community, culture, and family in programming, and I cannot think of a conference in recent memory that better exemplified these themes, both in its speakers and attendees.

With the help of NSNorth's organizers, Dan Byers and Philippe Casgrain, we were able to put together an NSHipster Pub Quiz. Because of time constraints, the format was a bit different than usual, with just 2 rounds instead of 4, and an activity sheet.

Nevertheless, the content was as challenging and the competition was as fierce as always, with the team led by (and named after) Jessie Char taking first place with an impressive 24 points.

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

• There are 2 Rounds and an activity sheet, with 10 questions each
• Record answers on a separate sheet of paper
• Each correct answer to a question gets you 1 point (unless otherwise specified)
• Play with up to 5 friends for maximum enjoyment
• Don't be lame and look things up on the Internet or in Xcode

Round 1: General Knowledge

Current events, miscellaneous tidbits, and random trivia. Following a time-honored traditions for NSHipster quizzes, the first round is always a mis-mash of people, places, and pop culture.

1. In 2011, Apple deprecated Mac OS X's Common Data Security Architecture, leaving them unaffected by what recent vulnerability.
2. According to rumors, Apple will be partnering with which company to add song recognition functionality to Siri in iOS 8?
3. The White House expressed disappointment over a "selfie" of Boston Red Sox player David Ortiz and President Obama, due to allegations that it was a promotional stunt for which company?
4. In Sony's forthcoming Steve Jobs biopic, which actor was recently rumored to being approached by director Danny Boyle to play the lead role? For a bonus point: which actor was previously confirmed for this role, before director David Fincher backed out of the project?
5. In Apple's Q2 Earnings call, Tim Cook announced the company had acquired 24 companies so far in 2014, including Burstly, which is better known for what service for iOS developers?
6. After a rumored $3.2 billion acquisition bid by Apple, which American record producer, rapper and entrepreneur has described himself as "the first billionaire in hip hop"? For a bonus point: what is his legal (i.e. non-stage) name?
7. A widespread (and recently debunked) rumor of Apple announcing Lightning-cable-powered biometric ear buds was originally disclosed on which social network for Silicon Valley insiders?
8. Oracle won an important victory in the U.S. Court of Appeals against Google in their suit regarding copyright claims of what?
9. What hot new social networking app allows you to anonymously chat with patrons of its eponymous, popular American chain restaurant?
10. If one were to sit down at a NeXTstation and open "/NextLibrary/Frameworks/AppKit.framework/Resources/", they would find the file "NSShowMe.tiff". Who is pictured in this photo?

Round 2: Core Potpourri

With the fluff out of the way, it's now time to dive into some hardcore Cocoa fundamentals. How well do you know the standard library?

1. What unit does a Bluetooth peripheral measure RSSI, or received signal strength intensity in?
2. What is the return value of the following code: UTTypeCreatePreferredIdentifierForTag(kUTTagClassMIMEType, @"image/jpeg", NULL)?
3. What function must be called before calling SecTrustGetCertificateCount on a SecTrustRef?
4. What UIKit class can be used to show the definition of a word?
5. An SCNetworkReachabilityRef can be created from three different sets of arguments. Fill in the blank SCNetworkReachabilityCreateWith_______. (1 pt. each)
6. mach_absolute_time() returns a count of Mach absolute time units. What function can be used to convert this into something more useful, like nanoseconds?
7. How many arguments does CGRectDivide take?
8. What function would you call to generate a random integer between 1 and N
9. What CoreFoundation function can, among other things, transliterate between different writing systems?
10. What is LLVM's logo? And, for a bonus point: What is GCC's logo?

Activity Sheet: NSAnagram

First introduced in NSHipster Quiz #4, NSAnagram has become loved and hated, in equal parts, by those who have dared to take the challenge. Each question is an anagram, whose letters can be rearranged to form the name of a class or type in a well-known system framework (hint: Foundation, CoreFoundation, CoreLocation, StoreKit, and UIKit are represented here). Good luck!

1. Farms To Rent
2. Zest On Mine!
3. A Stressful Nude
4. Non-payment Attacks, Sir!
5. Allegiant Ace, Conglomerated
6. Mental Burlesque Ruts
7. Ulcer Porn: OFF
8. Forgive Traded Crap
9. Cautionary Mini Dam
10. Coil Infatuation... Coil

Answers

Round 1: General Knowledge

1. Heartbleed
2. Shazam
3. Samsung
4. Leonardo DiCaprio, previously Christian Bale)
5. TestFlight
6. Dr. Dre, a.k.a Andre Romelle Young
7. Secret
8. Java APIs
9. WhatsApplebees
10. A young Scott Forstall

Round 2: Core Potpourri

1. decibels (dB)
2. public.jpeg
3. SecTrustEvaluate
4. UIReferenceLibraryViewController
5. Address, AddressPair, Name
6. mach_timebase_info()
7. 5
8. arc4random_uniform
9. CFStringTransform
10. LLVM's Logo is a wyvern, or dragon. GCC's Logo is an egg (with a gnu bursting out of it)

Round 3: NSAnagram

1. NSFormatter
2. NSTimeZone
3. NSUserDefaults
4. SKPaymentTransaction
5. CLLocationManagerDelegate
6. NSMutableURLRequest
7. CFRunLoopRef
8. CGDataProviderRef
9. UIDynamicAnimator
10. UILocalNotification

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

Abstractions are necessary for doing meaningful work, but they come at a cost. To work at a high level is to turn a blind eye to nonessential details in order to reason with larger logical chunks. Determining what information is important within a particular context, however, is challenging, and is at the heart of performance engineering.

By benchmarking, a programmer can uncover the hidden performance characteristics of their code, and use this information to optimize accordingly. It is an essential tool for any developer interested in making their apps faster (which is to say every self-respecting developer).

The etymology of the word "benchmark" can be traced back to 19^th century land surveying. In its original sense, a benchmark was a cut made into stone to secure a "bench", or kind of bracket, used to mount measuring equipment. Its figurative meaning of "a standard by which something is measured" was later repurposed to all walks of epistemology.

In programming, there is a minor semantic distinction between a benchmark and the act of benchmarking:

A benchmark is a program made specifically to measure and compare broad performance characteristics of hardware and software configurations. By contrast, benchmarking, is a general term for when code is used to measure the performance of a system.

Benchmarking Performance in Objective-C

Benchmarks should be treated like any other epistemological discipline, with a firm grasp of the Scientific Method as well as statistics.

The Scientific Method outlines a series of steps to logically deduce answers for questions:

1. Ask a Question
2. Construct a Hypothesis
3. Predict the Outcome
4. Test the Hypothesis
5. Analyze the Results

In the case of programming, there are generally two kinds of questions to be asked:

• What are the absolute performance characteristics of this code? Is the procedure bound by computation or memory? What is the limiting behavior across different sample sizes?
• What are the relative performance characteristics of this code, as compared to its alternatives? Which is faster, methodA or methodB?

Because the underlying factors of everything from the operating system down to the metal itself are extremely variable, performance should be measured across a large number of trials. For most applications, something on the order of 10⁵ to 10⁸ samples should be acceptable.

First Pass: CFAbsoluteTimeGetCurrent

For this example, let's take a look at the performance characteristics of adding an object to a mutable array.

To establish a benchmark, we specify a count of objects to add, and the number of iterations to run this process.

staticsize_tconstcount=1000;staticsize_tconstiterations=10000;

Since we're not testing the stack allocation of objects, we declare the object to be added to the array once, outside of the benchmark.

idobject=@"🐷";

Benchmarking is as simple as taking the time before running, and comparing it against the time after. CACurrentMediaTime() is a convenient way to measure time in seconds derived from mach_absolute_time.

Unlike NSDate or CFAbsoluteTimeGetCurrent() offsets, mach_absolute_time() and CACurrentMediaTime() are based on the internal host clock, a precise, monatomic measure, and not subject to changes in the external time reference, such as those caused by time zones, daylight savings, or leap seconds

for loops are used to increment count and iterations. Each iteration is enclosed by an @autoreleasepool, to keep the memory footprint low.

Putting it all together, here's a simple way to benchmark code in Objective-C:

CFTimeIntervalstartTime=CACurrentMediaTime();{for(size_ti=0;i<iterations;i++){@autoreleasepool{NSMutableArray*mutableArray=[NSMutableArrayarray];for(size_tj=0;j<count;j++){[mutableArrayaddObject:object];}}}}CFTimeIntervalendTime=CACurrentMediaTime();NSLog(@"Total Runtime: %g s",endTime-startTime);

The extra code block between startTime and endTime in the example below is unnecessary, but helps improve legibility and acts as a sanity check for variable scope

At this point, your NSHipster sense is probably tingling—as if to say, "Surely, there must be a better, more obscure way to do this!"

It's good to trust your instincts.

Allow me to introduce you to dispatch_benchmark.

Second Pass: dispatch_benchmark

dispatch_benchmark is part of libdispatch, a.k.a Grand Central Dispatch. Curiously, though, this function is not publicly declared, so you'll have to do that yourself:

externuint64_tdispatch_benchmark(size_tcount,void(^block)(void));

In addition to not having a public function definition, dispatch_benchmark also lacks public documentation in Xcode. Fortunately, it does have a man page:

man dispatch_benchmark(3)

The dispatch_benchmark function executes the given block multiple times according to the count variable and then returns the average number of nanoseconds per execution. This function is for debugging and performance analysis work. For the best results, pass a high count value to dispatch_benchmark.

Please look for inflection points with various data sets and keep the following facts in mind:

• Code bound by computational bandwidth may be inferred by proportional changes in performance as concurrency is increased.
• Code bound by memory bandwidth may be inferred by negligible changes in performance as concurrency is increased.
• Code bound by critical sections may be inferred by retrograde changes in performance as concurrency is increased.
  • Intentional: locks, mutexes, and condition variables.
  • Accidental: unrelated and frequently modified data on the same cache-line.

If you happened to skim all of that, be encouraged to read through that again—those are remarkably well-written docs. In addition to satisfying the prime directive of documentation of describing how to use the function, it also lays out rather comprehensive and insightful guidelines on how to best make use of the function.

Here's what the previous example looks like if we were to use dispatch_benchmark instead:

uint64_tt=dispatch_benchmark(iterations,^{@autoreleasepool{NSMutableArray*mutableArray=[NSMutableArrayarray];for(size_ti=0;i<count;i++){[mutableArrayaddObject:object];}}});NSLog(@"[[NSMutableArray array] addObject:] Avg. Runtime: %llu ns",t);

Ahhh, much better. Nanoseconds are a suitably precise time unit, and dispatch_benchmark has a much nicer syntax than manually looping and calling CFAbsoluteTimeGetCurrent().

NSMutableArray array vs. arrayWithCapacity:... FIGHT!

Now that we've settled on the preferred way to run an absolute benchmark in Objective-C, let's do a comparative test.

For this example, let's consider the age-old question of "What difference does passing a capacity parameter into collection initialization make?", or more succinctly, "to -arrayWithCapacity: or not to -arrayWithCapacity: (that is the question)".

Let's find out:

uint64_tt_0=dispatch_benchmark(iterations,^{@autoreleasepool{NSMutableArray*mutableArray=[NSMutableArrayarray];for(size_ti=0;i<count;i++){[mutableArrayaddObject:object];}}});NSLog(@"[[NSMutableArray array] addObject:] Avg. Runtime: %llu ns",t_0);uint64_tt_1=dispatch_benchmark(iterations,^{@autoreleasepool{NSMutableArray*mutableArray=[NSMutableArrayarrayWithCapacity:count];for(size_ti=0;i<count;i++){[mutableArrayaddObject:object];}}});NSLog(@"[[NSMutableArray arrayWithCapacity] addObject:] Avg. Runtime: %llu ns",t_1);

Results

Testing on an iPhone Simulator running iOS 7.1, the results are as follows:

[[NSMutableArray array] addObject:]: Avg. Runtime 26119 ns
[[NSMutableArray arrayWithCapacity] addObject:] Avg. Runtime: 24158 ns

Across a large number of samples, there is a roughly 7% performance difference between mutable arrays with and without a capacity.

Although the results are indisputable (our benchmark works beautifully), the real trick is in figuring out how to interpret these results. It would be incorrect to use this benchmark alone to conclude that passing a capacity is always a good idea. Rather, this first benchmark tells us what questions to ask next:

• What does this cost mean in absolute terms? In the spirit of avoiding premature optimization, is the difference in performance negligible in the grand scheme of things?
• What difference does changing the count of objects make? Since initial capacity is used, presumably, to prevent resizing the array as it grows, how expensive is this operation for larger values of n?
• What impact does an initial capacity have on the performance characteristics of other collection classes, like NSMutableSet or NSMutableDictionary? The public deserves an answer!

Common-Sense Benchmarking Guidelines

• Know what question you're trying to answer. Although we should always endeavor to replace magical thinking with understanding, we must protect against misappropriating scientific methodologies to support incomplete reasoning. Take time to understand what your results mean in terms of the bigger picture, before jumping to any conclusions.
• Do not ship benchmarking code in apps. Never mind the fact that dispatch_benchmark may or may not warrant an app rejection, benchmarked code has no place in a shipping product. Benchmarking should be done in separate one-off projects or an isolated test case.
• Use Instruments to gain additional insights. Knowing the absolute runtime of a series of computations is valuable, but may not offer much insight into how to make that number smaller. Use Instruments to spec the call stack and memory footprint of the code in question, in order to get a better sense of what's actually going on.
• Benchmark on the device. Just like any performance measurement, it should ultimately be done on the actual device. In most cases, general performance characteristics will be consistent between the simulator and device, but it's always worth verifying.
• Don't prematurely optimize.This cannot be stressed enough. One of the most pervasive tendencies for developers is to fixate on what they perceive to be "slow code", before there's any real evidence to support that. Even for veteran developers, it's very easy to incorrectly predict where bottlenecks will be in an application. Don't waste your time chasing shadows. Let Instruments show you where your app is spending most of its time.

Richard Feynman once likened experiments in particle physics to "[finding] out what a watch is made out of and how the mechanism works [by] smashing two watches together and seeing what kinds of gear wheels fly out". Benchmarking code can feel like this at times.

With so many implementation details of our computational universe hidden to us through layers of abstraction, sometimes the best we can do to try to understand what's at play is to magnify code by a few orders of magnitude and see what we get.

Through a disciplined application of science and statistics in benchmarking, a developer is able to create well-reasoned conclusions about the performance characteristics of their code. Apply these principles and practices in your own project to come to your own conclusions and optimize accordingly.

Civilization is built on infrastructure: roads, bridges, canals, sewers, pipes, wires, fiber. When well thought-out and implemented, infrastructure is a multiplying force that drives growth and development. But when such formative structures are absent or ad hoc, it feels as if progress is made in spite of the situation.

It all has to do with solving the problem of scale.

No matter what the medium, whether it's accommodating millions of families into a region, or integrating a large influx of developers into a language ecosystem, the challenges are the same.

In the case of Objective-C, CocoaPods provided a much-needed tool for channeling and organizing open source participation, and served as a rallying point for the community at a time of rapid growth and evolution.

This week on NSHipster, we'll celebrate the launch of CocoaPods 0.33, an important milestone for the project, by taking a look back at where we came from, discussing where we are now, and thinking about what's to come.

The following historical look at the origins of CocoaPods is, admittedly, a bit wordy for this publication. So if you're looking for technical details, feel free to skip directly to that.

A Look Back

For the first twenty or so years of its existence, Objective-C was not a widely known language. NeXT and later OS X were marginal platforms, with a comparatively small user base and developer community. Like any community, there were local user groups and mailing lists and websites, but open source collaboration was not a widespread phenomenon. Granted, Open Source was only just starting to pick up steam at that time, but there was no contemporary Objective-C equivalent to, for example, CPAN, the Comprehensive Perl Archive Network. Everyone took SDKs from Redwood City and Cupertino as far as they could, (maybe sprinkling in some code salvaged from a forum thread), but ultimately rolling their own solutions to pretty much everything else.

Objective-C and the iPhone

This went on until the summer of 2008, when iPhone OS was first opened up to third party developers. Almost overnight, Objective-C went from being an obscure C++/C# also-ran to the one of the most sought-after programmer qualifications. Millions of developers flocked from all walks of code, bringing an influx of new ideas and influences to the language.

Around this same time, GitHub had just launched, and was starting to change the way we thought about open source by enabling a new distributed, collaborative workflow.

In those early years of iPhone OS, we started to see the first massively adopted open source projects, like ASIHTTPRequest and Facebook's Three20. These first libraries and frameworks were built to fill in the gaps of app development on iPhone OS 2.0 and 3.0, and although largely made obsolete by subsequent OS releases or other projects, they demonstrated a significant break from the tradition of "every developer for themselves".

Of this new wave of developers, those coming from a Ruby background had a significant influence on the code and culture of Objective-C. Ruby, a spiritual successor to Perl, had its own package manager similar to CPAN: RubyGems.

Why so much influence from Ruby? Here's my pet theory: Ruby started gaining popular traction because of Rails, which hit 1.0 at the end of 2005. Given that the average duration of a startup gig seems to be about 1½ – 2½ years, the timing works out such that those first and second waves of bored Rails developers itching to jump ship would find a place in the emerging app space.

As open source contributions in Objective-C began to get some traction, the pain points of code distribution were starting to become pretty obvious:

Lacking frameworks, code for iOS could be packaged as a static library, but getting that set up and keeping code and static distributions in sync was an arduous process.

Another approach was to use Git submodules, and include the source directly in the project. But getting everything working, with linked frameworks and build flags configured, was not great either—especially at a time when the body of code was split between ARC and non-ARC.

Enter CocoaPods

CocoaPods was created by Eloy Durán on August 12, 2011.

Taking inspiration from Bundler and RubyGems, CocoaPods was designed to resolve a list of dependencies, download the required sources, and configure the existing project in such a way to be able to use them. Considering the challenges of working with a sparsely documented Xcode project format and build system, it's kind of a miracle that this exists at all.

Another notable decision made early on was to use a central Git repository as the database for all of the available libraries. Although there were certain logistical considerations with this approach, bootstrapping on GitHub provided a stable infrastructure, that allowed the team to iterate on building out the tool chain.

Since its initial proof-of-concept, the project has grown to include 14 core team members along with over 100 additional contributors. At the time of writing, there are nearly 5000 open source projects available for anyone to add to their project.

A significant portion of these prolific contributions from the open source community for Objective-C has been directly enabled and encouraged by increased ownership around tooling. Everyone involved should be commended for their hard work and dedication.

To break the 4th wall for a moment: Seriously, thank you, ladies and gentlemen of CocoaPods. You've done an amazing job. Keep up the good work!

Using CocoaPods

CocoaPods is easy to get started with both as a consumer and a library author. It should only take a few minutes to get set up.

For the most up-to-date information on how to use CocoaPods, check out the official guides.

Installing CocoaPods

CocoaPods is installed through RubyGems, the Ruby package manager, which comes with a standard Mac OS X install.

To install, open Terminal.app and enter the following command:

$ sudo gem install cocoapods

Now you should have the pod command available in the terminal.

If you're using a Ruby versioning manager, like rbenv, you may need to run a command to re-link a binary shim to the library (e.g. $ rbenv rehash).

Managing Dependencies

A dependency manager resolves a list of software requirements into a list of specific tags to download and integrate into a project.

Declaring requirements in such a way allows for project setup to be automated, which is general best practice for software development practice, no matter what the language. Even if you don't include third-party libraries, CocoaPods is still an invaluable tool for managing code dependencies across projects.

Podfile

A Podfile is where the dependencies of a project are listed. It is equivalent to Gemfile for Ruby projects using Bundler, or package.json for JavaScript projects using npm.

To create a Podfile, cd into the directory of your .xcodeproj file and enter the command:

$ pod init

Podfile

platform:ios,'7.0'target"AppName"doend

Dependencies can have varying levels of specificity. For most libraries, pegging to a minor or patch version is the safest and easiest way to include them in your project.

pod'X','~> 1.1'

CocoaPods follows Semantic Versioning conventions.

To include a library not included in the public specs database, a Git, Mercurial, or SVN repository can be used instead, for which a commit, branch, or tag can be specified.

pod'Y',:git=>'https://github.com/NSHipster/Y.git',:commit=>'b4dc0ffee'

Once all of the dependencies have been specified, they can be installed with:

$ pod install

When this is run, CocoaPods will recursively analyze the dependencies of each project, resolving them into a dependency graph, and serializing into a Podfile.lock file.

For example, if two libraries require AFNetworking, CocoaPods will determine a version that satisfies both requirements, and links them with a common installation of it.

CocoaPods will create a new Xcode project that creates static library targets for each dependency, and then links them all together into a libPods.a target. This static library becomes a dependency for your original application target. An xcworkspace file is created, and should be used from that point onward. This allows the original xcodeproj file to remain unchanged.

Subsequent invocations of pod install will add new pods or remove old pods according to the locked dependency graph. To update the individual dependencies of a project to the latest version, do the following:

$ pod update

Trying Out a CocoaPod

One great, but lesser-known, feature of CocoaPods is the try command, which allows you to test-drive a library before you add it to your project.

Invoking $ pod try with the name of a project in the public specs database opens up any example projects for the library:

$ pod try Ono

Creating a CocoaPod

Being the de facto standard for Objective-C software distribution, CocoaPods is pretty much a requirement for open source projects with the intention of being used by others

Yes, it raises the barrier to entry for sharing your work, but the effort is minimal, and more than justifies itself. Taking a couple minutes to create a .podspec file saves every user at least that much time attempting to integrate it into their own projects.

Remember: raising the bar for contribution within a software ecosystem lowers the bar for participation.

Specification

A .podspec file is the atomic unit of a CocoaPods dependency. It specifies the name, version, license, and source files for a library, along with other metadata.

The official guide to the Podfile has some great information and examples.

NSHipsterKit.podspec

Pod::Spec.newdo|s|s.name='NSHipsterKit's.version='1.0.0's.license='MIT's.summary="A pretty obscure library.                You've probably never heard of it."s.homepage='http://nshipster.com's.authors={'Mattt Thompson'=>'mattt@nshipster.com'}s.social_media_url="https://twitter.com/mattt"s.source={:git=>'https://github.com/nshipster/NSHipsterKit.git',:tag=>'1.0.0'}s.source_files='NSHipsterKit'end

Once published to the public specs database, anyone could add it to their project, specifying their Podfile thusly:

Podfile

pod'NSHipsterKit','~> 1.0'

A .podspec file can be useful for organizing internal or private dependencies as well:

pod'Z',:path=>'path/to/directory/with/podspec'

Publishing a CocoaPod

New in CocoaPods 0.33 is the new Trunk service.

Although it worked brilliantly at first, the process of using Pull Requests on GitHub for managing new pods became something of a chore, both for library authors and spec organizers like Keith Smiley. Sometimes podspecs would be submitted without passing $ pod lint, causing the specs repo build to break. Other times, rogue commits from people other than the original library author would break things unexpectedly.

The CocoaPods Trunk service solves a lot of this, making the process nicer for everyone involved. Being a centralized service, it also has the added benefit of being able to get analytics for library usage, and other metrics.

To get started, you must first register your machine with the Trunk service. This is easy enough, just specify your email address (the one you use for committing library code) along with your name.

$ pod trunk register mattt@nshipster.com "Mattt Thompson"

Now, all it takes to publish your code to CocoaPods is a single command. The same command works for creating a new library or adding a new version to an existing one:

$ pod trunk push NAME.podspec

Authors of existing CocoaPods can claim their libraries with a few simple steps.

A Look Forward

CocoaPods exemplifies the compounding effect of infrastructure on a community. In a few short years, the Objective-C community has turned into something that we can feel proud to be part of.

CocoaPods is just one example of the great work being done on Objective-C infrastructure. Other community tools, like Travis CI, CocoaDocs, and Nomad have dramatically improved the everyday experience iOS and Mac OS X development for the community.

It can be tempting to be snarky, contrarian, or grumpy about the direction of a community. No matter what, though, let us all try our best to enter into dialogue in good faith, offering constructive criticism where we can. We should help each other to be good stewards of what we share, and strive towards empathy in all our interactions.

CocoaPods is a good thing for Objective-C. And it's only getting better.

Today's a big day for NSHipster, and I have some important and exciting news to share.

Before I get into all of that, though, I wanted to thank everyone for their enthusiasm about CFHipsterRef, and NSHipster in general. Thank you for your kind words and encouragement. It's such a pleasure to write for y'all each and every week.

Okay, so some updates:

Digital / Physical Edition Questions

A number of you have contacted me with some confusion about whether the pre-order was for the physical or digital editions. To be clear: the pre-order is for a digital copy only. A print edition will be available for purchase on Amazon in the coming weeks.

I wrote about this briefly in a recent post, but the reality is that the logistics of shipping to over 50 countries internationally was a bit over my head, so this time, I'm going to just leave it to Amazon.

Although this was spelled out in the product listing, I can completely understand how one might be confused. As such, I'm going to hold off on pushing through any pre-orders until everyone has a chance to cancel their pre-order, if they want. After that time, charges will go through, and you'll receive your digital copy of CFHipsterRef.

Beta Release

WWDC is right around the corner, so there is a high likelihood that some information will be outdated come next week. Therefore, CFHipsterRef will be initially released as a beta book, with updates as information is added and corrected. I'm aiming to have a final version ready for print by the end of the month.

Wait... Another Book?

Here's where the narrative goes a little, well, off-book.

Today, I'm announcing the release of another title: "The NSHipster Fake Book", which is now available for download.

Everyone who pre-ordered "CFHipsterRef" received a free copy of "The NSHipster Fake Book", as a way to say thanks for their continued support of NSHipster. I will honor this for any new or cancelled pre-orders, as well. (For new pre-orders, you can expect an email with a promo code within a few hours).

I intended for both books to go out at the same time, but with the hold on pre-order charges, I hope that this will help tide you over until CFHipsterRef is pushed out.

tl;dr

• The pre-order period for "CFHipsterRef" has been extended to give anyone who might have been confused about distribution the opportunity to cancel their digital pre-order, if they want.
• "CFHipsterRef" will be released initially as a Beta book, with the final edition coming out after WWDC.
• Everyone who pre-ordered "CFHipsterRef" will receive a free copy of the "The NSHipster Fake Book".

Sorry for the confusion and inconvenience. It's been a chaotic couple of weeks for me, so please bear with me on this.

If you have any questions at all about your purchase, do not hesitate to get in touch.

On June 3rd, we organized the second annual WWDC edition of the NSHipster Pub Quiz. Keeping in its tradition, questions ranged from random Apple trivia to obscure technical questions. For the second year in a row, the event was graciously hosted by New Relic, whose beautiful downtown San Francisco offices gave the event a feeling of distinction and class. We're also very thankful to Spotify& thoughtbot sponsor libations for the evening. Cheers!

With dozens of teams, comprised of developers from all around the world, the competition was fierce. But ultimately, it was a team known simply as nil that took the day, with 54 points total.

For everyone that couldn't make it to the event, here's an opportunity to play along at home. Some ground rules:

• There are 3 Rounds, with 10 questions each
• Record answers on a separate sheet of paper
• Each correct answer to a question gets you 1 point (unless otherwise specified)
• Play with up to 5 friends for maximum enjoyment
• Don't be lame and look things up on the Internet or in Xcode

Round 1: General Knowledge

Current events, miscellaneous tidbits, and random trivia. Following a time-honored traditions for NSHipster quizzes, the first round is always a mis-mash of people, places, and pop culture.

1. On iOS 8, what magic phrase can be used to activate Siri, when the device is plugged in?
2. What game, crestfallen by the runaway success of its clone, 2048, was at least slightly vindicated last night with an ADA win?
3. Which alternative search engine was added to the latest release of Safari?
4. Weeks after its announcement, Apple finally confirmed its $3B acquisition of Beats Electronics. What is the name of Dre’s Co-founder?
5. Yosemite is, of course, the code name of Mac OS X 10.10, but this code name was used before. What was the product? (Hint: It was released in 1999 and had a top clock speed of 450MHz)
6. What is the name of the valley in Yosemite that was flooded after construction of the O'Shaughnessy Dam in 1927, which provides drinking water to San Francisco?
7. Much of the reason why Yosemite exists today is thanks to the Sierra Club and a Scottish-born naturalist. What is this gentleman's name?
8. 20 years ago, Apple launched a new experimental language. It had a syntax like this: let x :: <integer> = 2;. What was this language’s name?
9. What does a Swift eat?
10. What is the birdwatching term for the overall impression or appearance of a bird based on its shape, posture, & flying style?

Round 2: So You Think You Can Swift?

Having only been introduced the day before, Swift was fresh on everyone's minds, and the hot topic of conversation. To put everyone's knowledge to the test, the following 10 exercises were posed to attendees.

For anyone revisiting this quiz months or years after the fact, this should be incredibly easy. But just imagine coming into these questions having only skimmed a few hundred pages of the Swift iBook (if at all). And now imagine that you're a beer and a half into a late night during the week of WWDC. Now you can start to appreciate how grumpy this round made a lot of people.

1. Declare a constant d equal to 3.0.
2. Declare a variable s of type String.
3. Interpolate the value of d into a String literal.
4. Set a var b to 28 using an octal literal.
5. Declare an optional property of type Int named x.
6. Declare a Highlander enum of type Int, with an element named "One".
7. Override viewDidLoad in a UIViewController Subclass.
8. Declare a class C that adopting the NSCoding protocol.
9. Alias String as Rope.
10. Declare a protocol method m, which returns both an Int, and a Dictionary, with String keys and any value.

Round 3: Music Round

Rounding out the competition was the venerable staple of pub trivia everywhere: the music round!

The theme of this music round is—you guessed it—songs used in Apple commercials. For each song, score yourself a point for the correct title, artist, and Apple product advertised.

Due to the peculiarities of embedded video, you may have to click through in order to hear the song. Don't worry—the link is to the song itself, not the Apple ad, so you'll at least have something to puzzle over.

Answers

Round 1: General Knowledge

1. "Hey Siri"
2. Threes
3. DuckDuckGo
4. Jimmy Iovine
5. Power Macintosh G3 (Blue & White)
6. Hetch Hetchy
7. John Muir
8. Dylan
9. Insects
10. Jizz

Round 2: So You Think You Can Swift?

1. let d = 3.0
2. var s: String
3. "\(d)"
4. var b = 0o34
5. var x: Int?
6. enum Highlander: Int { case One = 1}
7. override func viewDidLoad() { ... }
8. class C: NSCoding
9. typealias Rope = String
10. func m() -> (Int, Dictionary<String,Any>)

Round 3: Music Round

1. iPod 3G: Jet — "Are You Gonna Be My Girl?"
2. G4 Cube: The Jimi Hendrix Experience — "Purple Haze"
3. iPod Shuffle: Caesars — "Jerk It Out"
4. iTunes: Green Day — "I Fought The Law"
5. iPod 4G (U2 Special Edition): U2 — "Vertigo"
6. Mac OS X (First-Run Experience): Honeycut — "Exodus Honey"
7. iPod 1G: The Propellerheads — "Take California"
8. iPhone 5s: Pixies — "Gigantic"
9. iBook: Miles Davis — "Flamenco Sketches" (with voiceover by Jeff Goldblum)
10. iMac "Sage": Kermit The Frog — "(It’s Not Easy) Bein' Green"

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

Ask anyone, and they'll tell you: WWDC 2014 was the one of the most exciting in recent memory. It was, first and foremost, a developer event, with nary a hardware announcement to upstage the latest software & developer tools.

And boy howdy, was there a lot to be excited about.

The announcements from iOS 8 & OS X Yosemite alone would have made 2014 a bellwether year for the Apple platform, with Extensions, Continuity, SpriteKit enhancements, SceneKit for iOS, Metal, Game HealthKit, HomeKit, Local Authentication, and a brand new Photos framework. Not to mention the dramatic improvements to Xcode & Interface Builder, a revamped iTunes Connect, TestFlight, Crash Reports, and CloudKit. And oh yeah—Swift.

The kicker? Apple has graciously relaxed its NDA for new technologies, meaning that we don't have to wait to talk about all of the shiny new toys we have to play with.

This week, we'll take a look beneath the headline features, and share some of the more obscure APIs that everyone should know about.

From here on out, NSHipster will primarily write code samples in Swift, with the occasional Objective-C throwback where appropriate. By the end of the summer, we hope to have all of the existing code samples ported to Swift, with the option to toggle between languages.

NSProcessInfo -isOperatingSystemAtLeastVersion

Forget [[UIDevice currentDevice] systemVersion] and NSFoundationVersionNumber, there's a new way to determine the current operating system in code: NSProcessInfo -isOperatingSystemAtLeastVersion

importFoundationletyosemite=NSOperatingSystemVersion(majorVersion:10,minorVersion:10,patchVersion:0)NSProcessInfo().isOperatingSystemAtLeastVersion(yosemite)// false

Keep in mind, however, that a test for capability, such as with SomeClass.class or respondsToSelector:, is preferable to checking the OS version. Compiler macros in C or Swift can be used to conditionally compile source based on the build configuration of the target.

New NSFormatter Subclasses

One the features most sorely lacking in Foundation was the ability to work with units for quantities like mass or length. In iOS 8 and OS X Yosemite, three new classes were introduced that fills the gap: NSEnergyFormatter, NSMassFormatter, & NSLengthFormatter.

This effectively doubles the number of NSFormatter subclasses in Foundation, which was previously limited to NSNumberFormatter, NSDateFormatter, & NSByteCountFormatter.

Although these new formatter classes are part of Foundation, they were added primarily for use in HealthKit.

NSEnergyFormatter

NSEnergyFormatter formats energy in Joules, the raw unit of work for exercises, and Calories, which is used when working with nutrition information.

letenergyFormatter=NSEnergyFormatter()energyFormatter.forFoodEnergyUse=trueletjoules=10_000.0println(energyFormatter.stringFromJoules(joules))// "2.39 Cal"

NSMassFormatter

Although the fundamental unit of physical existence, mass is pretty much relegated to tracking the weight of users in HealthKit. Yes, mass and weight are different, but this is programming, not science class, so stop being pedantic.

letmassFormatter=NSMassFormatter()letkilograms=60.0println(massFormatter.stringFromKilograms(kilograms))// "132 lb"

NSLengthFormatter

Rounding out the new NSFormatter subclasses is NSLengthFormatter. Think of it as a more useful version of MKDistanceFormatter, with more unit options and formatting options.

letlengthFormatter=NSLengthFormatter()letmeters=5_000.0println(lengthFormatter.stringFromMeters(meters))// "3.107 mi"

CMPedometer

Continuing on iOS 8's health kick, CMStepCounter is revamped in the latest release. CMPedometer is a strict improvement over its predecessor, with the ability to query from discrete points in time, track both steps and distance, and even calculate how many flights of stairs were climbed.

It's amazing what that M7 chip is capable of.

importCoreMotionletlengthFormatter=NSLengthFormatter()letpedometer=CMPedometer()pedometer.startPedometerUpdatesFromDate(NSDate(),withHandler:{data,errorinif!error{println("Steps Taken: \(data.numberOfSteps)")letdistance=data.distance.doubleValueprintln("Distance: \(lengthFormatter.stringFromMeters(distance))")lettime=data.endDate.timeIntervalSinceDate(data.startDate)letspeed=distance/timeprintln("Speed: \(lengthFormatter.stringFromMeters(speed)) / s")}})

CMAltimeter

On supported devices, a CMPedometer's stats on floorsAscended / floorsDescended can be augmented with CMAltimeter to get a more granular look at vertical distance traveled:

importCoreMotionletaltimeter=CMAltimeter()ifCMAltimeter.isRelativeAltitudeAvailable(){altimeter.startRelativeAltitudeUpdatesToQueue(NSOperationQueue.mainQueue(),withHandler:{data,errorinif!error{println("Relative Altitude: \(data.relativeAltitude)")}})}

CLFloor

CLFloor is a new API in iOS 8 that ties the new features in CoreMotion with Apple's ambitious plan to map the interiors of the largest buildings in the world. Look for this information to play a significant role in future hyperlocal mapping applications.

importCoreLocationclassLocationManagerDelegate:NSObject,CLLocationManagerDelegate{funclocationManager(manager:CLLocationManager!,didUpdateLocationslocations:AnyObject[]!){letlocation:CLLocation?=locations[0]as?CLLocationifletfloor:CLFloor?=location?.floor{println("Current Floor: \(floor?.level)")}}}letmanager=CLLocationManager()manager.delegate=LocationManagerDelegate()manager.startUpdatingLocation()

HKStatistics

As a framework, HealthKit covers a lot of ground, with dozens of new classes and constants. A good place to start, in terms of understanding what's possible is HKStatistics.

HealthKit manages your biometrics from all of your devices in a single unified API. Statistics on things like heart rate, caloric intake, and aerobic output can be tracked and aggregated in powerful ways.

The following example shows how statistics summed over the duration of the day can be grouped and interpreted individually:

importHealthKitletcollection:HKStatisticsCollection?=...letstatistics:HKStatistics?=collection!.statisticsForDate(NSDate())foritem:AnyObjectinstatistics!.sources{ifletsource=itemas?HKSource{ifletquantity:HKQuantity=statistics!.sumQuantityForSource(source){ifquantity.isCompatibleWithUnit(HKUnit.gramUnitWithMetricPrefix(.Kilo)){letmassFormatter=NSMassFormatter()letkilograms=quantity.doubleValueForUnit(HKUnit.gramUnitWithMetricPrefix(.Kilo))println(massFormatter.stringFromKilograms(kilograms))}ifquantity.isCompatibleWithUnit(HKUnit.meterUnit()){letlengthFormatter=NSLengthFormatter()letmeters=quantity.doubleValueForUnit(HKUnit.meterUnit())println(lengthFormatter.stringFromMeters(meters))}ifquantity.isCompatibleWithUnit(HKUnit.jouleUnit()){letenergyFormatter=NSEnergyFormatter()letjoules=quantity.doubleValueForUnit(HKUnit.jouleUnit())println(energyFormatter.stringFromJoules(joules))}}}}

NSHipster will be covering a lot more about HealthKit in future editions, so stay tuned!

NSStream +getStreamsToHostWithName

In many ways, WWDC 2014 was the year that Apple fixed their shit. Small things, like adding the missing NSStream initializer for creating a bound stream pair (without resorting to awkwardly-bridged CFStreamCreatePairWithSocketToHost call). Behold: +[NSStream getStreamsToHostWithName:port:inputStream:outputStream:]

varinputStream:NSInputStreamvaroutputStream:NSOutputStreamNSStream.getStreamsToHostWithName(hostname:"nshipster.com",port:5432,inputStream:&inputStream,outputStream:&outputStream)

NSString -localizedCaseInsensitiveContainsString

Also filed under: "small but solid fixes", is this convenience method for NSString:

letstring:NSString="Café"letsubstring:NSString="É"string.localizedCaseInsensitiveContainsString(substring)// true

CTRubyAnnotationRef

If you're a linguistics and typography nerd, this new addition to the CoreText framework may have you standing up on your chair and cheering. "What's with Jim? Is it me, or has he been acting kind of weird since his trip to San Francisco?", they'll say, looking at you atop your desk as you tear your clothes off your body in a frenzy of pure ecstasy. "Yeah, remind me not to stay in the Tenderloin for next year's conference."

...oh right. Ruby. No, not Ruby. Ruby. It's used to display the pronunciation of characters in certain Asian scripts.

@importCoreText;NSString*kanji=@"猫";NSString*hiragana=@"ねこ";CFStringReffurigana[kCTRubyPositionCount]={(__bridgeCFStringRef)hiragana,NULL,NULL,NULL};CTRubyAnnotationRefruby=CTRubyAnnotationCreate(kCTRubyAlignmentAuto,kCTRubyOverhangAuto,0.5,furigana);

Admittedly, the documentation isn't entirely clear on how exactly to incorporate this into the rest of your CoreText drawing calls, but the result would look something like this:

猫ねこ

New Calendar Identifiers

What's even nerdier than Ruby annotations? The new calendar identifiers added to iOS 8 & OS X Yosemite. This update brings Foundation up to the latest version of the CLDR:

(Sadly, the French Republican Calendar is still but a twinkle in the eyes of NSHipsters everywhere)

• NSCalendarIdentifierCoptic: a.k.a Alexandrian calendar, is used by the Coptic Orthodox Church.
• NSCalendarIdentifierEthiopicAmeteMihret: Ethiopic calendar, Amete Mihret (epoch approx. 8 C.E.)
• NSCalendarIdentifierEthiopicAmeteAlem: Ethiopic calendar, Amete Alem (epoch approx. 5493 B.C.E.)
• NSCalendarIdentifierIslamicTabular: A simple tabular Islamic calendar using the astronomical/Thursday epoch of CE 622 July 15.
• NSCalendarIdentifierIslamicUmmAlQura: The Islamic Umm al-Qura calendar used in Saudi Arabia. This is based on astronomical calculation, instead of tabular behavior.

NSURLCredentialStorage

The Foundation URL Loading System has remained relatively unchanged since last year's NSURLSession blowout. However, NSURLCredentialStorage has been given some TLC, with new functions that get and set credentials for tasks in asynchronous, non-blocking fashion.

importFoundationletsession=NSURLSession()lettask=session.dataTaskWithURL(NSURL(string:"http://nshipster.com"),completionHandler:{data,response,errorin// ...})letprotectionSpace=NSURLProtectionSpace()NSURLCredentialStorage.getCredentialsForProtectionSpace(protectionSpace:protectionSpace,task:task,completionHandler:{credentialsin// ...})

kUTTypeToDoItem

Looking through the latest API diffs, one might notice the large number of new UTIs constants. One that caught my eye was kUTTypeToDoItem:

importMobileCoreServiceskUTTypeToDoItem// "public.to-do-item"

As a public type, iOS & OS X now provide a unified way to share tasks between applications. If you happen to work on a task management tool (and, let's be honest, the chances are extremely good, considering how damn many of them there are in the App Store), proper integration with this system type should be put at the top of your list.

kCGImageMetadataShouldExcludeGPS

Most users are completely unaware that most pictures taken with phones these days include GPS metadata. Countless individuals have had their privacy breached because of this small detail.

New to the Image I/O framework is a convenient new option for CGImageDestination: kCGImageMetadataShouldExcludeGPS, which does what you'd expect.

@importUIKit;@importImageIO;@importMobileCoreServices;UIImage*image=...;NSURL*fileURL=[NSURLfileURLWithPath:@"/path/to/output.jpg"];NSString*UTI=kUTTypeJPEG;NSDictionary*options=@{(__bridgeid)kCGImageDestinationLossyCompressionQuality:@(0.75),(__bridgeid)kCGImageMetadataShouldExcludeGPS:@(YES),};CGImageDestinationRefimageDestinationRef=CGImageDestinationCreateWithURL((__bridgeCFURLRef)fileURL,(__bridgeCFStringRef)UTI,1,NULL);CGImageDestinationAddImage(imageDestinationRef,[imageCGImage],(__bridgeCFDictionaryRef)options);CGImageDestinationFinalize(imageDestinationRef);CFRelease(imageDestinationRef);

WTF_PLATFORM_IOS

#define WTF_PLATFORM_IOS has been removed from JavaScriptCore. It will be missed.

WKWebView

UIWebView is dead. Long live WKWebView.

WKWebView offers Safari-level performance to your own app, and further improves on UIWebView with preferences and configurations:

importWebKitletpreferences=WKPreferences()preferences.javaScriptCanOpenWindowsAutomatically=falseletconfiguration=WKWebViewConfiguration()configuration.preferences=preferencesletwebView=WKWebView(frame:self.view.bounds,configuration:configuration)letrequest=NSURLRequest(URL:NSURL(string:"http://nshipster.com"))webView.loadRequest(request)

NSQualityOfService

Threads have been systematically de-emphasized from the conceptual foundation of Apple frameworks. This has been a good thing for developers.

Following this trend is a change to NSOperation in the latest APIs. A new qualityOfService property replaces the threadPriority. These new semantics allow an app to defer non-critical work to ensure a consistently great user experience.

The NSQualityOfService enum defines the following values:

• UserInteractive: UserInteractive QoS is used when performing work that is related to graphically intensive work such as scrolling or animating.
• UserInitiated: UserInitiated QoS is used for performing work that has been explicitly requested by the user, but does not require millisecond accuracy like animations. For example, if a user requests an email app to check for mail right now.
• Utility: Utility QoS is used for performing work that has been requested by the user to happen automatically. For example, an email app may be configured to automatically check for mail every 5 minutes. It is not a problem if the email check is deferred by a few minutes if the system is extremely limited in resources.
• Background: Background QoS is used for performing work that the user may not even be aware is happening on their behalf. For example, an email app may use this to perform indexing for a search.

Quality of Service is used throughout Foundation in iOS 8 & OS X Yosemite, so be on the lookout for opportunities to capitalize on this new feature.

LocalAuthentication

Finally, one of the most anticipated features of iOS 8: LocalAuthentication. Ever since TouchID was introduced with the iPhone 5s, developers have been salivating at the prospect of using that in their own app.

Imagine: with CloudKit and LocalAuthentication, nearly all of the friction to creating a user account is gone. Just scan your fingerprint, and you're in.

LocalAuthentication works in terms of an LAContext class, which evaluates a specified policy, and gives a thumbs up or thumbs down on user authentication. At no point is any biometric information made available to the application—everything is kept safe on the hardware itself.

LAContext*context=[[LAContextalloc]init];NSError*error=nil;if([contextcanEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometricserror:&error]){[contextevaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometricslocalizedReason:NSLocalizedString(@"...",nil)reply:^(BOOLsuccess,NSError*error){if(success){// ...}else{NSLog(@"%@",error);}}];}else{NSLog(@"%@",error);}

Although it seems like all that anyone can talk about these days is Swift, it'd be a shame if we ignored all of the neat things iOS 8 & OS X Yosemite allow us to actually do with this new language.

If you're feeling adventurous, dive into the iOS 7.1 to 8.0 API diffs to really appreciate the magnitude of new technologies to discover. Granted, of the 4000+ new APIs, at least half of those are slight changes to Accelerate functions or methods becoming properties, but still... Have at it!

Diagnostics combine logic with analytics to arrive at a conclusion. It's science and engineering at their purest. It's human reasoning at its most potent.

Within the medical profession, a diagnosis is made through instinct backed by lab samples. For industrial manufacturing, one diagnoses a product fault through an equal application of statistics and gumption.

For us developers, our medium of code informs the production of subsequent code, creating a positive feedback loop that has catapulted the development of technology exponentially over the last half century. For us Objective-C developers specifically, the most effective diagnostics come from Clang.

Clang is the C / Objective-C front-end to the LLVM compiler. It has a deep understanding of the syntax and semantics of Objective-C, and is much of the reason that Objective-C is such a capable language today.

That amazing readout you get when you "Build & Analyze" (⌘⇧B) is a function of the softer, more contemplative side of Clang: its code diagnostics.

In our article about #pragma, we quipped:

Pro tip: Try setting the -Weverything flag and checking the "Treat Warnings as Errors" box your build settings. This turns on Hard Mode in Xcode.

Now, we stand by this advice, and encourage other developers to step up their game and treat build warnings more seriously. However, there are some situations in which you and Clang reach an impasse. For example, consider the following switch statement:

switch(style){caseUITableViewCellStyleDefault:
    caseUITableViewCellStyleValue1:
    caseUITableViewCellStyleValue2:
    caseUITableViewCellStyleSubtitle:
        // ...default:return;}

When certain flags are enabled, Clang will complain that the "default label in switch which covers all enumeration values". However, if we know that, zooming out into a larger context, style is (for better or worse) derived from an external representation (e.g. JSON resource) that allows for unconstrained NSInteger values, the default case is a necessary safeguard. The only way to insist on this inevitability is to use #pragma to ignore a warning flag temporarily:

push& pop are used to save and restore the compiler state, similar to Core Graphics or OpenGL contexts.

#pragma clang diagnostic push#pragma clang diagnostic ignored "-Wcovered-switch-default"switch(style){caseUITableViewCellStyleDefault:
    caseUITableViewCellStyleValue1:
    caseUITableViewCellStyleValue2:
    caseUITableViewCellStyleSubtitle:
        // ...default:return;}#pragma clang diagnostic pop

Again, and this cannot be stressed enough, Clang is right at least 99% of the time. Actually fixing an analyzer warning is strongly preferred to ignoring it. Use #pragma clang diagnostic ignored as a method of last resort.

The problem is that given a warning string, it is very difficult to determine what its corresponding warning flag is. Unless a random Stack Overflow question pops up for the given error string, you're pretty much out of luck.

So this week, as a public service, we've compiled a (mostly) comprehensive list of Clang warning strings and their associated flags:

Like our article on NSError, this is more of an article for future reference than a formal explanation. Keep this page bookmarked for the next time that you happen to run into this situation.

Clang Diagnostic Warning Flags & Messages

Lex (liblex)

Parse (libparse)

Semantic (libsema)

Corrections? Additions? Open a Pull Request to submit your change. Any help would be greatly appreciated.

NSHipster.com was launched 2 years ago to the day, with a little article about NSIndexSet. Each week since has featured a new article on some obscure topic in Objective-C or Cocoa (with only a couple gaps), which have been read by millions of visitors in over 180 different countries.

This is actually the 101st article, which means that by television industry standards, this site is now suitable for broadcast syndication. (Coming soon to TBS!)

Let's celebrate with some cake:

Cute, right? Let's see what this looks like in code:

varcakePath=UIBezierPath()cakePath.moveToPoint(CGPointMake(31.5,32.5))cakePath.addCurveToPoint(CGPointMake(6.5,66.1),controlPoint1:CGPointMake(31.5,32.5),controlPoint2:CGPointMake(6.9,46.3))cakePath.addCurveToPoint(CGPointMake(6.5,66.5),controlPoint1:CGPointMake(6.5,66.2),controlPoint2:CGPointMake(6.5,66.3))cakePath.addLineToPoint(CGPointMake(6.5,95))...

Wait, hold up. What is this, Objective-C? Manipulating UIBezierPaths isn't exactly ground-breaking stuff, but with a few dozen more lines to go, this is miserable.

How about we put some syntactic icing on this cake with some custom operators?

operatorinfix--->{associativityleft}func--->(left:UIBezierPath,right:(Float,Float))->UIBezierPath{let(x,y)=rightleft.moveToPoint(CGPointMake(x,y))returnleft}operatorinfix+-{associativityleft}func+-(left:UIBezierPath,right:(Float,Float))->UIBezierPath{let(x,y)=rightleft.addLineToPoint(CGPointMake(x,y))returnleft}operatorinfix+~{associativityleft}func+~(left:UIBezierPath,right:((Float,Float),(Float,Float),(Float,Float)))->UIBezierPath{let((x1,y1),(x2,y2),(x3,y3))=rightleft.addCurveToPoint(CGPointMake(x1,y1),controlPoint1:CGPointMake(x2,y2),controlPoint2:CGPointMake(x3,y3))returnleft}

Get it? ---> replaces moveToPoint, while +- replaces addLineToPoint, and +~ replaces addCurveToPoint. This declaration also does away with all of the redundant calls to CGPointMake, opting instead for simple coordinate tuples.

Swift offers a great deal of flexibility in how a programmer structures their code. One feature that exemplifies this mantra of minimal constraints is the ability to add custom prefix, infix, and postfix operators. Swift's syntax limits custom operators to be one or more of any of the following characters (provided an operator does not conflict with a reserved symbols, such as the ? or ! used for optional values):

/ = - + * % < > ! & | ^ . ~.

Custom operators offer a powerful tool for cutting through cruft, redundancy, unnecessary repetition, and so on and so forth, et cetera. Combine them with other language features like patterns or chaining to craft DSLs perfectly suited to the task at hand.

Just... you know, don't let this power go to your head.

After full Emoji support (let 🐶🐮), custom operators are perhaps the shiniest new feature for anyone coming from Objective-C. And like any shiny new feature, it is destined to provide the most snark fodder for the "get off my lawn" set.

A Dramatization of the Perils of Shiny Swift Features

SCENE: SAN FRANCISCO, THE YEAR IS 2017

GREYBEARD: So I inherited an old Swift codebase today, and I found this line of code—I swear to $DEITY—it just reads 😾 |--~~> 💩.

BROGRAMMER: shakes head

GREYBEARD: What the hell am I supposed to make of that? Is, like, the piece of poo throwing a Hadouken, or is it about to get the business end of a corkscrew?

BROGRAMMER: Truly, a philosophical quandary if ever there was one.

GREYBEARD: Anyway, turns out, that statement just reloads nearby restaurants.

BROGRAMMER: Dude, AFNetworking got weird with its 4.0 release.

GREYBEARD: Indeed.

The moral of that cautionary tale: use custom operators and emoji sparingly.

(Or whatever, the very next code sample totally ignores that advice)

// Happy 2nd Birthday, NSHipster// 😗💨🎂✨2️⃣var🍰=UIBezierPath()🍰--->((31.5,32.5))+~((6.5,66.1),(31.5,32.5),(6.9,46.3))+~((6.5,66.5),(6.5,66.2),(6.5,66.3))+-((6.5,95))+~((8.5,96.9),(6.5,96.1),(7.4,97))+-((92,93.1))+~((94.2,93),(93.1,93),(94.1,93))+~((94.4,91),(94.3,93),(94.4,92.1))+~((94.4,64.5),(94.4,91),(94.4,65.5))+~((92.4,61.5),(94.4,62.5),(92.4,61.5))--->((92.5,89.4))+~((90.5,91.4),(92.5,90.4),(91.6,91.3))+-((10.5,94.9))+~((8.5,93.1),(9.4,94.9),(8.5,94.1))+~((8.5,83),(8.5,93.1),(8.5,88.4))+-((92.5,79.1))+~((92.5,89.4),(92.5,84.5),(92.5,89.4))🍰.closePath()🍰--->((92.5,76))+-((8.5,80))+~((8.5,68.2),(8.5,74.2),(8.5,68.7))+~((9.5,67.1),(8.5,67.3),(9.5,67.1))+-((91.5,63.5))+~((92.5,64.4),(91.5,63.5),(92.5,63.5))+~((92.5,76),(92.5,64.9),(92.5,70.3))🍰.closePath()var📍=UIBezierPath()📍--->((46,47.5))+~((41.5,52),(46,50),(44,52))+-((41.5,52))+~((37,47.5),(39,52),(37,50))+-((37,19.8))+~((41.5,15.3),(37,17.3),(39,15.3))+-((41.5,15.3))+~((46,19.8),(44,15.3),(46,17.3))+-((46,47.5))📍.closePath()var🔥=UIBezierPath()🔥.miterLimit=4🔥--->((45.8,8.4))+~((41.7,14),(45.8,12.5),(44,14))+~((37.6,8.4),(39.4,14),(37.6,12.5))+~((41.8,1),(37.6,4.3),(41.8,1))+~((45.8,8.4),(41.8,1),(45.8,4.3))🔥.closePath()UIColor.blackColor().setFill()🍰.fill()🔥.fill()UIColor.whiteColor().setFill()UIColor.blackColor().setStroke()📍.fill()📍.stroke()

I'm as amazed as anyone that this actually compiles.

Everything is terrible.

Anyway, Happy 2nd Birthday, NSHipster!

Thank you for helping to make these last couple years the insanely great experience it's been. I'll do my part to keep things up for years to come.

Although iOS 8 and Swift has garnered the lion's share of attention of the WWDC 2014 announcements, the additions and improvements to testing in Xcode 6 may end up making some of the most profound impact in the long-term.

This week, we'll take a look at XCTest, the testing framework built into Xcode, as well as the exciting new additions in Xcode 6: XCTestExpectation and performance tests.

Most Xcode project templates now support testing out-of-the-box. For example, when a new iOS app is created in Xcode with ⇧⌘N, the resulting project file will be configured with two top-level groups (in addition to the "Products" group): "AppName" & "AppNameTests". The project's auto-generated scheme enables the shortcut ⌘R to build and run the executable target, and ⌘U to build and run the test target.

Within the test target is a single file, named "AppNameTests", which contains an example XCTestCase class, complete with boilerplate setUp& tearDown methods, as well as an example functional and performance test cases.

XCTestCase

Xcode unit tests are contained within an XCTestCase subclass. By convention, each XCTestCase subclass encapsulates a particular set of concerns, such as a feature, use case, or flow of an application.

Dividing up tests logically across a manageable number of test cases makes a huge difference as codebases grow and evolve.

setUp & tearDown

setUp is called before each test in an XCTestCase is run, and when that test finishes running, tearDown is called:

classTests:XCTestCase{overridefuncsetUp(){super.setUp()// Put setup code here. This method is called before the invocation of each test method in the class.}overridefunctearDown(){// Put teardown code here. This method is called after the invocation of each test method in the class.super.tearDown()}}

These methods are useful for creating an objects common to all of the tests for a test case:

varcalendar:NSCalendar?varlocale:NSLocale?overridefuncsetUp(){super.setUp()self.calendar=NSCalendar(identifier:NSGregorianCalendar)self.locale=NSLocale(localeIdentifier:"en_US")}

Since XCTestCase is not intended to be initialized directly from within a test case definition, shared properties initialized in setUp are declared as optional vars.

Functional Testing

Each method in a test case with a name that begins with "test" is recognized as a test, and will evaluate any assertions within that function to determine whether it passed or failed.

For example, the function testOnePlusOneEqualsTwo will pass if 1 + 1 is equal to 2:

functestOnePlusOneEqualsTwo(){XCTAssertEqual(1+1,2,"one plus one should equal two")}

All of the XCTest Assertions You Really Need To Know

XCTest comes with a number of built-in assertions, but one could narrow them down to just a few essentials:

Fundamental Test

To be entirely reductionist, all of the XCTest assertions come down to a single, base assertion:

XCTAssert(expression,format...)

If the expression evaluates to true, the test passes. Otherwise, the test fails, printing the formatted message.

Although a developer could get away with only using XCTAssert, the following helper assertions provide some useful semantics to help clarify what exactly is being tested. When possible, use the most specific assertion available, falling back to XCTAssert only in cases where it better expresses the intent.

Boolean Tests

For Bool values, or simple boolean expressions, use XCTAssertTrue& XCTAssertFalse:

XCTAssertTrue(expression,format...)XCTAssertFalse(expression,format...)

XCTAssert is equivalent to XCTAssertTrue.

Equality Tests

When testing whether two values are equal, use XCTAssert[Not]Equal:

XCTAssertEqual(expression1,expression2,format...)XCTAssertNotEqual(expression1,expression2,format...)

XCTAssert[Not]EqualObjects are not necessary in Swift, since there is no distinction between scalars and objects.

When specifically testing whether two Double, Float, or other floating-point values are equal, use XCTAssert[Not]EqualWithAccuracy, to account for any issues with floating point accuracy:

XCTAssertEqualWithAccuracy(expression1,expression2,accuracy,format...)XCTAssertNotEqualWithAccuracy(expression1,expression2,accuracy,format...)

In addition to the aforementioned equality assertions, there are XCTAssertGreaterThan[OrEqual]& XCTAssertLessThan[OrEqual], which supplement == with >, >=, <, & <= equivalents for comparable values.

Nil Tests

Use XCTAssert[Not]Nil to assert the existence (or non-existence) of a given value:

XCTAssertNil(expression,format...)XCTAssertNotNil(expression,format...)

Unconditional Failure

Finally, the XCTFail assertion will always fail:

XCTFail(format...)

XCTFail is most commonly used to denote a placeholder for a test that should be made to pass. It is also useful for handling error cases already accounted by other flow control structures, such as the else clause of an if statement testing for success.

Performance Testing

New in Xcode 6 is the ability to benchmark the performance of code:

functestDateFormatterPerformance(){letdateFormatter=NSDateFormatter()dateFormatter.dateStyle=.LongStyledateFormatter.timeStyle=.ShortStyleletdate=NSDate()self.measureBlock(){letstring=dateFormatter.stringFromDate(date)}}

Test Case '-[_Tests testDateFormatterPerformance]' started.
<unknown>:0: Test Case '-[_Tests testDateFormatterPerformance]' measured [Time, seconds] average: 0.000, relative standard deviation: 242.006%, values: [0.000441, 0.000014, 0.000011, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100
Test Case '-[_Tests testDateFormatterPerformance]' passed (0.274 seconds).

Performance tests help establish a baseline of performance for hot code paths. Sprinkle them into your test cases to ensure that significant algorithms and procedures remain performant as time goes on.

XCTestExpectation

Perhaps the most exciting feature added in Xcode 6 is built-in support for asynchronous testing, with the XCTestExpectation class. Now, tests can wait for a specified length of time for certain conditions to be satisfied, without resorting to complicated GCD incantations.

To make a test asynchronous, first create an expectation with expectationWithDescription:

letexpectation=expectationWithDescription("...")

Then, at the bottom of the method, add the waitForExpectationsWithTimeout method, specifying a timeout, and handler to execute if the conditions of a test are not satisfied within that timeframe:

waitForExpectationsWithTimeout(10,handler:{errorin// ...})

Now, the only remaining step is to fulfill that expecation in the relevant callback of the asynchronous method being tested:

expectation.fulfill()

If the test has more than one expectation, it will not pass unless each expectation executes fulfill() within the timeout specified in waitForExpectationsWithTimeout().

Here's an example of how the response of an asynchronous networking request can be tested with the new XCTestExpectation APIs:

functestAsynchronousURLConnection(){letURL="http://nshipster.com/"letexpectation=expectationWithDescription("GET \(URL)")letsession=NSURLSession.sharedSession()lettask=session.dataTaskWithURL(NSURL(string:URL),completionHandler:{(data,response,error)inexpectation.fulfill()XCTAssertNotNil(data,"data should not be nil")XCTAssertNil(error,"error should be nil")ifletHTTPResponse=responseasNSHTTPURLResponse!{XCTAssertEqual(HTTPResponse.URL.absoluteString,URL,"HTTP response URL should be equal to original URL")XCTAssertEqual(HTTPResponse.statusCode,200,"HTTP response status code should be 200")XCTAssertEqual(HTTPResponse.MIMETypeasString,"text/html","HTTP response content type should be text/html")}else{XCTFail("Response was not NSHTTPURLResponse")}})task.resume()waitForExpectationsWithTimeout(task.originalRequest.timeoutInterval,handler:{errorintask.cancel()})}

Mocking in Swift

With first-class support for asynchronous testing, Xcode 6 seems to have fulfilled all of the needs of a modern test-driven developer. Well, perhaps save for one: mocking.

Mocking is a useful technique for isolating and controlling behavior in systems that, for reasons of complexity, non-determinism, or performance constraints, do not usually lend themselves to testing. Examples include simulating network requests, intensive database queries, or inducing states that might emerge under a particular race condition.

There are a couple of open source libraries for creating mock objects and stubbing method calls, but these libraries largely rely on Objective-C runtime manipulation, something that is not currently possible with Swift.

However, this may not actually be necessary in Swift, due to its less-constrained syntax.

In Swift, classes can be declared within the definition of a function, allowing for mock objects to be extremely self-contained. Just declare a mock inner-class, override and necessary methods:

functestFetchRequestWithMockedManagedObjectContext(){classMockNSManagedObjectContext:NSManagedObjectContext{overridefuncexecuteFetchRequest(request:NSFetchRequest!,error:AutoreleasingUnsafePointer<NSError?>)->[AnyObject]!{return[["name":"Johnny Appleseed","email":"johnny@apple.com"]]}}letmockContext=MockNSManagedObjectContext()letfetchRequest=NSFetchRequest(entityName:"User")fetchRequest.predicate=NSPredicate(format:"email ENDSWITH[cd] %@","@apple.com")fetchRequest.resultType=.DictionaryResultTypevarerror:NSError?letresults=mockContext.executeFetchRequest(fetchRequest,error:&error)XCTAssertNil(error,"error should be nil")XCTAssertEqual(results.count,1,"fetch request should only return 1 result")letresult=results[0]as[String:String]XCTAssertEqual(result["name"]asString,"Johnny Appleseed","name should be Johnny Appleseed")XCTAssertEqual(result["email"]asString,"johnny@apple.com","email should be johnny@apple.com")}

With Xcode 6, we've finally arrived: the built-in testing tools are now good enough to use on their own. That is to say, there are no particularly compelling reasons to use any additional abstractions in order to provide acceptable test coverage for the vast majority apps and libraries. Except in extreme cases that require extensive stubbing, mocking, or other exotic test constructs, XCTest assertions, expectations, and performance measurements should be sufficient.

But no matter how good the testing tools have become, they're only good as how you actually use them.

If you're new to testing on iOS or OS X, start by adding a few assertions to that automatically-generated test case file and hitting ⌘U. You might be surprised at how easy and—dare I say—enjoyable you'll find the whole experience.

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.

Ironically, much of the following is currently undocumented, and is subject to change or correction.

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 latest Xcode 6 beta, 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{...}

It gets weirder.

Jump into a bridged Swift header for an Objective-C API, like say, HomeKit's HMCharacteristic, and option-clicking does work. (Also, the documentation there uses /*! to open documentation, rather than the conventional /**).

Little is known about this new documentation format... but in these Wild West times of strict typing and loose morals, that's not enough to keep us from using it ourselves:

Update: Sources from inside Cupertino have confirmed that SourceKit (the private framework powering Xcode that y'all probably know best for crashing in Playgrounds) includes a primitive parser for reStructuredText. How reST is, well, re-structured and adapted to satisfy Apple's use case is something that remains to be seen.

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.    */publicenumStyle{caseRoad,Touring,Cruiser,Hybrid}/**        Mechanism for converting pedal power into motion.        - Fixed: A single, fixed gear.        - Freewheel: A variable-speed, disengageable gear.    */publicenumGearing{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.0}/**        Take a bike out for a spin.        :param: meters The distance to travel in meters.    */functravel(distancemeters:Double){ifmeters>0.0{self.distanceTravelled+=metersself.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:

Again, not much is known about this new documentation format yet... as it's currently undocumented. But this article will be updated as soon as more is known. In the meantime, feel free to adopt the conventions described so far, as they're at least useful for the time being.

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