100% found this document useful (1 vote)

1K views

Apple Watch Programming Guide

Uploaded by

โยอันนา ยุนอา แคทเธอรีน เอี่ยมสุวรรณ

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

1K views

Apple Watch Programming Guide

Uploaded by

โยอันนา ยุนอา แคทเธอรีน เอี่ยมสุวรรณ

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 79

Apple Watch Programming Guide

Contents

Overview 7
Developing for Apple Watch 8
The WatchKit App 10
Glance Interfaces 11
Custom Interfaces for Local and Remote Notifications 11

Configuring Your Xcode Project 12

Adding a WatchKit App to Your iOS Project 12
App Target Structure 13
The Build, Run, and Debug Process 13
Specifying a Notification Payload for Testing 15

WatchKit App Architecture 19

WatchKit App Life Cycle 20
Tasks to Perform at Different Stages of an Apps Life 22
Sharing Data with Your Containing iOS App 23
Communicating Directly with Your Containing iOS App 24

Leveraging iOS Technologies 25

WatchKit Apps 26
App Essentials 27
How Interface Controllers Work 27
Assembling Your Storyboard Scenes 28
Accommodating Different Display Sizes 29
Updating Your Interface at Runtime 32
Setting Your Apps Key Color 32
Internationalizing Your Interface 33

Interface Navigation 34
Implementing a Page-Based Interface 34
Implementing a Hierarchical Interface 35

Contents

Presenting Interface Controllers Modally 36

Interface Objects 37
Creating an Interface Object 37
Configuring Your Interface at Design Time 38
Changing Your Interface at Runtime 39
Responding to User Interactions 40
Hiding Interface Objects 41

Text and Labels 42

Using Fonts 42
Customizing the System Font 43
Managing Text Input 44
Internationalizing Your Text Code 45

Images 46
Specifying Your Image Assets 46
Using Named Images to Improve Performance 46
Caching Images on the Device 47

Tables 48
Configuring Row Controllers 48
Configuring the Tables Contents at Runtime 50
Handling Row Selections 52

Context Menus 53
Designing Your Menu Items 53
Adding a Context Menu to an Interface Controller 54
Handling Taps in a Menu Item 55

Glances 56
Glance Essentials 57
The Glance Life Cycle 58
Glance Interface Guidelines 58

Managing Your Glance Interface 59

Adding a Glance Interface to Your App 60
Implementing a Glance Interface Controller 60
Customizing App Launch From Your Glance 61

Contents

Notifications 62
Notification Essentials 63
The Short-Look Interface 64
The Long-Look Interface 65
Adding Action Buttons to Notifications 67
Responding to Taps in Action Buttons 68

Managing a Custom Long Look Interface 69

Adding a Custom Notification Interface to Your App 70
Configuring the Category of a Custom Interface 71
Configuring the Static Notification Interface 72
Configuring a Dynamic Notification Interface 73
Designing Your Dynamic Interface 74
Configuring Your Dynamic Interface at Runtime 74
Testing Your Custom Interface 77

Document Revision History 78

Figures, Tables, and Listings

Configuring Your Xcode Project 12

Figure 2-1
Figure 2-2

Target structure for a WatchKit app 13

A simulated remote notification payload. 17

WatchKit App Architecture 19

Figure 3-1
Figure 3-2
Figure 3-3
Table 3-1

Communication between a WatchKit app and WatchKit extension 19

Launching a WatchKit app 21
The life cycle of an interface controller 22
Key methods of WKInterfaceController 22

App Essentials 27
Figure 5-1
Figure 5-2

Interface objects in Xcode 28

Customizing attributes for different devices 31

Interface Objects 37
Figure 7-1
Table 7-1
Listing 7-1
Listing 7-2

Configuring a label object 38

Action methods for interface objects 40
Initializing an interface controller in Objective-C 39
Initializing an interface controller in Swift 39

Text and Labels 42

Figure 8-1
Figure 8-2
Listing 8-1
Listing 8-2
Listing 8-3

Standard font styles for labels 42

Gathering text input from the user 44
Using a custom font in a label string 43
Customizing the system font to use small caps 43
Presenting the text input controller 44

Tables 48
Figure 10-1
Listing 10-1
Listing 10-2

Examining a row controller in Xcode 50

Sample class for managing a row 49
Creating and configuring the rows of a table 51

Context Menus 53
Figure 11-1

A context menu with three items 53

Figures, Tables, and Listings

Glance Essentials 57
Figure 12-1

Glance interface for the Lister sample app 57

Managing Your Glance Interface 59

Figure 13-1

An interface controller with the glance entry point object 59

Notification Essentials 63
Figure 14-1
Figure 14-2
Listing 14-1

A short-look interface 65
A long-look notification interface 66
Registering actions in a containing iOS app 67

Managing a Custom Long Look Interface 69

Figure 15-1
Figure 15-2
Figure 15-3
Figure 15-4
Figure 15-5
Listing 15-1

Static and dynamic notification interfaces 69

Preparing the notification interface 70
Configuring the notification type information 71
Static and dynamic scenes for a single notification type 73
Configuring the dynamic notification interface 74
Configuring the custom interface from a remote notification 75

Overview

Important: This is a preliminary document for an API or technology in development. Apple is supplying
this information to help you plan for the adoption of the technologies and programming interfaces described
herein for use on Apple-branded products. This information is subject to change, and software implemented
according to this document should be tested with final operating system software and final documentation.
Newer versions of this document may be provided with future betas of the API or technology.

Developing for Apple Watch (page 8)

Configuring Your Xcode Project (page 12)

WatchKit app Architecture (page 19)

Leveraging iOS Technologies (page 25)

Developing for Apple Watch

Apple Watch offers users a distinctly personal and unobtrusive way to access their data. Rather than pull an
iPhone out of a pocket, a user can glance at Apple Watch and get important information quickly. Apps written
for Apple Watch support these brief interactions by providing only the most relevant information in the most
straightforward way possible.

Developing for Apple Watch

The WatchKit App

Apple Watch requires the presence of an iPhone to run third-party apps. Creation of a third-party app requires
two separate bundles: a WatchKit app that runs on Apple Watch and a WatchKit extension that runs on the
users iPhone. The WatchKit app contains only the storyboards and resource files associated with your apps
user interface. The WatchKit extension contains the code for managing the WatchKit apps user interface and
for responding to user interactions.
The user interacts with your WatchKit app in the following ways:

The user interacts with your apps full interface by launching the app from the home screen. Your apps
full interface can have multiple screens of content and can facilitate interactions with your apps data. You
must always provide a full app experience.

A Glance is a read-only interface that you use to display the most timely and relevant information from
your app. Providing a glance is optional.

Custom notification interfaces you change the way local and remote notification content is displayed to
the user. Use a custom interface to incorporate graphics, additional content, and a custom layout to your
notification content. Providing custom notification interfaces is optional.

Because a WatchKit app extends the behavior of your existing iOS app, the WatchKit app and WatchKit extension
are bundled together and packaged inside your iOS app bundle. During installation of your iOS app, the system
prompts the user to install the WatchKit app when a paired Apple Watch is present.

The WatchKit App

A WatchKit app is a user launchable app that appears on the Apple Watch home screen. A WatchKit app is the
users main way of viewing and interacting with your data. It provides the means to view your data and
optionally to manipulate or interact with that data. Depending on the data, a WatchKit app might present only
a subset of the data presented by its containing iOS app.
A WatchKit app acts as the public face of your app but it works in tandem with your WatchKit extension, which
is the brains of the operation. The WatchKit app contains only the storyboards and resource files associated
with your apps user interface. The WatchKit extension contains the business logic and code for managing
content, responding to user interactions, and updating your user interface. And because the extension runs
on the users iPhone, it can coordinate with your iOS app as needed to perform more sophisticated tasks.
To get started creating a WatchKit app, see App Essentials (page 27).

Developing for Apple Watch

Glance Interfaces

Glance Interfaces
A Glance is a focused interface that you use to display your apps most important information. Glances are
aptly named because they are intended to be looked at quickly by the user. Glances do not scroll; the entire
Glance interface must fit on a single screen. Glances are read-only and cannot contain buttons, switches, or
other interactive controls. Tapping a glance launches your WatchKit app.
Creating a Glance interface does not require creating a separate executable. Creating a Glance involves creating
a specialized set of objects inside your existing WatchKit app and WatchKit extension. In fact, the classes and
techniques you use to implement a Glance are the same ones you use to create your WatchKit app.
To get started creating a glance interface, see Glance Essentials (page 57).

Custom Interfaces for Local and Remote Notifications

Apple Watch works with its paired iPhone to display local and remote notifications. Initially, Apple Watch uses
a minimal interface to display incoming notifications. When the users movement indicates a desire to see
more information, the minimal interface changes to a more detailed interface displaying the contents of the
notification. You can customize this detailed interface and add custom graphics or arrange the notification
data differently than the default interface provided by the system.
Apple Watch provides automatic support for the actionable notifications introduced in iOS 8. Actionable
notifications are a way to add buttons to your notification interface that reflect actions the user might take.
For example, a notification for a meeting invite might include buttons to accept or reject the invitation. When
your iOS app registers support for actionable notifications, Apple Watch automatically adds appropriate buttons
to the notification interfaces on Apple Watch. All you need to do is handle the actions selected by the user in
your WatchKit extension.
To get started with creating a custom notification interface, see Notification Essentials (page 63).

Configuring Your Xcode Project

Creating a WatchKit app requires an existing iOS app. In the Xcode project for your iOS app, you add a new
WatchKit app target, which configures the bundles and initial resources for your WatchKit app and WatchKit
extension. Those bundles are then delivered as part of your iOS app on the App Store.
The WatchKit app target provided by Xcode contains everything you need to get started creating your WatchKit
app, glances, and custom notification interfaces. And iOS Simulator provides you with a runtime environment
for testing the appearance and behavior of all of your interfaces.

Adding a WatchKit App to Your iOS Project

You must have an existing iOS app to create a WatchKit app. The WatchKit app is implemented as a separate
target of your Xcode project and built and packaged inside your iOS apps bundle.
To add a WatchKit app target to your existing iOS app project, do the following:
1.

In Xcode, open the project for your iOS app .

Select File > New > Target and navigate to the Apple Watch section.

Select WatchKit App.

Click Next.

If you plan to implement a Glance or custom notification interface, select the appropriate checkboxes.
For notification interfaces, it is recommended that you enable the Include Notification Scene checkbox,
even if you do not plan on implementing that interface right away. Selecting that checkbox adds an
additional file to your project for debugging your notification interfaces. If you do not select that option,
you must create the file manually later.

Click Finish.

Xcode configures the targets for your WatchKit app and WatchKit extension and adds the needed files to your
iOS project. The bundle IDs for both new targets are configured automatically and are based on the bundle
ID of your iOS app. The base IDs for all three bundles must match; if you change your iOS apps bundle ID, you
must update the other bundle IDs accordingly.

Configuring Your Xcode Project

App Target Structure

Adding a WatchKit App target to your Xcode project creates two new executables and updates your projects
build dependencies. Building your iOS app builds all three executables (iOS app, WatchKit extension, and
WatchKit app) and packages them together. Xcode also creates a build scheme specifically for building and
debugging only your WatchKit app.
Figure 2-1 illustrates the structure of your iOS app and WatchKit executables. The WatchKit app is packaged
inside your WatchKit extension, which is in turn packaged inside your iOS app. When the user installs your iOS
app on an iPhone, the system prompts the user to install your WatchKit app if there is a paired Apple Watch
available. The installation process is handled automatically by iOS and requires no further work on your part.
Figure 2-1

