WatchKit on watchOS 2 brings major improvements to how Apple Watch apps communicate with their host app. Gone is openParentApplication(_:reply:), which has been replaced by the more capable WCSession.

 Features

WCSession allows WatchKit apps and their counterpart application to communicate, bidirectionally, in three ways: an updatable Application Context, live messages, and background transfers. The two later communication methods can either send a dictionary of values or raw data.

 Application Context

The Application Context is a dictionary that’s sent to the counterpart and persisted. The dictionary can then be read when the counterpart, whether that’s the WatchKit app or the host app, wakes up.

Updating the Application Context is simple. Just call updateApplicationContext(_:). This replaces the prior context value visible to the counterpart application. Note that updateApplicationC

One useful addition brought by watchOS 2.0 is the WKExtensionDelegate protocol, which exposes lifecycle events and more. This protocol is similar to UIApplicationDelegate.

WKExtensionDelegate has three methods that let you respond to lifecycle events. The lifecycle methods will seem familiar: applicationDidFinishLaunching(), applicationDidBecomeActive(), and applicationWillResignActive().

There are also several methods you can implement to handle notifications.

And finally, you can implement handleUserActivity() to facilitate Handoff.

I’ve been tinkering with WatchKit in my spare time and thought I’d share a bit of what I’ve learned. Of course, all of my tinkering was done in the simulator as I’ve not actually played with an  Watch.

 Watch Apps Have Up To Three Components

Watch apps contain an application, an optional glance, and optional custom notifications.

Glances are sort of like Today widgets on iOS. The idea is to show the most important bit of information your app provides. For example, CNN might display breaking news. The Watch may create your glance controller some time before the user sees it so it’s important to make sure the information displayed is up to date in willActivate(). Glances can be enabled or disabled by the user, don’t support scrolling, and allow for limited interactivity. Tapping a glance opens your Watch application.

Notifications are baked in with a default look but you can choose to

@ColinEberhardt wrote a great post titled Swift Initialization and the Pain of Optionals. In the post, Colin mentions not being able to pass parameters to initializers when assigning to a variable marked lazy. The workaround he found was to use a closure. Colin gave two examples:

lazy private var animator = UIDynamicAnimator(referenceView: self.view)

which did not compile and:

lazy private var animator: UIDynamicAnimator = {
    return UIDynamicAnimator(referenceView: self.view)
}()

which did compile. @schukin noticed that Colin also added an explicit type to the variable declaration in the second example. Doing the same with Colin’s first example fixes the compilation error:

lazy private var animator: UIDynamicAnimator = UIDynamicAnimator(referenceView: self.view)

So it turns out that you can reference variables regardless of whether or not you use a closure. The important

I’m republishing this article here so I can reference it later.

I recently needed a way to perform an unknown number of asynchronous http requests and wait until they were all done before proceeding. dispatch_groups are a neat feature of Grand Central Dispatch (GCD) that made this easy to do.

There are a couple of ways to use dispatch_groups but the basic idea is the same: create a dispatch_group, give it some tasks, and wait for it to finish those tasks.

First, let’s create a group:

dispatch_group_t group = dispatch_group_create();

There are two ways to add tasks to our dispatch_group. You can either call dispatch_group_async with the group, a dispatch_queue and block to run or manually call dispatch_group_enter.

Calling dispatch_group_async looks something like this:

dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // Do stuff on

I’ve just started reading Ed Catmull’s book, Creativity, Inc. Early on Ed explains that he came up with both the z-buffer and texture mapping techniques that had a profound impact on my childhood (Threewave CTF in Quake 1, anybody?). This reminded me of an anecdote the instructor of my second graphics class once shared.

Jarek Rossignac told us about his giving a talk during his tenure as a researcher at IBM. Jarek’s talk was about his research of subdivision of curves. After the talk, a gentleman struck up a conversation with him. That gentleman ended up being Pierre Bézier, the man who popularized the Bézier Curve.