Article

Keeping Your watchOS Content Up to Date

Ensure that your watchOS content is relevant and up to date.

Overview

A watchOS app rarely runs in isolation; it needs data from the outside world. You can access data directly from a web service, CloudKit, or other online resources. You can also share data from a paired iPhone, although this can’t be your app’s primary way of accessing data.

Because Apple Watch has several different ways to connect to the internet, it’s important to test all of your apps networking code over all possible routes.

Access Data Directly

Your watchOS app can connect directly to web services and other online sources. When making these requests, the system can send data through a paired iPhone as a proxy, over a known WiFi network, or over the watch’s own cellular connection (see Test Your Update Code with Different Configurations).

Always use a NSURLSession object to make network requests; however, the type of session varies depending on your app’s needs:

  • If your app is running in the foreground, use a default or ephemeral session to avoid any delays to your request.

  • If your app is running in the background (or about to become inactive), use a background session to ensure the request completes.

Default and ephemeral sessions minimize any possible delays between making the request and receiving the response. These sessions are ideal for small exchanges of data when the user actively interacts with the app. You can also use them to update your app’s content whenever the app becomes active. For more information, see Making Default and Ephemeral Requests.

Background sessions, on the other hand, guarantee that your app eventually receives a response, even if your app becomes inactive or terminates. However, the system may delay or defer background sessions based on available resources. For more information, see Making Background Requests.

To learn more about using URL sessions, see URL Loading System.

Use CloudKit to Store Data in the Cloud

CloudKit lets you save data in an iCloud container, sharing that data across all the user’s iCloud-connected devices. For example, you could use CloudKit to share your app’s settings or sync the user’s current location in a long-form audio file. CloudKit also lets you create cloud-based apps without having to set up and manage your own servers.

CloudKit offers the following advantages:

  • Users can access CloudKit data based on their Apple ID without requiring in-app sign in.

  • CloudKit is ubiquitous; it is available as a native framework on all of Apple’s platforms. Additionally, the web frameworks give users access to CloudKit on the web or on platforms that don’t have a native framework.

  • CloudKit requests use NSURLSession. This means watchOS automatically selects the best route when making the request (proxied through a paired iPhone, over WiFi, or over a cellular connection).

CloudKit includes support for CKSubscription and notifications in watchOS 6 and later, letting your watchOS app respond to changes from other devices. This makes CloudKit a potential replacement for Watch Connectivity for independent apps. For more information, see CloudKit.

Share Data with the Paired iPhone

While your watchOS app can schedule periodic background tasks to update its information, these tasks are strictly limited—both in the number of times your app can wake per day, and in the amount of time it can run when it wakes. Additionally, your app is not guaranteed to receive background execution time. The system gives apps with a complication in the active watch face, and apps in the dock (as shown in Figure 1 and Figure 2) priority over other apps.

Figure 1

Apps with active complications

A figure showing a watch face with several active complications.
Figure 2

Apps in the dock

A figure showing apps in the dock.

If your watchOS app has a companion iOS app installed, you can take advantage of it to update your watchOS app from its companion. For example, if the user’s iPhone and Apple Watch can communicate with each other, use the WatchConnectivity framework to opportunistically send updates from iOS to watchOS.

However, WatchConnectivity is not always available. In watchOS 6 and later, users may not install the iOS companion for their independent watchOS apps. Also, with the release of the Watch Series 3 (GPS + Cellular), even dependent apps are likely to be away from the paired iPhone for extended periods. It’s vital that your app continue to provide useful information even when it can’t connect with its companion, so you can’t rely on WatchConnectivity as your only means of updating the watchOS app. Instead, use the WatchConnectivity framework as an opportunistic optimization, rather than the primary means of supplying fresh data.

For more information on using background refresh tasks, see WKApplicationRefreshBackgroundTask. For more on the WatchConnectivity framework, see Communicating with the Counterpart App.

Test Your Update Code with Different Configurations

When your watchOS app connects to CloudKit or interacts with online resources using a URL session request, the system can route the request in one of three ways. While developing your app, make sure to test your network requests over all three routes. The system can route the request by:

  • Proxy through iPhone

  • Connecting to a known network

  • Connecting using cellular data

First, the watch attempts to proxy the request through a paired iPhone. The watch communicates with the phone over Bluetooth, sharing the phone’s connection to the internet. When connected to a paired iPhone, the control center shows a green iPhone icon in the upper-left corner.

Screenshot showing the Apple Watch control center when the watch is connected to a paired iPhone.

If the watch cannot connect to a paired iPhone but can connect to a known WiFi network (a network that the user has previously logged into with their phone), then it sends the request using the WiFi network. When connected to a known network, the control center shows the WiFi network in the upper-left corner.

Screenshot showing the Apple Watch control center when the watch is connected to a known WiFi network.

Finally, if the watch cannot connect to either a paired iPhone or a known WiFi network, it sends the request using its cellular connection. This route is only available on Apple Watch Series 3 (GPS + Cellular). When using a cellular connection, the control center shows the cell connection’s signal strength as green dots in the upper-left corner.

Screenshot showing the Apple Watch control center when the watch is using a cellular connection.

Topics

Making Network Requests

Making Default and Ephemeral Requests

Send requests from your app when it is running in the foreground.

Making Background Requests

Send requests from your app when it is running in the background.

See Also

App Infrastructure

Working with the watchOS App Life Cycle

Learn how the watchOS app life cycle operates and respond to life cycle notification methods.

Authenticating Users on Apple Watch

Create an account sign-up and sign-in strategy for Apple Watch.

WKExtension

An object that manages behaviors shared by an app’s interface controllers.

WKExtensionDelegate

A collection of methods that manage the app-level behavior of a WatchKit extension.

WKInterfaceDevice

An object that provides information about the user’s Apple Watch.