A class that provides the infrastructure for managing the interface in a watchOS app.
- iOS 8.2+
- watchOS 2.0+
An interface controller serves the same purpose as a
UIView object in a UIKit app, except that it does not manage any actual views. It runs in your WatchKit extension and remotely manages the behavior associated with an interface controller in your Watch app’s storyboard file. You subclass
WKInterface and use its methods to configure the elements of your storyboard scene and to respond to interactions with those elements.
Your interface controller code runs locally on the user’s Apple Watch but is separate from the interface that it manages. When you change the value of an interface object in your code, the system forwards the needed information to your Watch app, which makes the corresponding changes onscreen.
Initializing Your Interface Controllers
When the user interacts with your app content, the system launches your extension and creates the appropriate interface controller objects automatically. Apps use different interface controllers to manage their notification and app interfaces. WatchKit uses the information in your app’s main storyboard file to determine which interface controller to load. Notification scenes are configured specially so that the system can identify them. For your app, WatchKit loads your app’s main interface controller initially, but you may change the initial interface controller at launch time.
When creating an interface controller, WatchKit instantiates the class and calls its
init() method. You can use this method to initialize variables and load data; however, don't use it to configure your user interface. The controller's user interface elements may not be properly initialized when this method runs.
Next, the system calls the
awake(with method. If WatchKit passes a valid object to the
awake(with method, use the information in that object to customize the initialization process. Also, the controller's user interface elements are guaranteed to be available at this point. This means that you can safely use this method to configure your user interface.
will method lets you know when your interface is about to become active. Use the
will method to perform any last minute tasks, such as checking for updates to your content; however, don't use it for your primary initialization.
will method may be called at times when your interface is not yet onscreen. For example, WatchKit may call the method in advance so that you have time to update your content. WatchKit calls the
did method to let you know when your interface becomes visible. Similarly, WatchKit calls the
did methods when your interface moves offscreen again.
In iOS Simulator, WatchKit calls the
did method for the current interface controller when you lock the simulator by selecting Hardware > Lock. When you subsequently unlock the simulator, WatchKit calls that interface controller’s
will method again. You can use this capability to debug your activation and deactivation code.
Displaying Your App’s Interface Controllers
Your Watch app may use one of two navigation styles for displaying content. The hierarchical navigation style lets you push and pop interface controllers similar to a navigation controller on iOS. The page-based style lets the user navigate between two or more interface controllers by swiping horizontally.
For page-based navigation, you normally specify the interface controllers for each page at design time. Once configured, you do not need to make any calls to facilitate navigation from page to page. WatchKit automatically displays the next page in the sequence when the user swipes horizontally. If you want to change the currently displayed pages, you can do so at any time by calling the
reload class method. Typically, you call that method early in your app’s launch cycle but you may call it at any time to reload your interface.
For hierarchical interfaces, you are responsible for pushing new interface controllers onscreen in response to user actions. When you want to display new content, call the
push method and specify the name of the interface controller you want to display. WatchKit handles all of the animations associated with displaying the new interface controller.
When pushing a new interface controller, it is recommended that you pass a context object to the
push method. A context object is the main way to communicate information to the new interface controller. For example, you might use this object to specify the data that you want the new interface controller to display. A context object can be an existing data object, or it can be a dictionary that you create dynamically and fill with relevant information.
When using segues to initiate hierarchical navigation between interface controllers, WatchKit calls the
context method based on whether the source of the segue was a table row or a button. Use those methods to provide the context object needed to initialize the new interface controller.
Presenting an Interface Controller Modally
Apps can present an interface controller modally to gather or display information. A modally presented interface controller animates up from the bottom of the screen and covers the current interface. Dismissing the interface reverses the animation and reveals the previously covered interface controller again. When presenting a modal interface, you can display a single interface controller (which is the most common use) or you can display multiple interface controllers in a page-based layout.
present methods to present your interface controllers modally. If the modal interface controller does not have a title, its title is set to the string
Cancel by default. You can set the value of this string in your storyboard or change it at runtime using the
set method. When the user taps the title string, WatchKit automatically dismisses the modal interface without taking any further actions.
Presenting Standard System Interfaces
The system supports several standard interfaces for gathering input or displaying specific types of information.
Alert and action sheets. Use the
presentmethod to display alerts and request user input using a standard interface.
Alert(with Title: message: preferred Style: actions:)
Text input. Use the
presentmethod to receive text input from the user. The user can use dictation or select from one of several predefined phrases.
Text Input Controller(with Suggestions: allowed Input Mode: completion:)
Video and audio playback. Use the
presentmethod to play back audio and video.
Media Player Controller(with: options: completion:)
Audio recording. Use the
presentmethod to display the standard audio recording interface.
Audio Recorder Controller(with Output URL: preset: options: completion:)
PassKit passes. Use the
presentmethod to display an interface for adding passes to the user’s Apple Watch.
Add Passes Controller(with Passes: completion:)
The standard interfaces have built-in buttons so that the user can dismiss them at any time. Many of the interfaces also have a dismiss method that you can use to close the interface programmatically. While an interface is active, your app does not have direct control over the interactions with that interface. Use actions or a completion handler to handle any tasks related to the interface itself.
Interface Builder Configuration Options
Xcode lets you configure information about your interface controller in your storyboard file. Table 1 lists the attributes you can configure in your storyboard and their meaning.
The name of the interface controller. Use this name to specify which interface controller to push or present.
The title string assigned to the interface controller. You can set this value programmatically using the
Is Initial Controller
A Boolean indicating whether the object is the app’s root interface controller. Only one interface controller at a time may have this option enabled. This option does not apply to glance or notification interface controllers.
Activity Indicator On Load
A Boolean indicating whether the interface controller’s contents should be hidden until after the
A Boolean value that turns off scrolling and allows built-in controls and containers to fill content to the screen edges, regardless of the content-safe area.
Fixed to screen edges
A Boolean value that indicates whether content should ignore the content safe area and minimum layout margins. When this option is enabled, the system turns off scrolling, and allows built-in controls and containers to fill content to the screen edges.
The background image to be displayed behind the scene’s content. The image you specify in your storyboard scrolls with your interface controller’s content.
The content mode for the background image. This mode defines how the background image scales or fills the screen and behaves in the same way as the constants for the
A Boolean value indicating whether an animated background image starts running its animation automatically after being loaded. Set this option to Yes if you want the animation to start automatically; set it to No if you prefer to start the animation programmatically.
The background color to be displayed behind the scene’s content.
The amount of space (in points) to insert between the edges of the interface controller and its content. Selecting Custom lets you specify different values for the top, bottom, left, and right edges.
Additional spacing (in points) to include between items in the interface controller.
Table 2 lists the attributes you can configure for a glance interface controller.
The name of the glance interface controller.
Display Activity Indicator When Loading
A Boolean value indicating whether the system displays a loading indicator for the glance. Glances display a snapshot of their pervious content until the
The template to use in the upper portion of the glance. Select the template that best suits the information you want to display.
The template to use in the lower portion of the glance. Select the template that best suits the information you want to display.
WKInterface when you have a storyboard scene that requires configuration at runtime or that handles user interactions. Typically, you define a custom subclass for each unique storyboard scene that your app manages. In your subclass, define outlets for any interface objects you need to configure and define action methods for responding to interactions with the elements of your storyboard scene.
Most custom interface controllers you use in your app require a custom interface controller subclass. Even glances need an interface controller to update the glance contents. The only storyboard scene that cannot use a custom interface controller is the scene associated with a static notification interface. When implementing an interface controller for your dynamic notification interface, subclass WKNotificationInterfaceController instead.
Override any methods of the class needed to configure your interface and get it ready to display. Most interface controllers override the
awake(with methods. Override any other methods that make sense based on your needs.