Target structure for a WatchKit app

The Build, Run, and Debug Process

When you create your WatchKit app target, Xcode automatically configures a build scheme for running and
debugging your WatchKit app. Use that scheme to launch and run your app in iOS Simulator or on a device.
For apps that include Glance or custom notification interfaces, you must configure additional build schemes
to test those interfaces. Use the glance scheme for debugging your glance interface in the simulator and use
the notification scheme to test your dynamic and static notification interfaces.

To configure custom build schemes for your glance or notification interfaces

Select your existing WatchKit app scheme.

Configuring Your Xcode Project

The Build, Run, and Debug Process

Select Edit Scheme from the scheme menu.

Duplicate your existing WatchKit app scheme and give the new scheme an appropriate name.
For example, give it a name like Glance - My WatchKit app to indicate that the scheme is specifically
for running and debugging your glance.

Select the Run option in the left column of the scheme editor.

Configuring Your Xcode Project

Specifying a Notification Payload for Testing

In the Info tab, select the appropriate executable for the new scheme.

Close the scheme editor to save your changes.

When creating a build scheme for your notification interfaces, you can also specify a JSON file to use as the
notification payload during testing. For more information about notification payloads, see Specifying a
Notification Payload for Testing (page 15).

Specifying a Notification Payload for Testing

When debugging custom notification interfaces in iOS Simulator, you can specify the JSON payload data you
want delivered to your interface during testing. Use the scheme editor to specify which payload you want to
use when running your notification interface. The payload itself is a file that you create with a .apns filename
extension.

Configuring Your Xcode Project

Specifying a Notification Payload for Testing

Note: If you enabled the Include Notification Scene option when creating your WatchKit app target,
Xcode provides you with an initial PushNotificationPayload.apns file for specifying your test
data. The file is located in the Supporting Files directory of your WatchKit extension. You can also
create payload files manually later.

The PushNotificationPayload.apns file contains most of the keys you need to simulate a remote
notification, and you can add more keys based on your needs. Figure 2-2 shows the default JSON file that
comes with your project.

Configuring Your Xcode Project

Specifying a Notification Payload for Testing

Figure 2-2

A simulated remote notification payload.

Most, but not all, of the JSON data is packaged into a dictionary and delivered to your code at runtime. Because
iOS Simulator does not have access to your iOS apps registered actions, payload files may also specify the
action buttons to display in your interface. The WatchKit Simulator Actions key contains an array of dictionaries,
each of which represents an action button to add to your interface. Each dictionary contains two keys:

Configuring Your Xcode Project

Specifying a Notification Payload for Testing

title - The value of this key is the title of the action button.

identifier - The value of this key is the string to pass to your interface controllers
application:handleActionWithIdentifier:forLocalNotification:completionHandler:

or application:handleActionWithIdentifier:forRemoteNotification:completionHandler:
method.

destructive - The value of this key is the value 1 or 0, where 1 causes the resulting button to be

rendered in a way that indicates it performs a destructive action. The value 0 causes the button to be
rendered normally. Inclusion of this key is optional.
To test your notification interface with the JSON payload, configure the build scheme with the appropriate
payload file. When you select a notification interface executable, Xcode adds a menu for selecting one of your
payload files. You can create different build schemes for different notification payloads or you can update the
payload file for an existing build scheme prior to testing.

WatchKit App Architecture

Apps built for Apple Watch consist of two parts: a WatchKit app and a WatchKit extension. The WatchKit app
resides on the users Apple Watch and contains your storyboard and resource files but no code. The WatchKit
extension resides on the users iPhone (inside your containing iOS app) and contains the code and resource
files for managing your WatchKit apps interface.
The WatchKit app and WatchKit extension work in tandem to implement your apps interface. When the user
interacts with your app on Apple Watch, your WatchKit app chooses the appropriate scene from your storyboards
to handle that interaction. For example, if the user views your apps Glance, it chooses your Glance scene. After
choosing the scene, WatchKit tells the paired iPhone to launch your WatchKit extension and create the objects
needed to manage that scene. When the scene is fully configured, it is displayed on Apple Watch. The transfer
of information between the WatchKit app and WatchKit extension happens transparently behind the scenes.
Figure 3-1

Communication between a WatchKit app and WatchKit extension

Each scene is managed by a single interface controller object, which is an instance of the
WKInterfaceController class. An interface controller in WatchKit serves the same purpose as a view
controller in iOS: it presents and manages content on the screen and responds to user interactions with that
content. Unlike a view controller, an interface controller does not manage the actual views of your interface.
Those views are managed for you behind the scenes by WatchKit.

WatchKit App Architecture

WatchKit App Life Cycle

WatchKit apps typically contain multiple interface controllers, where each interface controller displays a different
type of information. Because only one interface controller at a time is displayed onscreen, an app presents
new interface controllers in response to user actions. Apps can present interface controllers modally. The
navigation style of an app also determines how interface controllers are presented. For information on how
to present new interface controllers, see Interface Navigation (page 34).
Note: Glance and custom notification interfaces use specialized interface controllers that are separate
from your apps other interface controllers. For information about implementing a glance, see Glance
Essentials (page 57). For information about the implementing custom notification interfaces, see
Notification Essentials (page 63).

WatchKit App Life Cycle

User interactions with Apple Watch drive the launching of your app and its life cycle. The user can launch your
app from the home screen, interact with your glance, or view notifications using your custom UI. Each of these
interactions launches your WatchKit app and the corresponding WatchKit extension. Your WatchKit app and
WatchKit pass information back and forth until the user stops interacting with your app, at which point iOS
suspends the extension until the next user interaction.

WatchKit App Architecture

WatchKit App Life Cycle

At launch time, WatchKit automatically loads the appropriate scene for the current interaction. If the user views
your apps glance, it loads the glance scene from your storyboard; if the user launched your app directly, it
loads the initial scene for your app. After it loads the scene, it asks the WatchKit extension to create the
corresponding interface controller object, which you use to prepare the scene for display to the user. Figure
3-2 shows the steps for this sequence.
Figure 3-2

Launching a WatchKit app

Use your interface controllers init and awakeWithContext: methods to load any required data, set the
values for any interface objects, and prepare your interface to be displayed. Do not use the willActivate
to initialize your interface controller. The willActivate method is called shortly before your interface is
displayed onscreen, so you should use that method only to make last minute changes. For example, you might
also use that method to start animations or start other tasks that should only happen while your interface is
onscreen.
While your interface controller is onscreen, user interactions are handled by your interface controllers custom
action methods. As the user interacts with tables, buttons, switches, sliders, and other controls, WatchKit calls
your action methods so that you can respond. You use those action methods to update your interface or
perform other relevant tasks. To perform tasks at other times, use an NSTimer object to run code at the time
you designate.

WatchKit App Architecture

Tasks to Perform at Different Stages of an Apps Life

Note: Glance interfaces do not support action methods. Tapping your apps glance interface always
launches the app.

Your WatchKit extension remains running only while the user is interacting with your app on Apple Watch.
Interactions with Apple Watch are meant to be brief, so interface controllers should be lightweight and never
perform long-running tasks. When the user exits your app explicitly or stops interacting with Apple watch, iOS
deactivates the current interface controller and suspends your extension as shown in Figure 3-3.
Figure 3-3

The life cycle of an interface controller

Tasks to Perform at Different Stages of an Apps Life

At different stages of your apps life, iOS calls the methods of your WKInterfaceController objects to give
you a chance to respond. Table 3-1 lists the key methods that you should almost always implement in your
interface controllers, along with the kinds of tasks you perform in them.
Table 3-1

Key methods of WKInterfaceController

Method

Tasks to perform

init

This method is your first chance to prepare your interface for display. Use it
to load data and update labels, images, tables, and other interface objects
in your storyboard scene.

awakeWithContext:

This method lets you configure the interface controller using any available
context data. The context data is data you provide to assist in the
configuration of a new interface controller. For example, when pushing a
new interface controller in a hierarchical interface, you specify a context
object that contains the next level of data to display. Providing a context
object is recommended but not required.

WatchKit App Architecture

Sharing Data with Your Containing iOS App

Method

Tasks to perform

willActivate

This method lets you know that your interface will soon be visible to the
user. Use this method only to make small changes to your interface. For
example, you might use this method to update a label based on new data.
The bulk of your interface initialization should still occur in the init and
awakeWithContext: methods.

didDeactivate

Use the didDeactivate method to clean up your interface and put it into
a quiescent state. For example, use this method to invalidate timers and stop
animations.
You cannot set values for any interface objects from this method. From the
time this method is called to the time the willActivate method is called
again, any attempts to set values for interface objects are ignored.

Sharing Data with Your Containing iOS App

If your iOS app and WatchKit extension rely on the same data, use a shared app group to store that data. An
app group is a secure container that multiple processes can access. Because your WatchKit extension and iOS
app run in separate sandbox environments, they normally do not share files or communicate directly with one
another. An app group lets the two processes share files or user defaults information between them.
You set up a shared app group from the Capabilities tab of your iOS app and WatchKit extension. Enabling the
App Groups capability adds an entitlements file (as needed) to each target and adds the
com.apple.security.application-groups entitlement to that file. To share data, both targets must
have the same app group selected.
At runtime, you share files between processes by reading and writing those files in the shared container
directory. To access the container directory, use the
containerURLForSecurityApplicationGroupIdentifier: method of NSFileManager to retrieve the
base URL for the directory. Use the provided URL to enumerate the directory contents or create new URLs for
files in the directory.
To share preferences data between apps, create an NSUserDefaults object using the identifier of the shared
group. The initWithSuiteName: method of NSUserDefaults creates an object that allows access to the
shared user defaults data. Both processes can access this data and write changes to it.

WatchKit App Architecture

Communicating Directly with Your Containing iOS App

Apps that work closely with their containing iOS app can use the openParentApplication:reply: method
to send requests to that app and receive a response. WatchKit extensions do not support background execution
modes; they run only while the user is interacting with the corresponding app on Apple Watch. Their containing
iOS app has fewer restrictions and can be configured to run in the background or to gather information on
behalf of the WatchKit extension. Activities that might require extra time to complete, such as fetching the
users location, should therefore be performed by the iOS app and communicated back to the WatchKit
extension.
When you call the openParentApplication:reply: method, iOS launches or wakes up the containing iOS
app in the background and calls the application:handleWatchKitExtensionRequest:reply: method
of its app delegate. The app delegate uses the provided dictionary to perform the request and return a reply
to the WatchKit extension.

Leveraging iOS Technologies

WatchKit extensions have access to the same technologies found in iOS apps, but because they are extensions,
use of some technologies may be restricted and the use of others is not recommended. Here are some guidelines
for deciding when to use a particular technology:

Avoid using technologies that request user permission, like Core Location. Using the technology from
your WatchKit extension could involve displaying an unexpected prompt on the users iPhone the first
time you make the request. Worse, it could happen at a time when the iPhone is in the users pocket and
not visible.

Do not use background execution modes for a technology. WatchKit extensions run only while the user
interacts with the corresponding WatchKit app and are therefore considered foreground extensions. As a
result, WatchKit extensions cannot execute using the background modes supported by some technologies.

