Developer Perspective: the LTE Apple Watch
When Apple announced the new LTE-enabled Apple Watch, it seemed like a huge step forward. Apple Watch was already great, but when you didn’t happen to have your phone or Wi-Fi nearby, it lost much of its functionality. With built-in cellular-connectivity, many LTE Apple Watch development problems have been fixed. Kinda.
To really understand the value LTE brings to Apple Watch, we first need to look at the evolution of Apple Watch hardware and software. When Apple Watch first came out, it was very dependent on a paired iPhone, meaning the Apple Watch app couldn’t even run without the phone. As Apple released new versions of watchOS along with updated hardware, Apple Watch gained more standalone functionality, such as:
- Apps can run on Apple Watch without being paired to iPhone
- On-Device GPS—no longer reliant on an iPhone for geo functionality
- Connect to Wi-Fi directly from Apple Watch
- Network HTTP calls via NSURLSession
All these advances allowed Apple Watch developers to update (or create) their Apple Watch apps to be more robust and provide stand-alone functionality. But we still couldn’t leave home without our iPhones, since key features were not possible without connected a phone or Wi-Fi. This includes making or receiving phone calls, texts, etc.
Apple Watch Apps reaching out
Adding on-device LTE helps solve this problem, but is not an instant fix. Even on an LTE-enabled Apple Watch, not everything “just works.” Depending on how the app developer handles data access and communication with the paired iPhone, LTE might work great, or not at all.
The only way for an Apple Watch app to communicate directly with its paired iPhone is through Watch Connectivity. This is a robust API which allows bi-directional communication between the watch and phone via Bluetooth. An older way for a watch app to get outside data would be to use Watch Connectivity to send the iPhone a message, and have the phone retrieve the data. The phone could then, in turn, send that data to the watch via another message, or a reply to the original message from the watch.
Another, more modern, way for the watch to retrieve data would be to use the NSURLSession class (and related classes), available since watchOS 2. Even before LTE was introduced, Apple Watch apps could make HTTP calls directly using NSURLSession, but it would still be routed through the iPhone via Bluetooth (if nearby and enabled). If the phone was turned off and Wi-Fi was available, then Wi-Fi would be used. And now LTE will be used, if available.
These were Apple’s first steps in making Watch apps more independent, steps that gave developers a chance to start making direct HTTP requests from the watch itself. If developers, had been more forward thinking, we would have jumped on the NSURLSession bandwagon right after it was released. Had we done so, very little (if anything) would need to be done to use LTE now.
The good news is the code to implement NSURLSession in watchOS is the same as in iOS. This makes for a relatively painless developer experience (if an app needs to be updated to use it), since they will already be familiar with the code needed to implement NSURLSession, and won’t need to re-invent the HTTP wheel.
The need for speed!
It’s worth noting that functionality implemented via NSURLSession isn’t necessarily executed the same way in all situations. Apple Watch is a tiny device with tiny resources, including a tiny battery. To preserve battery life, Apple Watch executes NSURLSession requests using the most energy-efficient method available. Those request methods are as follows (from most energy efficient to least):
- nearby, connected iPhone
- Wi-Fi (if configured)
- LTE (if enabled)
There’s also a speed factor involved. Turns out, the most energy-efficient way may also be the slowest, especially if the watch detects an iPhone that’s not so close. The watch will still use the connection to save energy, but the response time will be very slow due to the weak signal.
When I first conducted some Wi-Fi and LTE tests with no iPhone, I was pleasantly surprised to see the increase in speeds. During development, an Apple Watch app should be tested under multiple network scenarios to see how it performs under different connection types and speeds. This will help validate how the app will run and could even help debug issues. Switching to Wi-Fi or LTE could help determine if a slow screen is an app issue, for instance, or simply caused by a slow connection.
Goodbye Watch Connectivity?
Just because Apple Watch can be more independent, this doesn’t mean existing API’s no longer serve a purpose, especially Watch Connectivity. For example, some iPhone app configuration might include sending the config file to the Watch once, via Watch Connectivity. After which, the Watch App could run on its own without the phone until that configuration needed to change, which may be days (or weeks) later.
As with any mobile development tool or API selection, you have to pick the right one for the job. LTE and Watch Connectivity both play key parts in an Apple Watch App, along with other watchOS features. Making a great Apple Watch app is a matter of having the experience and expertise to properly implement the right feature to solve the problem at hand.
“Watch out” for great apps!
Apple Watch with LTE is a great advance in hardware and makes a great platform even better. The difference between a good watch app and a great one, however, is the team of developers with the experience and know-how to use the features of Apple Watch properly. When your organization is ready to extend its mobile portfolio through wearables and wants to enhance an enterprise mobile app with a great companion Apple Watch app, give us a call. We’d love to get you started.