As a developer, the debut of the Apple Watch is an exciting event. While the technology isn’t new, it’s guesstimated the rate of user adoption will be. Demand at this scale always drives innovation, and the Watch is sure to bring about awesome new apps and experiences – some that haven’t even been dreamt up yet.

At Apteligent, we have the pleasure of working with over 30,000 app developers worldwide, across a wide range of different devices. With that breadth of information at our fingertips, we’re going to address some of the major use cases that will be solved for Watch users on launch day, how these apps are built, and what the developers are doing to ensure a success when the Watch is unleashed into the wild.

If you’ve already started building apps, great! Make sure you’re aware of these things developers need to know about the Apple Watch. And if you haven’t dipped your toes in the Apple Watch waters, check out our tutorial that walks you through every step needed to create a full app integrated with the WatchKit framework.

General Concepts on the Apple Watch

One topic we’re seeing over and over again across popular use cases is how the Apple Watch communications with the rest of the world – through GPS, web services, messaging, and the like. Since the Watch is so resource-constrained, Apple has required the presence of an iPhone in order for most 3rd-party apps to work. This is in the best interest of the consumer, and makes perfect sense when you consider issues like battery life.

This constraint means your app needs to be constructed in a way that offloads the heavy lifting onto the iPhone, and then communicates the appropriate data to the Watch for display and user interactions. The flow of data looks something like this:

Fig 1.1

Apple has provided methods to easily communicate flexible data structures between the iPhone and the Watch, making it easy for developers to implement data transfers between the devices. The communication starts with this static WKInterfaceController method in your WatchKit Extension:

+ (void) openParentApplication:(NSDictionary*)sendInfo
reply:^(NSDictionary *replyInfo, NSError *error)reply;

This will ask the app running on the iPhone to respond to its request. If the app isn’t running on the iPhone, it will be ‘woken up’ in order to respond. It’s worth noting that the app won’t necessarily be brought to the foreground if the iPhone is in use. The iPhone app responds in its AppDelegate class by implementing the following method:

- (void) application:(UIApplication *)application handleWatchKitExtensionRequest:(NSDictionary *)userInfo
reply:(void (^)(NSDictionary *))reply;

You probably noticed that NSDictionary is used in the request and callbacks. This gives you a lot of flexibility in the data sent back and forth, but it’s not quite as easy as throwing generic objects to one another. You must always make sure that data is serialized properly, otherwise the request will fail.

A full back-and-forth request from the Watch to the iPhone may look something like the following.

Your WatchKit Extension makes a request to the phone from its InterfaceController:

[WKInterfaceController openParentApplication:@{@"requestType": @"getLocation"}
reply:^(NSDictionary *replyInfo, NSError *error) {

// the request was successful
if(error == nil) {

// get the serialized location object
NSDictionary *location = replyInfo[@"currentLocation"];

// do something with the result

// the request failed
else {
[Apteligent logError:error];

And your AppDelegate on the phone responds to the request by implementing the following method:

- (void) application:(UIApplication *)application
handleWatchKitExtensionRequest:(NSDictionary *)userInfo
reply:(void (^)(NSDictionary *))reply
if([userInfo[@"requestType"] isEqualToString:@"getLocation"]) {
reply(@{@"currentLocation": @{@"latitude":@32.83, @"longitude":@-79.82}});
} else {
reply(@{@"errorCode": @"unknown request"});

These methods are the key for passing data from the iPhone to the Watch, and allow for simple, lightweight requests for the Watch to grab data from the iPhone. For the majority of use cases, think of the Watch simply as a secondary display rather than a standalone device.

Apple Watch Performance

When developers look to extend functionality, especially on a new device with a new set of APIs, issues are going to arise. We noticed this at the launch of iOS8, and it’s a consistent pattern when new features are released. Being on the look out for issues – especially on first launch – is critical to maintaining user trust and keeping people engaged as newly extended apps go into the market.

Fortunately, Apteligent provides some easy-to-use tools to help out with this.

Above, we showed how an app will communicate with the Watch’s counterpart. The majority of apps will rely on the iPhone to communicate with services, then shoot data back and forth to the Watch. This transfer is critical to your app’s functionality. If data is incorrect or the connection drops, your user will be in for a bad experience. Apteligent’s latest SDK (v.5.2.0) automatically tracks these connections for you and lets you know when (and how) your app is utilizing WatchKit.

This latest addition, along with Apteligent’s industry-leading crash reporting and performance monitoring, will help give you the insight needed to not only know if your WatchKit-enabled app is working properly, but also to debug any issues that arise after the Apple Watch goes live. And best of all, you don’t need to add a single line of extra code. The SDK automatically takes care of everything.

Use Cases for Apple Watch

Apple has already shown off some of the apps that will be available on launch day. Here are a couple of Apple Watch app monitoring use cases we’d like to point out:


With Apple’s recent push of their HealthKit tools, as well as the apps and sensors that ship with the Watch, it’s clear that the Apple Watch will have strong ties to health and fitness apps. The Nike+ fitness apps have long been in the top lifestyle apps in the App Store, and in many ways these apps are the perfect candidates for a Watch extension.

From a development perspective, the heavy lifting is still based on the iPhone – which does GPS tracking and syncs with Nike’s web services, but they use the methods and tools mentioned above to transmit relevant data to the Watch quickly and consistently in order to give their users a great experience.


Traveling can be a handful – between suitcases and companions, literally speaking. But then, your hotel reservation pops up on your Watch, and you can point your cab in the right direction without digging for your iPhone. You tap a check-in button on your Watch during the ride, and by the time you arrive at your room, it’s one more button tap and your door unlocks.

SPG (Starwood Hotels & Resorts) has built an awesome Watch extension to make all that possible. By utilizing the iPhone’s data connection and authentication system, they are able to not only communicate with their reservation systems, but also to the door lock itself. Once again, it’s a simple interface on the Watch that is driven by the iPhone and the simple communication methods in the app delegate class.

Apteligent already helps a number of these brands monitor their app performance to ensure a great user experience – particularly when the app and Watch are communicating with each other and external services.

Wrapping up

These small, functional additions to existing apps bring plenty of value to a user in Watch-form – and this first round of app-extensions are only the beginning.

As consumers adopt the Apple Watch, it will drive new ideas and innovation, just as the iPhone SDK did nearly a decade ago. We’ll almost certainly be using the Watch in ways we can’t even imagine yet in just a matter of months. Now it’s time to get out there and start developing!