Avoid performing long-running tasks with a technology. A WatchKit extension is suspended soon after
the user stops interacting with the corresponding WatchKit app. Because WatchKit app interactions are
typically brief, the extension might already be suspended by the time the requested data arrives.

The best solution for performing any long-running tasks is to let your iOS app perform the task instead. For
example, instead of starting location services in your WatchKit extension, start it in your iOS app. Your iOS app
can gather the needed data and put it in a shared app group so that your extension can access it later. Use
the openParentApplication:reply: method to initiate tasks and receive a reply or use a shared group
container to communicate details between your iOS app and WatchKit extension. For information about how
to handle communication between your iOS app and WatchKit extension, see Communicating Directly with
Your Containing iOS App (page 24).

WatchKit Apps

App Essentials (page 27)

Interface Navigation (page 34)

Interface Objects (page 37)

Text and Labels (page 42)

Images (page 46)

Tables (page 48)

Context Menus (page 53)

App Essentials

Xcode provides storyboard support for creating WatchKit app interfaces. When you add a WatchKit app to
your project, Xcode provides you with a storyboard for implementing your UI. The storyboard has at least one
scene for your WatchKit apps interface and may have additional scenes for your glance or notification interfaces.
You can add additional scenes to your storyboard by dragging interface controller objects from the object
library.
Each new scene in your storyboard is backed by a corresponding WKInterfaceController subclass that
you provide. (For dynamic notification interfaces, you subclass WKUserNotificationInterfaceController
instead.) For every new scene, enter the name of your interface controller subclass in the Identity inspector.
All of your interface controller code goes in your WatchKit extension target. Do not include any code in your
WatchKit app.

How Interface Controllers Work

Interface controllers manage the content of your storyboard scenes. Each interface controller uses outlets to
store references to objects in the scene and defines action methods to respond to user interactions. At runtime,
you use the interface controllers init, awakeWithContext:, and willActivate methods to configure
your interface. In these methods, you perform tasks such as the following:

Fetch the data you want to display.

Set the initial values and configuration of labels, images, and other controls.

Hide interface objects that you do not need and show the ones you do need.

There is no limit to the number of interface controllers you can have in your WatchKit app, but more interface
controllers usually means more complexity, so fewer is better. The navigation style you choose for your app
defines how users navigate from one scene to the next. Some navigation styles require you to explicitly present
the next interface controller while others do not. For more information on how to navigate between the scenes
of your app, see Interface Navigation (page 34).

App Essentials
Assembling Your Storyboard Scenes

Assembling Your Storyboard Scenes

WatchKit apps do not use the same layout model as iOS apps. When assembling the scenes of your WatchKit
app interface, you do not create view hierarchies by placing elements arbitrarily in the available space. Instead,
as you add elements to your scene, Xcode positions the items for you, stacking them vertically on different
lines. At runtime, Apple Watch takes those elements and lays them out for you based on the available space.
WatchKit also provides ways for you to position items more precisely within your storyboard scenes. The size
and position of most items can be configured using the Attributes inspector. Group objects offer another
important tool for positioning items, allowing you to lay out elements horizontally as well as vertically. Groups
also offer extra options for spacing items within the group bounds. Groups have no default visual representation
but can be configured with a background color or image if you want.
Figure 5-1 shows how different elements can be arranged in your storyboard file. The first three elements are
labels, each of which occupies the entire horizontal width of its line. For each label, the alignment value
determines whether the aligned to left, right, or center of interface controllers bounds. Below the labels is a
group object containing two images arranged horizontally. The interface also contains a switch, a separator,
and a button all stacked vertically underneath the group object.
Figure 5-1

Interface objects in Xcode

When creating your interfaces in Xcode, let objects resize themselves to fit the available space whenever
possible. App interfaces should be able to run both display sizes of Apple Watch. Letting the system resize
objects to fit the available space minimizes the amount of custom code you have to write for each device.

App Essentials
Accommodating Different Display Sizes

Accommodating Different Display Sizes

Xcode supports customizing your interface for the different sizes of Apple Watch. The changes you make in
the storyboard editor apply to all sizes of Apple Watch by default, but you can customize your storyboard
scenes as needed for different devices. For example, you might make minor adjustments to the spacing and
layout of items or specify different images for different device sizes.

App Essentials
Accommodating Different Display Sizes

To customize an item for a specific device size, use the plus buttons in the Attributes inspector to override the
value of an attribute for a given device. Clicking a plus button adds a new device-specific entry for the attribute.
Changes you make to that version of the attribute affect only the selected device. Figure 5-2 shows an example
where text scaling is handled differently for Apple Watch 42mm.

App Essentials
Accommodating Different Display Sizes

Figure 5-2

Customizing attributes for different devices

App Essentials
Updating Your Interface at Runtime

Users should not notice any significant differences in your apps interface on different sizes of Apple Watch,
so always minimize the customizations you make for different device sizes. Whenever possible, limit interface
changes to layout-related behaviors such as spacing and margins. Although it is possible to remove interface
objects altogether from your interface in different layouts, doing so is not recommended. You should always
try to use the exact same set of interface objects on all sizes of Apple Watch.
To see customizations applied to different device sizes, use the control at the bottom of the storyboard editor
to toggle between the device sizes. The storyboard editor displays the Any device size by default. Changes
applied in the Any display mode apply to all sizes of Apple Watch. If you change the display mode to a specific
device size, the changes you make while in that mode apply only to the current device.

Updating Your Interface at Runtime

At runtime, an interface controller can make the following modifications to the objects in its corresponding
storyboard scene:

Set or update data values.

Change the visual appearance of objects that support such modifications.

Change the size of an object.

Change the transparency of an object.

Show or hide an object.

You cannot add new objects to your interface or change the order of the objects that are already there. Although
you cannot remove objects, you can hide them, which removes them from the layout temporarily. When an
item is hidden, other objects fill in the space previously occupied by the item. To hide an object without filling
in the space, set the items alpha value to 0. For more information about hiding objects in a scene, see Hiding
Interface Objects (page 41).

Setting Your Apps Key Color

Every WatchKit app has an associated key color, which is applied to the following UI elements:

The title string in the status bar

The app name in short look notifications

App Essentials
Internationalizing Your Interface

An apps key color is stored in the Global Tint property of the apps storyboard. To access this property, select
your storyboard and display the File inspector. Select one of several preexisting colors from the popup menu
or use the color picker to specify a custom color.

Internationalizing Your Interface

The storyboards that come with your WatchKit app have base internationalization enabled by default. This
feature causes any strings in your storyboard to be added to your projects Localizable.strings files
automatically. All you have to do is translate the strings in those files for each target language and include
them with your shipping app. When creating a storyboard scene at runtime, Xcode inserts the strings associated
with the appropriate localization.
When thinking about internationalization, your main concern should be arranging your interface so that labels
and controls that contain text have room to expand. Instead of placing multiple buttons on the same line,
arrange them vertically so that each one has plenty of room to display its title.
For text and images that you specify programmatically, use the same internationalization techniques you use
for iOS and OS X apps.

Use the NSLocalizedString macros to load strings from resource files.

Use an NSNumberFormatter object to format numerical values.

Use an NSDateFormatter object to format dates.

When used in your WatchKit extension, an NSLocale object returns the locale information configured on the
users Apple Watch. Use that class to get the users preferred languages and other language and locale-related
information.
For more information about internationalizing your app, see Internationalization and Localization Guide .

Interface Navigation

For WatchKit apps with more than one screen of content, you must choose a technique for navigating between
those screens. WatchKit apps support two navigation styles, which are mutually exclusive:

Page-based. This style is suited for apps with simple data models where the data on each page is not
closely related to the data on any other page. A page-based interface contains two or more independent
interface controllers, only one of which is displayed at any given time. At runtime, the user navigates
between interface controllers by swiping left or right on the screen. A dot indicator control at the bottom
of the screen indicates the users current position among the pages.

Hierarchical. This style is suited for apps with more complex data models or apps whose data is more
hierarchical. A hierarchical interface always starts with a single root interface controller. In that interface
controller, you provide controls that, when tapped, push new interface controllers onto the screen.

Apps can use modal presentations to supplement their base navigation style. Modal presentations are a way
to interrupt the current user workflow to request input or display information. You can present interface
controllers modally from both page-based and hierarchical apps. The modal presentation itself can consist of
a single screen or multiple screens arranged in a page-based layout.

Implementing a Page-Based Interface

You configure a page-based interface in your apps storyboard by creating a next page segue from one
interface controller to the next. To create this segue:
1.

In your storyboard, add interface controllers for each of the pages in your interface.

Control-click your apps main interface controller and drag to another interface controller.
The second interface controller should highlight, indicating that a segue is possible.

Release the mouse button.

Select next page from the relationship segue panel.

Using the same technique, create segues from each interface controller to the next.
The order in which you create your segues defines the order of the pages in your interface.

Interface Navigation
Implementing a Hierarchical Interface

The segues you create in your storyboard file define the page-based interface that is loaded when your app
is launched. You can change the set of pages you want to display by calling the
reloadRootControllersWithNames:contexts: method early in the launch cycle. For example, you might
call that method in the init method of your main interface controller to force WatchKit to load a different
set of pages.
All interface controllers in a page-based interface are created and initialized prior to displaying the interface,
but only one interface controller at a time is displayed. Normally, WatchKit displays the first interface controller
in the sequence initially. To change the initially displayed interface controller, call the becomeCurrentPage
method from its init or awakeWithContext: method.
As the user navigates from page to page, WatchKit activates and deactivates interface controllers accordingly.
During a transition, the currently visible interface controllers didDeactivate method is called, followed by
a call to the willActivate method of the interface controller that is about to be displayed. Use the
willActivate method to update the contents of your interface controller to reflect any last minute changes.

Implementing a Hierarchical Interface

In a hierarchical interface, you tell WatchKit when to transition to a new screen using segues or by calling the
pushControllerWithName:context: method of the current interface controller. In your storyboard, you
create push segues from a button, group, or table row in your interface to another interface controller in your
storyboard. If you prefer to initiate the push transition programmatically, call the
pushControllerWithName:context: method from any of your interface controllers action methods.
When pushing a new interface controller onto the screen, it is recommended that you pass a data object in
the context parameter of the pushControllerWithName:context: method. This context object is how
you pass state information to the new interface controller before it appears onscreen. Use this object to tell
the new interface controller what data to display.
A pushed interface controller displays a chevron in the upper-left corner of the screen to indicate that the user
can navigate backward. When the user taps the upper-left corner of the screen or performs a left-edge swipe,
WatchKit dismiss the topmost interface controller automatically. You can also dismiss the interface controller
programmatically by calling its popController method. You cannot dismiss your apps main interface
controller.

Interface Navigation
Presenting Interface Controllers Modally

Presenting Interface Controllers Modally

A modal interface is a way to interrupt the current navigation flow temporarily to prompt the user or display
information. You can present a modal interface from any interface controller, regardless of the navigation style
used by your app. To display an interface controller modally, do one of the following:

Create a modal segue in your storyboard file.

Call the presentControllerWithName:context: method to present a single interface controller

modally.

Call the presentControllerWithNames:contexts: method to present two or more interface controllers

modally using a page-based layout.

When creating a modal segue, connect the segue to the interface controller you want to display. When using
a segue to present multiple interface controllers, first use the next page segue to connect the modal interface
controllers together, in the same way that you connect them together for a page-based interface. Your modal
segue should connect to the first interface controller in the group. If you connect to an interface controller in
the middle of the group, the interface controllers that precede it in the group are not displayed.
The top-left corner of a modal interface displays the interface controllers title string. When the user taps that
string, WatchKit dismisses the modal interface. Set the title string to reflect the meaning of dismissing the
modal interface. For example, when displaying information, you might set the string to Done or Close. If you
do not specify a title for your interface controller, WatchKit displays the string Cancel by default.

Interface Objects

You manipulate your WatchKit apps UI using interface objects. An interface object is an instance of the
WKInterfaceObject class, or more specifically one of its subclasses. The WatchKit framework provides
interface objects for most (but not all) of the visual elements you can add to your UI in your storyboard files.
Interface objects are not views. They are proxy objects that communicate wirelessly with the actual views used
to implement your UI on Apple Watch.
Note: Communication between an interface object and the corresponding view on Apple Watch is
one way, with information flowing from your WatchKit extension to Apple Watch. In other words,
you set values on an interface object but you cannot get the current values of its attributes. There
are performance and latency implications for retrieving data from Apple Watch, making changes,
and writing those changes back to the device. So it is recommended that you maintain information
about the configuration of your interface in your WatchKit extension.

Creating an Interface Object

You create interface objects indirectly by adding declared properties to your interface controller and connecting
those properties to the corresponding elements in your storyboard file. You never alloc/init interface objects
yourself. During the initialization of your interface controller object, WatchKit creates the interface objects for
any connected outlets automatically.
When adding declared properties for interface objects, set the class to the appropriate type and include the
IBOutlet keyword in your declaration. For example, the declaration for a label is as follows:
@interface MyHelloWorldController()
@property (weak, nonatomic) IBOutlet WKInterfaceLabel* label;
@end

Connect each declared property in your interface controller to the corresponding item in your storyboard. A
quick way to create property declarations and connect them to an item is to use the Assistant editor in Xcode.
After displaying the Assistant editor, control-drag from an element in your storyboard to the interface definition
of your class to create an outlet. (In Swift, drag to your class definition.) After prompting you for the outlets
name, Xcode creates the property declaration in your class and connects it to the storyboard element.

Interface Objects
Configuring Your Interface at Design Time

Configuring Your Interface at Design Time

At design time, use Xcode to configure the appearance of the visual elements in your storyboards. For many
layout-related attributes, design-time is the only time you can configure the attribute. For example, you can
change a labels text, color, and font using a WKInterfaceLabel object but you cannot change the number
of lines or the height of each line. Those attributes must be configured in Xcode, as shown in Figure 7-1.
Figure 7-1

Configuring a label object

Interface Objects
Changing Your Interface at Runtime

For more information about how to configure interface objects, see the corresponding class descriptions in
WatchKit Framework Reference .

Changing Your Interface at Runtime

In the code of your WatchKit extension, you update your apps UI by calling methods of any referenced interface
objects. An interface controller may change the configuration of its interface objects only while it is active,
which includes initialization time. In your init, awakeWithContext:, and willActivate methods, call
methods to assign data values to labels, images, and other objects in your user interface. You might also update
them from your interface controllers action methods.
At initialization time, it is important to let WatchKit initialize your interface controller class before doing anything
else. The initialization methods of WKInterfaceController and its subclasses are where WatchKit creates
your apps interface objects. So any initialization code you write for your interface controllers must call the
super implementation first. Listing 7-1 shows an example of an init method for an interface controller that
contains an outlet (called label) for a WKInterfaceLabel object.
Listing 7-1

Initializing an interface controller in Objective-C

- (instancetype)init {
// Always call super first.
self = [super init];
if (self){
// It is now safe to access interface objects.
[self.label setText:@Hello New World];
}
return self;
}

Listing 7-2 shows how to initialize your interface using Swift.

Listing 7-2

Initializing an interface controller in Swift

override init {
// Initialize variables here.
super.init

// It is now safe to access interface objects.

Interface Objects
Responding to User Interactions

label.setText("Hello New World")

}

To improve performance and battery life, the WatchKit framework optimizes any attempts to set values on
your apps interface objects. Whenever you set the values for one or more interface objects in the same run
loop iteration, the new values are coalesced and transmitted to Apple Watch in a single batch to improve
efficiency. Coalescing changes means that only that last change to a given property of an object is sent to the
device. More importantly, setting the same property to the same value generates a log message to help you
track down the duplicate calls.
For information about the methods you use to configure your interface objects, see the corresponding class
descriptions in WatchKit Framework Reference .

Responding to User Interactions

Use buttons, switches, and other interactive controls to initiate changes in your app. When a button is tapped
or the value of another control changes, WatchKit calls the associated action method in your interface controller.
Each type of interface object has a required format for its action method, which are listed in Table 7-1. Change
the name of the action methods to something appropriate for your app.
Table 7-1

Action methods for interface objects

Object

Objective-C

Swift

Button

- (IBAction)buttonAction

@IBAction func
buttonAction()

Switch

- (IBAction)switchAction:(BOOL)on

@IBAction func
switchAction(value: Bool)

Slider

(IBAction)sliderAction:(float)value

@IBAction func
sliderAction(value: Float)

Menu Item

- (IBAction)menuItemAction

@IBAction func
menuItemAction()

Interfaces containing tables can use segues or the table:didSelectRowAtIndex: method of the interface
controller to respond to taps in a table row. Use a segue to display another interface controller. Prior to
performing the segue, WatchKit calls the contextForSegueWithIdentifier:inTable:rowIndex: or
contextsForSegueWithIdentifier:inTable:rowIndex: method of your interface controller so that

Interface Objects
Hiding Interface Objects

you can specify the context objects to use when displaying the interface controller. If you use the
table:didSelectRowAtIndex: method instead of a segue, you can perform whatever actions are appropriate
for tapping on the row.
After your interface controller is initialized and onscreen, WatchKit calls the methods of your interface controller
only when the user interacts with your interface. If you want to update your user interface without user
intervention, you must configure an NSTimer object and use its handler to perform any needed tasks.
For tasks that might take more than a second or two, consider handing those tasks off to your parent iOS app
for execution. Long-running tasks such as network access and location monitoring are best handled by the
parent app, which can then communicate that information back to your WatchKit extension through a shared
group container directory. For information about handing off tasks to your parent app, see Communicating
Directly with Your Containing iOS App (page 24).

Hiding Interface Objects

Hiding objects lets you use the same interface controller to display different types of content. Each scene in
your storyboard file must contain all of the interface objects needed to display its content at runtime. If you
customize your interface based on the data you have available, you can hide objects that you do not need.
Hiding an object effectively removes it from your interface. During layout, hidden items are treated as if they
were removed entirely from the layout altogether. To hide an object, call its setHidden: method and pass
the value YES.

Text and Labels

To display text in your WatchKit app, use label objects. Labels support formatted text that can be changed
programmatically at runtime.
To add a label to your interface controller, drag it into the corresponding storyboard scene. From there, configure
the labels initial text string and format. WatchKit supports both standard fonts and custom fonts that you
specify yourself. Figure 8-1 shows the standard font styles available for you to use.
Figure 8-1

Standard font styles for labels

For more information about configuring label objects in Xcode and in your code, see WKInterfaceLabel Class
Reference .

Using Fonts
WatchKit apps may use only the system font or custom fonts to display text. To use custom fonts, you must
install those fonts by doing the following:

Include the custom font file in both your WatchKit app and WatchKit extension bundle.

Add the UIAppFonts key to your WatchKit apps Info.plist file and use it to specify the fonts you
added to the bundle. For more information about this key, see Information Property List Key Reference .

Text and Labels

Customizing the System Font

Important: You must include the font in your WatchKit extension so that you can create strings with that
font at runtime. The font information is included with the attributed string when it is sent to Apple Watch,
and the copy of the font in your WatchKit app bundle is then used to render the string there.
To format text using a custom font, create an attributed string using the font information and use that string
to set the text of your label, as shown in Listing 8-1. The font name and size are encoded with the attributed
string, which is then used to update the label on the users Apple Watch. If the font name you specify is not
the system font or one of your custom installed fonts, WatchKit uses the system font.
Listing 8-1

Using a custom font in a label string

// Configure an attributed string with custom font information.

let menloFont = UIFont(name: "Menlo", size: 12.0)!

var fontAttrs = [NSFontAttributeName : menloFont]
var attrString = NSAttributedString(string: "My Text", attributes: fontAttrs)

// Set the text on the label object

self.label.setAttributedText(attrString)

Customizing the System Font

To customize the system font, use UIFontDescriptor objects to specify a new font based on the system
font. Listing 8-2 shows an example of how to customize the standard system font to always use small capital
characters. After converting the system font to a font descriptor, the method adds the kLowerCaseType and
kLowerCaseSmallCapsSelector attributes (defined in the Core Text framework) and uses the resulting
font descriptor to create a new font object.
Listing 8-2

Customizing the system font to use small caps

let fontSize : CGFloat = 18.0

let aFont = UIFont.systemFontOfSize(fontSize)
let fontDescriptor = aFont.fontDescriptor().fontDescriptorByAddingAttributes(
[UIFontDescriptorFeatureSettingsAttribute :
[UIFontFeatureTypeIdentifierKey : kLowerCaseType,
UIFontFeatureSelectorIdentifierKey : kLowerCaseSmallCapsSelector]])

Text and Labels

Managing Text Input

let smallCapFont = UIFont(descriptor: fontDescriptor, size: fontSize)

Managing Text Input

WatchKit provides a standard modal interface for retrieving text input from the user. When presented, the
interface allows the user to enter text via dictation or to select from a standard set of phrases or emoji. To
present this interface, call the
presentTextInputControllerWithSuggestions:allowedInputMode:completion: method of the
currently active interface controller. When presenting the interface, you specify the types of input you support
and a block to execute with the results. You also specify an initial set of phrases to display in the interface, as
shown in Figure 8-2. The user can select from the available phrases or use the controls to input a different
phrase.
Figure 8-2

Gathering text input from the user

Listing 8-3 shows how to configure the text input controller and process the results. After specifying the initial
phrases and input modes, the controller runs asynchronously. When the user selects an item or cancels input,
your block is executed on the main thread. Use that block to retrieve the text or emoji image that was selected
by the user and update your app.
Listing 8-3

Presenting the text input controller

NSArray* initialPhrases = @[@"Let's do lunch.", @"Can we meet tomorrow?", @"When

are you free?"];

Text and Labels

Internationalizing Your Text Code

[self presentTextInputControllerWithSuggestions:initialPhrases
allowedInputMode:WKTextInputModeAllowAnimatedEmoji
completion:^(NSArray *results) {
if (results && results.count > 0) {
id aResult = [results objectAtIndex:0];
// Use the string or image.
}
else {
// Nothing was selected.
}
}];

Internationalizing Your Text Code

WatchKit apps can use the same technologies for internationalization that iOS apps use.

Use Xcodes base internationalization support for storyboards and xib files. Base internationalization lets
you have only one set of storyboard files that supports all localizations. The localized strings for the
storyboard are stored separately in language-specific strings files.

Use the NSLocalizedString family of macros to retrieve localized strings programmatically.

Use the NSNumberFormatter class to format numerical values using the users region and locale settings.

Use the NSDateFormatter class to format dates using the users region and locale settings.

When internationalizing your app, your main concern should be arranging your interface so that labels (and
other controls with text) have room to expand. For example, rather than using a group to arrange three buttons
horizontally, arranging the buttons vertically gives each one room to grow horizontally when its text becomes
longer.
For more information about internationalizing your app, see Internationalization and Localization Guide .

Images

WatchKit provides the following ways to incorporate images into your content:

The WKInterfaceImage displays a single image or a sequence of images as standalone content.

The WKInterfaceGroup, WKInterfaceButton, and WKInterfaceController classes allow you to

specify an image as the background for other content.

Specifying Your Image Assets

Here are guidelines to follow when creating your image assets:

Use the PNG format for images whenever possible.

Always create images that are sized appropriately for your interface. For images whose size you cannot
control, use the setWidth: and setHeight: methods of the interface object to ensure the image is
displayed at a proper size.

Using Named Images to Improve Performance

There are several ways to change the current image of an interface object:

Use the setImageNamed: or setBackgroundImageNamed: methods to assign an image that is already

in the WatchKit app bundle or that is currently in the on-device cache.

Use the setImage:, setImageData:, setBackgroundImage:, or setBackgroundImageData: methods

to transfer image data wirelessly from your WatchKit extension to your WatchKit app.

Specifying images by name is preferred because the only the name string is transferred to Apple Watch, which
takes less time and uses less power than sending the entire image. WatchKit searches your WatchKit app bundle
for an image file with the name you specified. If it does not find an image file in the bundle, it then searches
the device-side image caches for an image with the given name.

Images
Caching Images on the Device

Any time you create a UIImage object in your extension, that image object exists on the users iPhone and
must be sent to Apple Watch before it can be used. Even using the imageNamed: method of UIImage loads
the image from your WatchKit extensions bundle, not from your WatchKit app. If you try to assign that image
to one of your interface objects, the image data is transferred wirelessly to Apple Watch.

Caching Images on the Device

For images you create in your WatchKit extension but use frequently, cache those images on the device and
refer to them by name. You must cache images before you attempt to use them by calling the
addCachedImage:name: or addCachedImageWithData:name: methods of WKInterfaceDevice.
To use a cached image in your interface, do the following:

For WKInterfaceImage objects, call the setImageNamed: method, specifying the name of the cached
image.

For WKInterfaceGroup and WKInterfaceButton objects, call the setBackgroundImageNamed:

method, specifying the name of the cached image.

Important: When caching animated images, use the animatedImageWithImages:duration: method

to create a single UIImage object with all of the animation frames and cache that image. Do not cache the
images for the individual frames separately.
The Apple Watch image caches are limited in size, with each app receiving approximately 20 MB of cache
space. Caches are persistent and can be used between launches of the WatchKit app. When your apps caches
fill up, you must remove existing images from the cache before attempting to add new ones. Use the
removeCachedImageWithName: method to remove a single image or use the removeAllCachedImages
method to clear the caches completely.

Tables

Use tables to display lists of data whose contents change dynamically. WatchKit supports single-column tables
using the WKInterfaceTable class. Displaying data in a table requires defining the layout for your data in
advance and writing code to fill the table with the actual data at runtime. Specifically, you need to do the
following in your Xcode project:

In your storyboard file:

Add a table object to your interface controller scene. Create an outlet for that table in your interface
controller.

Configure one or more row controllers for your table as described in Configuring Row Types (page
48).

In your code:

Define a row controller class for each row controller you defined; see Configuring Row Types (page
48).

At initialization time, add rows to the table as described in Configuring the Tables Contents at
Runtime (page 50).

Respond to interactions with table rows as described in Handling Row Selections (page 52).

For each table, you may define multiple row controller types, each with a different appearance. At runtime,
you specify which row types you need and in what order they should be arranged in the table. For additional
information about how to configure a table, see WKInterfaceTable Class Reference .

Configuring Row Controllers

A row controller is a template for displaying a single row of data in your table. Every table must have at least
one row controller and you may define additional row controllers as needed. For example, you might use
different row controllers for content rows, headers, and footers in your table. When you add a table to your
interface controller scene, Xcode automatically creates an initial row controller, but you can add more.

To add row controllers to a table

Select the table object in your storyboard file.

Tables
Configuring Row Controllers

Open the Attributes inspector.

Use the Rows attribute to change the number of available row controllers.

Each row controller contains a single group element initially. To that group, you addd the labels, images, and
other objects that you want to include in the row. The content for labels and images in a row controller is
irrelevant at design time. At runtime, you replace the content of each item when you configure the row.
Each row controller is backed by a custom class that you use to access the rows contents. Most row controller
classes contain only properties for accessing the rows interface objects; few contain any code. However, if you
add buttons or other interactive controls to a row, your row class can also include action methods for responding
to user interactions with those controls.

To define a custom class for your row controller

Add a new Cocoa Touch class to your WatchKit extension.

Make your new class a subclass of NSObject.

Add declared properties for each label, image, or control that you plan to access at runtime. Use the
following format for declared properties, changing the class to match the class of the corresponding
interface object:
@property (weak, nonatomic) IBOutlet WKInterfaceLabel* label; //
Objective-C

Listing 10-1 shows a sample row controller class definition. In this example, the class contains outlets for an
image and a label.
Listing 10-1 Sample class for managing a row
@interface MainRowType : NSObject
@property (weak, nonatomic) IBOutlet WKInterfaceLabel* rowDescription;
@property (weak, nonatomic) IBOutlet WKInterfaceImage* rowIcon;
@end

You finish the configuration of your row controller in your storyboard file by setting its class and connecting
up any outlets. You must also assign an identifier string to the row. You use that string at runtime when creating
the row.

Tables
Configuring the Tables Contents at Runtime

To configure a row controller in your storyboard

In your storyboard file, select the row controller object.

Set the row controllers Identifier attribute to a unique value for the table.
You use the identifier later on when creating the tables rows. The value must be unique among the
row types of the table but the actual value is at your discretion. Set this value in the Attributes inspector.

Set the class of the row controller to your custom class. Set this value in the Identity inspector.

Connect the labels and other elements to the outlets in your custom class.
Connecting items in your storyboard file to your outlets binds the two together. WatchKit needs this
information to create a rows interface objects at runtime.

Figure 10-1 shows an example of a row controller configured with the identifier mainRowType and the class
MainRowType, which is defined in Listing 10-1 (page 49). The rowDescription and rowIcon outlets in that
class are connected to the image and label objects in the row.
Figure 10-1

Examining a row controller in Xcode

Configuring the Tables Contents at Runtime

At runtime, you add rows to a table and configure the contents of each row programmatically. Add and
configure rows as part of your interface controllers initialization process.

Tables
Configuring the Tables Contents at Runtime

To create and configure the rows of a table

Determine the number and type of rows you want, based on the data you want to display.

Use the setRowTypes: or setNumberOfRows:withRowType: method to create the rows.

Both methods create the rows in your interface and instantiate each rows corresponding class in your
WatchKit extension. The instantiated classes are stored in the table and accessible using the
rowControllerAtIndex: method.

Iterate over the rows using the rowControllerAtIndex: method.

Use the row controller objects to configure the row contents.

The setRowTypes: or setNumberOfRows:withRowType: methods instantiate the classes associated with

the corresponding row controllers. Immediately after calling one of those methods, retrieve the newly created
row controller objects and use them to configure the rows. Listing 10-2 shows a simple example that uses
some provided data to configure a label and image for a row. The data is provided by an array of custom data
objects of type MyDataObject. (The MyDataObject class exposes a string and image as properties and its
implementation is not shown here.) The rows themselves are instances of the custom MainRowType class,
whose definition is shown in Listing 10-1 (page 49).
Listing 10-2 Creating and configuring the rows of a table
- (void)configureTableWithData:(NSArray*)dataObjects {
[self.table setNumberOfRows:[dataObjects count] withRowType:@"mainRowType"];
for (NSInteger i = 0; i < self.table.numberOfRows; i++) {
MainRowType* theRow = [self.table rowControllerAtIndex:i];
MyDataObject* dataObj = [dataObjects objectAtIndex:i];

[theRow.rowDescription setText:dataObj.text];
[theRow.rowIcon setImage:dataObj.image];
}
}

When configuring tables, you can improve performance by limiting the number of rows you create initially.
Because table rows must all be created up front, creating large numbers of rows can adversely affect the
performance of your app. The precise number of rows depends on the complexity of your data and how long
it takes you to create each one, but consider keeping the total number of rows to 20 or fewer. For tables that
require more rows, consider loading only a subset of rows initially and providing the user with controls to load

Tables
Handling Row Selections

more rows. An even better solution is to display only the most important subset of rows. For example, you
might use location data to limit the number of rows to those that are most relevant to the users current
location.

Handling Row Selections

An interface controller is responsible for handling row selections in any tables it owns. When the user taps the
row of a table, WatchKit selects the row and calls the appropriate method in your WatchKit extension. You can
handle row selections in one of two places:

In the interface controllers table:didSelectRowAtIndex: method

In a custom action method that you define on your interface controller

You can use either technique to handle row selections. If your interface controller has more than one table,
using an action method might be preferable because you do not have to identify which table was involved. If
you implement an action method for your table, it must have the following syntax:
- (IBAction)myTableAction:(NSInteger)rowIndex

Use the selection of a table row to perform any relevant actions for your app. For example, you might display
a new interface controller or update the rows content. If you do not want a table row to be selectable, disable
the Selectable option for the corresponding row controller in your storyboard.

Context Menus

The Retina display with Force Touch found on Apple Watch provides a new way to interact with content.
Instead of just tapping items on the screen, pressing the screen with a small amount of force activates the
context menu (if any) associated with the current interface controller. WatchKit displays the menu over your
content, as shown in Figure 11-1.
Figure 11-1

A context menu with three items

Context menus are optional. You use a context menu to display actions related to the current screen and a
context menu can display up to four actions. Each action is represented by a title string and an image. Tapping
an actions image dismisses the menu and executes the action method associated with that menu item. Tapping
anywhere else dismisses the menu without any further action.

Designing Your Menu Items

Each menu item consists of a tappable area and a title. The tappable area contains a circular background, on
top of which sits an image that you provide. The image must be a template image, where the alpha channel
defines the shape to draw on top of the background. Opaque portions of the image show up as black and fully
or partially transparent portions let the background color show through.

Context Menus
Adding a Context Menu to an Interface Controller

The template images you provide should be smaller than the circular background on which they sit. For more
information about the size of menu images and guidelines for how to create them, see Apple Watch Human
Interface Guidelines .

Adding a Context Menu to an Interface Controller

You configure an interface controllers context menu at design time, but you can also add and remove menu
items at runtime. At design time, edit your storyboard to include the menu items that you always want to be
present on the menu for a given interface controller. When you initialize your interface controller later, you
can add menu items to supplement the ones you created in your storyboard. Menu items you add
programmatically can also be removed. The total number of menu items in a menu cannot exceed four,
regardless of whether you included them in your storyboard or added them programmatically.

To add a context menu to an interface controller

Open your storyboard file.

Drag a menu object from the library and add it to your interface controller scene.
The initial menu contains a single menu item.

Drag up to three more items from the library to your menu.

You can also use the Attributes inspector of the menu to set the number of items. The items you add
cannot be removed programmatically later.

For each item, use the Attributes inspector to specify the menus title and image. Both are required.

Connect each menu item to an action method in your interface controller class.
Menu action methods have the following format:
- (IBAction)doMenuItemAction

Save your storyboard file.

To add menu items at runtime, call the addMenuItemWithImage:title:action: or

addMenuItemWithImageNamed:title:action: method of your interface controller object. The items you
add are appended to the ones in your storyboard file. Items added programmatically remain attached to the
menu until you explicitly remove them or until your interface controller is deallocated.

Context Menus
Handling Taps in a Menu Item

Handling Taps in a Menu Item

When the user taps a menu item, WatchKit dismisses the menu and calls the associated action method. You
define action methods in your interface controller and use the following syntax:
- (IBAction)menuItemAction {
// Handle menu action.
}

If any state information is required to perform the action, it is your responsibility to store and maintain that
information in your interface controller object. For example, if an action relies on the currently selected row
of a table, your interface controller would include a variable to track the most recently selected row. Also, if
you want to request more information from the user after tapping a menu action, use your action method to
present a modal interface controller.

Glances

Glance Essentials (page 57)

Managing Your Glance Interface (page 59)

Glance Essentials

A glance is a supplemental way for the user to view important information from your app. Not all apps need
a glance. A glance provides immediately relevant information in a timely manner. For example, the glance for
a calendar app might show information about the users next meeting, while the glance for an airline app
might display gate information for an upcoming flight. Figure 12-1 shows the glance for the Lister sample app,
which displays the number of completed items and the number of remaining items on the users to-do list.
Figure 12-1

Glance interface for the Lister sample app

Glance Essentials
The Glance Life Cycle

Glances are delivered as part of your WatchKit app and WatchKit extension. The interface for your glance resides
in your WatchKit apps existing storyboard file and that interface is managed by a custom
WKInterfaceController object. However, the only job of your glance interface controller is to set the
contents of the glance. Glances do not support interactivity, and tapping on a glance automatically launches
your WatchKit app.

The Glance Life Cycle

The life cycle of a glance interface controller is the same as for other interface controllers except that glance
interface controllers are initialized early so that the glance be displayed quickly to the user. Because a nontrivial
amount of time can elapse between the initialization and display of a glance, include checks in your
willActivate method to make sure the information being displayed is up-to-date.
For information about the life cycle of interface controllers, see WatchKit Extension Life Cycle (page 20).

Glance Interface Guidelines

Xcode provides fixed layouts for arranging the contents of your glance. After choosing a layout that works for
your content, use the following guidelines to fill in that content:

Design your glance to convey information quickly. Do not display a wall of text. Make appropriate use of
graphics, colors, and animation to convey information.

Focus on the most important data. A glance is not a replacement for your WatchKit app. Just as your
WatchKit app is a trimmed down version of its containing iOS app, a glance is a trimmed down version of
your WatchKit app.

Do not include interactive controls in your glance interface. Interactive controls include buttons, switches,
sliders, and menus.

Avoid tables and maps in your glance interface. While not prohibited, the limited space makes tables and
maps less useful.

Be timely with the information you display. Use all available resources, including time and location to
provide information that matters to the user. And remember to update your glance to account for changes
that occur between the time your interface controller is initialized and the time it is displayed to the user.

An app has only one glance interface controller, so that one controller must be able to display the data you
want.

Managing Your Glance Interface

When adding a WatchKit app target to your Xcode project, you can specify whether you want a glance interface.
You can also add a glance to your project later if you forget to add one initially. A glance interface controller
has a slightly different appearance in your apps storyboard. Specifically, it has a Glance Entry Point object
attached to it and it has a default layout, as shown in Figure 13-1.
Figure 13-1

An interface controller with the glance entry point object

To configure the contents of your glance at runtime, you use a custom WKInterfaceController subclass.
You implement this subclass in the same way that you implement other interface controller classes in your
WatchKit app.

Managing Your Glance Interface

Adding a Glance Interface to Your App

When creating the WatchKit App target for your app, enable the Include Glance Scene option to create the
corresponding files you need to implement your glance interface. Xcode provides you with a glance storyboard
scene and a custom glance interface controller class. If you did not enable this option when creating your
target, configure your project manually.

Creating a glance interface manually

In your project, create a new WKInterfaceController subclass.

Create the new source file and add it to your WatchKit extension target. Give your subclass an
appropriate name, like GlanceInterfaceController.

In your storyboard file, drag a Glance Interface Controller to your storyboard.

The scene for your new glance interface controller has the Glance Entry Point object attached to it and
looks similar to the scene shown in Figure 13-1 (page 59).

Select the glance interface controller in your storyboard and open the Identity inspector.

Set the class of your glance interface controller to the class you created in Step 1.

WatchKit apps may have only one glance interface. Do not add more than one glance interface controller to
your apps storyboard.

Implementing a Glance Interface Controller

The implementation of a glance interface controller is relatively simple because its only job is to set the content
of the labels and images in the glance. So your glance typically implements only two methods:

Use the init and awakeWithContext: methods to initialize your glance interface and set the initial
values for its labels and images.

Use the willActivate to update the glance interface as needed based on recent changes.

To update the content of a glance after it is onscreen, use an NSTimer object to perform periodic updates.
You do not need to update WKInterfaceDate and WKInterfaceTimer objects, which automatically update
themselves.

Managing Your Glance Interface

Customizing App Launch From Your Glance

When the user taps a glance, Apple Watch launches the corresponding WatchKit app. Normally, launching the
app displays its main interface controller. If you want to display a different interface controller at launch time,
call the updateUserActivity:userInfo: method from your glance interface controller and use it to provide
contextual information about what the glance is doing. At launch time, your app can use that contextual data
to display a different interface controller.
Calling the updateUserActivity:userInfo: method tells WatchKit to call the main interface controllers
handleUserActivity: method at launch time. In your implementation of the handleUserActivity:
method, use the provided contextual data to configure your UI appropriately. For example, an app with a
page-based interface might use the provided data to select which page to display initially.
To summarize, to display a different interface controller when launching from your glance, do the following:

In the glance interface controller:

Configure the glance normally in the init and willActivate methods.

Call the updateUserActivity:userInfo: method and use the userInfo parameter to convey
information about the state of the glance to your app.

In your apps main interface controller:

Implement the handleUserActivity: method. Use the provided userInfo dictionary to configure
your UI appropriately.

Notifications

Notification Essentials (page 63)

Custom Notification Interfaces (page 69)

Notification Essentials

If your iOS app supports local or remote notifications, Apple Watch display those notifications at appropriate
times. When one of your apps local or remote notification arrives on the users iPhone, iOS decides whether
to display that notification on the iPhone or on Apple Watch. For notifications sent to Apple Watch, the system
lets the the user know subtly that a notification is available. If the user chooses to view the notification, the
system displays an abbreviated version of the notification first, followed by a more detailed version. The user
can dismiss the detailed notification, launch your WatchKit app, or act on the notification by tapping an available
action button.
Apps are not required to do anything to support notifications. The system provides a default notification
interface that displays the alert message from the notification. However, apps can customize the notification
interface and include custom graphics, content, and branding.

Notification Essentials
The Short-Look Interface

Note: Apple Watch displays local and remote notifications only if the containing iOS supports them.
For information about how to support local and remote notifications in your iOS app, see Local and
Remote Notification Programming Guide .

The Short-Look Interface

When the user first looks at a notification, the system displays the short-look interface, an example of which
is shown in Figure 14-1. The short-look interface is a nonscrolling screen that cannot be customized. The system
uses a template to display the app name and icon along with the title string stored in the local notification or
remote notification payload. If the user continues to look at the notification, the system transitions quickly
from the short-look interface to the long-look interface.

Notification Essentials
The Long-Look Interface

Figure 14-1

A short-look interface

The Long-Look Interface

The long-look interface is a scrollable screen that displays the notifications content and any associated action
buttons. If you do not provide a custom notification interface, Apple Watch displays a default interface that
includes your app icon, the title string of the notification, and the alert message. If you provide a custom
notification interface, Apple Watch displays your custom interface instead.
The long-look notification interface is divided into three areas:

The sash is an overlay that contains the app icon and app name. The sash is partially transparent by default
but you can customize the color in your custom notification interfaces.

Notification Essentials
The Long-Look Interface

The content area contains the detailed information about the incoming notification. For custom interfaces,
you can configure this area to start underneath the sash or just below it. For information on how to
customize the content in this area, see Custom Notification Interfaces (page 69).

The bottom area contains a Dismiss button and any action buttons registered by the containing iOS app.

Figure 14-2 shows an example of a long-look notification containing two action buttons.
Figure 14-2

A long-look notification interface

Tapping anywhere in the sash or content area launches your WatchKit app. Tapping one of the app-defined
action buttons delivers the selected action to either your iOS app or your WatchKit app. Foreground actions
are delivered to your WatchKit app and extension while background actions are delivered to your iOS app.
Tapping the Dismiss button closes the notification interface without any further actions.

Notification Essentials
Adding Action Buttons to Notifications

For information about how to provide a custom long-look interface for your app, see Custom Notification
Interfaces (page 69).

Adding Action Buttons to Notifications

Action buttons save time for the user by offering canned responses to a notification. Apple Watch makes use
of the interactive notifications registered by your iOS app to display action buttons. In iOS 8 and later, apps
are required to register the types of notification-generated alerts they display using a
UIUserNotificationSettings object. When registering that information, the app can also register a set
of custom notification categories, which include the actions that can be performed for that category. Apple
Watch uses this category information to add the corresponding action buttons to the long-look interface.
Listing 14-1 shows a partial implementation of a method that registers the settings and categories for a sample
iOS app. This method is implemented by the containing iOS app, not the WatchKit extension, and is called by
the iOS app delegate at launch time. The implementation shows the creation and registration of an invitation
category that contains actions to accept or decline a meeting invitation.
Listing 14-1 Registering actions in a containing iOS app
func registerSettingsAndCategories() {
var categories = NSMutableSet()

var acceptAction = UIMutableUserNotificationAction()

acceptAction.title = NSLocalizedString("Accept", comment: "Accept invitation")
acceptAction.identifier = "accept"
acceptAction.activationMode = UIUserNotificationActivationMode.Background
acceptAction.authenticationRequired = false

var declineAction = UIMutableUserNotificationAction()

declineAction.title = NSLocalizedString("Decline", comment: "Decline invitation")
declineAction.identifier = "decline"
declineAction.activationMode = UIUserNotificationActivationMode.Background
declineAction.authenticationRequired = false

var inviteCategory = UIMutableUserNotificationCategory()

inviteCategory.setActions([acceptAction, declineAction],
forContext: UIUserNotificationActionContext.Default)

Notification Essentials
Responding to Taps in Action Buttons

inviteCategory.identifier = "invitation"

categories.addObject(inviteCategory)

// Configure other actions and categories and add them to the set...
var settings = UIUserNotificationSettings(forTypes: (.Alert | .Badge | .Sound),
categories: categories)

UIApplication.sharedApplication().registerUserNotificationSettings(settings)
}

For information about how to configure categories and actions in your iOS app, see Local and Remote Notification
Programming Guide .

Responding to Taps in Action Buttons

When the user taps an action button for a notification, the system uses the information in the registered
UIUserNotificationAction object to determine how to process the action. Actions can be processed in
the foreground or the background and with or without requiring user authentication. However, foreground
and background actions are processed differently:

Foreground actions launch your WatchKit app and deliver the ID of the tapped button to the
handleActionWithIdentifier:forRemoteNotification: or
handleActionWithIdentifier:forLocalNotification: method of your main interface controller.

Background actions launch the containing iOS app in the background so that it can process the action.
Information about the selected action is delivered to the
application:handleActionWithIdentifier:forRemoteNotification:completionHandler:

or application:handleActionWithIdentifier:forLocalNotification:completionHandler:
method of the app delegate.
For foreground actions, it is important to note that your WKUserNotificationInterfaceController
subclass does not process the action. Selecting a foreground action launches your app and loads the interface
controller for your apps main entry point. It is this initial interface controller that is responsible for processing
any actions. That interface controller must implement the
handleActionWithIdentifier:forRemoteNotification: and
handleActionWithIdentifier:forLocalNotification: methods (as appropriate) to process actions.

Managing a Custom Long Look Interface

The custom long look notification interface consists of two separate interfaces: one static and one dynamic.
The dynamic interface displays a fully customized version of the notifications content, and can include custom
content and graphics provided by your WatchKit extension. The static interface is a simpler interface that
contains only the notifications alert message and any static images and text that you configure at design time.
When you add a new notification interface controller to your storyboard file, Xcode creates separate storyboard
scenes for the static and dynamic interfaces, as shown in Figure 15-1. The static scene is required but the
dynamic scene is optional. (In fact, delete the dynamic scene if you can display everything you want using the
static interface and do not need to configure the notification dynamically.) The static and dynamic scenes are
associated with the same notification type, which you configure using the notification category object attached
to the static scene.
Figure 15-1

Static and dynamic notification interfaces

When a notification of the correct type arrives, WatchKit chooses your static or dynamic interface based on
several factors. If a dynamic interface is not available, if there is not enough power to warrant displaying the
dynamic interface, or if you explicitly tell WatchKit not to display the dynamic interface, WatchKit displays the
static interface. In all other cases, WatchKit chooses your dynamic interface. After making the choice, WatchKit

Managing a Custom Long Look Interface

Adding a Custom Notification Interface to Your App

loads the appropriate storyboard resources and prepares the interface as shown in Figure 15-2. The loading
process for the dynamic interface is mostly the same as for your apps other interface controllers, with the
exception of processing the notification payload, which is specific to notification interface controllers.
Figure 15-2

Preparing the notification interface

Adding a Custom Notification Interface to Your App

When creating the WatchKit App target for your app, enable the Include Notification Scene option to create
the corresponding files you need to implement one of your notification interfaces. Xcode provides you with
an empty storyboard scene and a custom subclass to use for your notification interface controller. If you did
not enable this option when creating your target, or if you need to create additional notification interfaces,
create the notification interface manually.

Creating a notification interface manually

In your project, create a new WKUserNotificationInterfaceController subclass.

Create the new source file and add it to your WatchKit extension target. Give your subclass an
appropriate name that distinguishes it from your other notification interface controllers.

In your storyboard file, drag a Notification Interface Controller to your storyboard.

The scene for your new notification interface controller has the Notification Category object attached
to it and looks similar to the scene shown in Figure 15-1 (page 69).

Select the notification interface controller in your storyboard and open the Identity inspector.

Set the class of your notification interface controller to the class you created in Step 1.

Apps may have multiple notification interfaces, which you differentiate using categories. In your storyboard
file, use the Notification Category object to specify the category name associated with each scene. WatchKit
uses the category value to determine which scene to load at runtime. If an incoming notification does not

Managing a Custom Long Look Interface

Configuring the Category of a Custom Interface

have a category, WatchKit loads the scene whose category name is set to default. For more information
about how to specify the category of a notification interface, see Configuring the Category of a Custom
Interface (page 71).

Configuring the Category of a Custom Interface

Each notification interface must have an assigned notification category that tells Apple Watch when to use it.
Incoming notifications can include a category key in their payload, the value of which is a string you define.
Apple Watch uses that category to decide which of your notification scenes to display. If an incoming notification
does not include a category string, Apple Watch displays the notification interface configured with the default
category.
To assign a notification type to your notification interface, select the Notification Category object in your
storyboard and go to the Attributes inspector, shown in Figure 15-3. Enter the category name in the Name
field of the inspector. You can also set the sash color and title text color for your custom interface in the
inspector.
Figure 15-3

Configuring the notification type information

When generating remote notifications, your server specifies the notification type by including the category
key in the aps dictionary of the payload. For local notifications, you specify this value in the category property
of the UILocalNotification object.

Managing a Custom Long Look Interface

Configuring the Static Notification Interface

Note: The category string also defines which action buttons (if any) are appended to the end of
your notification interface. For more information on supporting custom actions, see Adding Action
Buttons to Notifications (page 67).

Configuring the Static Notification Interface

Use the static notification interface to define a simple version of your custom notification interface. The purpose
of a static interface is to provide a fallback interface in the event that your WatchKit extension is unable to
configure the dynamic interface in a timely manner. The rules for creating a static interface are as follows:

All images must reside in the WatchKit app bundle.

The interface must not include controls, tables, maps, or other interactive elements.

The interfaces notificationAlertLabel outlet must be connected to a label. The labels contents are
set to the notifications alert message. The text for all other labels does not change and is whatever is
specified in your storyboard file.

Managing a Custom Long Look Interface

Configuring a Dynamic Notification Interface

Figure 15-4 shows the configuration of the static and dynamic scenes for a custom notification interface in a
calendar app. The notification arrow points to the static scene, which contains a custom icon and two labels.
In the static interface, the label containing the string <message> is the one associated with the
notificationAlertLabel outlet and therefore receives the notifications alert message at runtime.
Figure 15-4

Static and dynamic scenes for a single notification type

Configuring a Dynamic Notification Interface

A dynamic notification interface lets you provide a more enriched notification experience for the user. Using
a dynamic interface, you can display more than just the alert message. You can incorporate additional
information, configure more than one label, display dynamically generated content, and so on.
Implementing a dynamic notification interface requires the creation of a custom
WKUserNotificationInterfaceController subclass. Your implementation of that subclass is responsible
for configuring the notification interface when a notification of the appropriate type arrives.

Managing a Custom Long Look Interface

Configuring a Dynamic Notification Interface

Designing Your Dynamic Interface

Configure your dynamic interface like you would any other interface controller scene. Include outlets in your
subclass to refer to labels, images, and other objects in the scene, and use those outlets to configure the
contents of the scene at runtime. Tapping your notification interface launches the app, so notification interfaces
should not contain interactive controls.

Use labels, images, groups, and separators for most of your interface.

You may include tables and maps as needed in your interface.

Do not include buttons, switches, or other interactive controls.

Configuring Your Dynamic Interface at Runtime

When a notification of the appropriate type arrives, WatchKit displays the appropriate scene from your storyboard
and asks your WatchKit extension to instantiate the corresponding
WKUserNotificationInterfaceController subclass. Figure 15-5 shows the steps that WatchKit takes
to prepare your interface. After initializing the notification interface controller, WatchKit delivers the payload
data to it using either the didReceiveRemoteNotification:withCompletion: or
didReceiveLocalNotification:withCompletion: method. You use the payload data to configure the
rest of your notification interface and then call the provided completion handler block to let WatchKit know
your interface is ready.
Figure 15-5

Configuring the dynamic notification interface

Managing a Custom Long Look Interface

Configuring a Dynamic Notification Interface

Always use the didReceiveRemoteNotification:withCompletion: and

didReceiveLocalNotification:withCompletion: methods to configure your notification interface.
When implementing either method, execute the provided completion handler as soon as you are done
configuring the interface. It is important to execute the block as soon as possible. If you wait too long, Apple
Watch abandons the attempt to display your dynamic interface and displays the static interface instead.
Listing 15-1 shows a sample implementation of the didReceiveRemoteNotification:withCompletion:
method. This method is implemented by a fictional calendar app that sends remote notifications for new
meeting invitations. The method extracts data from the remote notifications payload and uses that data to
set values for labels in the notification interface. For brevity, the example assumes that the server always
includes an appropriate value for each key but your own code should perform whatever error checking is
necessary to ensure the payload data is valid. After configuring the labels, the method calls the completion
handler to let WatchKit know that the custom interface is ready to be displayed.
Listing 15-1 Configuring the custom interface from a remote notification
// Standard remote notification payload keys.
NSString* apsKeyString = @"aps";
NSString* titleKeyString = @"title";

// Payload keys that are specific to the app.

NSString* customDataKey = @"cal";
NSString* invitationDateKey = @"date";
NSString* invitationLocationKey = @"loc";
NSString* invitationNotesKey = @"note";

- (void)didReceiveRemoteNotification:(NSDictionary *)remoteNotification
withCompletion:(void(^)(WKUserNotificationInterfaceType interface)) completionHandler
{
// Get the aps dictionary from the payload.
NSDictionary* apsDict = [remoteNotification objectForKey:apsKeyString];

// Retrieve the title of the invitation.

NSString* titleString = [apsDict objectForKey:titleKeyString];
[self.titleLabel setText:titleString];

// Extract the date and time from the custom section of the payload.
// The date/time information is stored as the number of seconds since 1970.

Managing a Custom Long Look Interface

Configuring a Dynamic Notification Interface

NSDictionary* customDataDict = [remoteNotification objectForKey:customDataKey];

NSNumber* dateValue = [customDataDict objectForKey:invitationDateKey];
NSDate* inviteDate = [NSDate dateWithTimeIntervalSince1970:[dateValue
doubleValue]];

// Format the date and time strings.

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];

// Call a custom method to get the localized date format string for the user.
// The default date format string is "EEE, MMM d".
dateFormatter.dateFormat = [self dateFormatForCurrentUser];
NSString *formattedDateString = [dateFormatter stringFromDate:inviteDate];

// Call a custom method to get the localized time format string for the user.
// The default time format string is "h:mm a".
dateFormatter.dateFormat = [self timeFormatForCurrentUser];
NSString *formattedTimeString = [dateFormatter stringFromDate:inviteDate];

// Set the date and time in the corresponding labels.

[self.dateLabel setText:formattedDateString];
[self.timeLabel setText:formattedTimeString];

// Set the location of the meeting.

NSString* locationString = [customDataDict objectForKey:invitationLocationKey];
[self.locationLabel setText:locationString];

// Set the invitation's notes (if any).

NSString* notesString = [customDataDict objectForKey:invitationNotesKey];
[self.notesLabel setText:notesString];

// Tell WatchKit to display the custom interface.

completionHandler(WKUserNotificationInterfaceTypeCustom);
}

Managing a Custom Long Look Interface

Testing Your Custom Interface

When calling the completion handler block, specify the WKUserNotificationInterfaceTypeDefault

constant if you want WatchKit to display your static interface instead.

Testing Your Custom Interface

When you are ready to test your dynamic interface in the simulator, create a custom build scheme for running
your notification interface if you have not done so already. When configuring the interface, specify the JSON
data file containing the test data you want delivered to your interface. Xcode provides custom JSON files for
specifying this data.
For more information about setting up the build schemes and configuring your payload data, see The Build,
Run, Debug Process (page 13).

Document Revision History

This table describes the changes to Apple Watch Programming Guide .

Date

Notes

2015-01-12

New document that describes how to use the WatchKit framework to

write apps for Apple Watch.

Apple Inc.
Copyright 2015 Apple Inc.
All rights reserved.
No part of this publication may be reproduced,
stored in a retrieval system, or transmitted, in any
form or by any means, mechanical, electronic,
photocopying, recording, or otherwise, without
prior written permission of Apple Inc., with the
following exceptions: Any person is hereby
authorized to store documentation on a single
computer or device for personal use only and to
print copies of documentation for personal use
provided that the documentation contains
Apples copyright notice.
No licenses, express or implied, are granted with
respect to any of the technology described in this
document. Apple retains all intellectual property
rights associated with the technology described
in this document. This document is intended to
assist application developers to develop
applications only for Apple-branded products.
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
408-996-1010
Apple, the Apple logo, Cocoa, Cocoa Touch,
iPhone, Objective-C, OS X, and Xcode are
trademarks of Apple Inc., registered in the U.S.
and other countries.
Retina is a trademark of Apple Inc.
App Store is a service mark of Apple Inc.
IOS is a trademark or registered trademark of
Cisco in the U.S. and other countries and is used
under license.
APPLE MAKES NO WARRANTY OR REPRESENTATION,
EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS
DOCUMENT, ITS QUALITY, ACCURACY,
MERCHANTABILITY, OR FITNESS FOR A PARTICULAR
PURPOSE. AS A RESULT, THIS DOCUMENT IS PROVIDED
AS IS, AND YOU, THE READER, ARE ASSUMING THE
ENTIRE RISK AS TO ITS QUALITY AND ACCURACY.
IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES RESULTING FROM ANY DEFECT, ERROR OR
INACCURACY IN THIS DOCUMENT, even if advised of
the possibility of such damages.
Some jurisdictions do not allow the exclusion of
implied warranties or liability, so the above exclusion
may not apply to you.

คัมภีร์เต้าเต๋อจิง 81 บท เหลาจื่อ
100% (2)
คัมภีร์เต้าเต๋อจิง 81 บท เหลาจื่อ
38 pages
Swiftui Ios17 Beginner Book
No ratings yet
Swiftui Ios17 Beginner Book
670 pages
Patcher FL
No ratings yet
Patcher FL
25 pages
Nike Size Charts: Infant, Toddler, Preschool Kids and Older Kids
No ratings yet
Nike Size Charts: Infant, Toddler, Preschool Kids and Older Kids
3 pages
XS Sports Nutrition FAQs
No ratings yet
XS Sports Nutrition FAQs
12 pages
Entitlement Key Reference
No ratings yet
Entitlement Key Reference
33 pages
(Ebook - PDF) Untold Windows Tips and Secrets (Ankit Fadia)
100% (1)
(Ebook - PDF) Untold Windows Tips and Secrets (Ankit Fadia)
22 pages
Heimdall For Flashing
No ratings yet
Heimdall For Flashing
3 pages
Safari Extension Guide
No ratings yet
Safari Extension Guide
102 pages
Magento 2 Diy Sample
0% (1)
Magento 2 Diy Sample
13 pages
View Controller PG For I Phone Os
No ratings yet
View Controller PG For I Phone Os
50 pages
Goodman GMH8 GDH8 DualSaver Gas Furnace Installation Instructions
No ratings yet
Goodman GMH8 GDH8 DualSaver Gas Furnace Installation Instructions
32 pages
Creating Epoxy Tables
No ratings yet
Creating Epoxy Tables
2 pages
How To Build Your First Robot ! Full, Step by Step Instructions
No ratings yet
How To Build Your First Robot ! Full, Step by Step Instructions
51 pages
THESIS - Emerson Network Power
100% (1)
THESIS - Emerson Network Power
41 pages
Links WOW
No ratings yet
Links WOW
1 page
The Researchers Digital Toolbox
100% (1)
The Researchers Digital Toolbox
94 pages
DTC P1345 Crankshaft Position (CKP) - Camshaft Position (CMP) Correlation
No ratings yet
DTC P1345 Crankshaft Position (CKP) - Camshaft Position (CMP) Correlation
5 pages
Photoshop Tutorial
No ratings yet
Photoshop Tutorial
15 pages
Goodman Gmvs80 u Service Manual
No ratings yet
Goodman Gmvs80 u Service Manual
38 pages
C CCCCCCCCC C C
No ratings yet
C CCCCCCCCC C C
6 pages
Coding User - Vol 6 2023
No ratings yet
Coding User - Vol 6 2023
96 pages
Universal Remote Control Guide: Service Provided by
No ratings yet
Universal Remote Control Guide: Service Provided by
12 pages
Step by Step Guide Book On Home Wiring PDF
No ratings yet
Step by Step Guide Book On Home Wiring PDF
50 pages
Ipad For Beginners 5th Edition 2021
No ratings yet
Ipad For Beginners 5th Edition 2021
116 pages
IPL
No ratings yet
IPL
628 pages
Andrew Thompson - Biking Stuff
No ratings yet
Andrew Thompson - Biking Stuff
120 pages
Build Your Own Carpc
No ratings yet
Build Your Own Carpc
15 pages
Stay Smart Online
No ratings yet
Stay Smart Online
11 pages
AdGuard Settings - Home Assistant
No ratings yet
AdGuard Settings - Home Assistant
3 pages
AppleWatchProgrammingGuide PDF
100% (1)
AppleWatchProgrammingGuide PDF
81 pages
AP ExtensibilityPG 2015 03 09
No ratings yet
AP ExtensibilityPG 2015 03 09
102 pages
Whats New in iOS
No ratings yet
Whats New in iOS
108 pages
Apple Watch App Development
From Everand
Apple Watch App Development
Steven F. Daniel
No ratings yet
I Phone App Programming Guide
No ratings yet
I Phone App Programming Guide
118 pages
WWDC 2020 Viewing Guide
No ratings yet
WWDC 2020 Viewing Guide
13 pages
I Phone App Programming Guide
No ratings yet
I Phone App Programming Guide
118 pages
I Phone App Programming Guide - Guiders
No ratings yet
I Phone App Programming Guide - Guiders
153 pages
App Intents Spotlight Integration Using Shortcuts…
No ratings yet
App Intents Spotlight Integration Using Shortcuts…
1 page
iOS App Programming Guide
100% (2)
iOS App Programming Guide
137 pages
Extensibility PG
No ratings yet
Extensibility PG
96 pages
i Phone App Programming Guide
No ratings yet
i Phone App Programming Guide
119 pages
iOS Phone App Programming Guide
No ratings yet
iOS Phone App Programming Guide
136 pages
MOSXApp Programming Guide
No ratings yet
MOSXApp Programming Guide
92 pages
MOSXApp Programming Guide
No ratings yet
MOSXApp Programming Guide
92 pages
SwiftUI - A New Beginning - Asynchronous Programming With SwiftUI and Combine - Functional Programming To Build UIs On Apple Platforms
No ratings yet
SwiftUI - A New Beginning - Asynchronous Programming With SwiftUI and Combine - Functional Programming To Build UIs On Apple Platforms
18 pages
App Extensions iOS
100% (1)
App Extensions iOS
96 pages
01FE17BCS115
No ratings yet
01FE17BCS115
45 pages
Supermarket_Billing_System PROJECT
No ratings yet
Supermarket_Billing_System PROJECT
34 pages
Library Management System: Latika Ahuja
No ratings yet
Library Management System: Latika Ahuja
103 pages
Implementing-Value Stream Mapping
No ratings yet
Implementing-Value Stream Mapping
24 pages
An iOS Developer's Guide to SwiftUI: Design and build beautiful apps quickly and easily with minimum code
From Everand
An iOS Developer's Guide to SwiftUI: Design and build beautiful apps quickly and easily with minimum code
Michele Fadda
No ratings yet
Your First iOS Application: General
No ratings yet
Your First iOS Application: General
54 pages
iOS DEVELOPER Interview Questions
No ratings yet
iOS DEVELOPER Interview Questions
6 pages
Your First iOS Application: General
No ratings yet
Your First iOS Application: General
54 pages
Mobil 2
No ratings yet
Mobil 2
16 pages
karthik_ppt
No ratings yet
karthik_ppt
40 pages
Your First iOS Application: General
No ratings yet
Your First iOS Application: General
54 pages
I Phone App Programming Guide
No ratings yet
I Phone App Programming Guide
153 pages
1.1 History of Locks (Smart Electro Glas)
No ratings yet
1.1 History of Locks (Smart Electro Glas)
51 pages
Headfirst Into IOS Development
No ratings yet
Headfirst Into IOS Development
66 pages
Xcode Quick Start Guide
No ratings yet
Xcode Quick Start Guide
54 pages
Venkat_Resume
No ratings yet
Venkat_Resume
6 pages
2015 Form 10-K As-Filed
No ratings yet
2015 Form 10-K As-Filed
84 pages
Apple Return of Capital Timeline Q216
No ratings yet
Apple Return of Capital Timeline Q216
1 page
Apple SR 2016 Progress Report
No ratings yet
Apple SR 2016 Progress Report
33 pages
Amway Media Guide Brochure
No ratings yet
Amway Media Guide Brochure
13 pages
Apple Environmental Responsibility Report 2016
No ratings yet
Apple Environmental Responsibility Report 2016
50 pages
XS Sports Nutrilite Product Guide
No ratings yet
XS Sports Nutrilite Product Guide
8 pages
Xcode Release Notes
No ratings yet
Xcode Release Notes
142 pages
Whats New in OSX
No ratings yet
Whats New in OSX
103 pages
Truvivity by Nutrilite
No ratings yet
Truvivity by Nutrilite
10 pages
Body Key 2015
No ratings yet
Body Key 2015
20 pages
Global Phytonutrient Report Commissioned by The Nutrilite Health Institute
100% (1)
Global Phytonutrient Report Commissioned by The Nutrilite Health Institute
22 pages
History
No ratings yet
History
117 pages
Logdhwhx
No ratings yet
Logdhwhx
6 pages
log
No ratings yet
log
3 pages
TF Classnotes
No ratings yet
TF Classnotes
4 pages
log
No ratings yet
log
2 pages
Arma 3 Mission Editor Guide
No ratings yet
Arma 3 Mission Editor Guide
332 pages
Log
No ratings yet
Log
2 pages
Game Save File
No ratings yet
Game Save File
3 pages
Logs GG Crack
No ratings yet
Logs GG Crack
121 pages
GDSN
No ratings yet
GDSN
2 pages
log
No ratings yet
log
2 pages
Kontakt Player Developer Guide
No ratings yet
Kontakt Player Developer Guide
37 pages
SikuliX-1 1 1
No ratings yet
SikuliX-1 1 1
4 pages
Log
No ratings yet
Log
7 pages
Log
No ratings yet
Log
2 pages
Android Studio Gradul Install
No ratings yet
Android Studio Gradul Install
9 pages
Hydrasynth Manager Guide 2.0.0
No ratings yet
Hydrasynth Manager Guide 2.0.0
10 pages
Log
No ratings yet
Log
9,436 pages
Log
No ratings yet
Log
6 pages
stdout
No ratings yet
stdout
957 pages
log
No ratings yet
log
4 pages
Logs
0% (1)
Logs
14 pages
Log
No ratings yet
Log
2 pages
2024-12-12
No ratings yet
2024-12-12
27 pages
Log
No ratings yet
Log
2 pages
V6 SuperCharger For Android-Update9 RC12-BlackDog-63457 Fix - SH
No ratings yet
V6 SuperCharger For Android-Update9 RC12-BlackDog-63457 Fix - SH
218 pages
MTB License Log
No ratings yet
MTB License Log
6 pages
Master Drive 6RA70 Parameter List
100% (3)
Master Drive 6RA70 Parameter List
186 pages
Log
No ratings yet
Log
2 pages
Log
No ratings yet
Log
2 pages