7 Things Apple Watch Can’t Do

Now that Apple has released the highly anticipated Apple Watch, many companies are itching to get their products on the device. The Apple Watch is certainly a fantastic opportunity to provide value to your customers, but this initial release comes with serious limitations that you should consider when you plan to bring your apps to your users’ wrists.

1. Your app won’t work without a paired iPhone

The watch itself does hardly any processing. Instead, developers create so-called “WatchKit Extensions” that execute on the paired iPhone and push data to the watch for display. The watch contains only view code.

2. You can’t write custom programmed views

iOS has sophisticated drawing and animating APIs, but on the watch developers are stuck with a handful of primitive UI elements. If you want to provide a custom look and feel, your only choice is to display a static image. Rudimentary animations can be achieved by displaying a sequence of images—like an animated GIF. Be warned: you aren’t going to achieve a great frame rate; creating dynamic images on the iPhone and pushing them to the watch isn’t very performant, either.

3. No access to sensor data

You might be thinking that the watch could be a great new data source, as it comes with a gyroscope, accelerometer, and heart-rate monitor. However, so far, Apple has not provided any API to access sensor data directly. Instead, programmers can access only the data Apple has provided in the HealthKit API, and it is unclear how portable that information will be.

4. You can’t subclass built-in view classes

While it’s possible to define a subclass, programmers can’t change the class type from the watch app’s storyboard, making it impossible to actually use the custom view. This, combined with the inability to use custom object constructor methods removes two common ways of organizing and sharing code in an app. Apple’s Mac and iOS APIs are popular for their developer ergonomics. When programming for the watch, you’ll really feel the limitations in what Apple has provided.

5. The watch can’t request user permission

Some APIs require your users to grant permission, like the CoreLocation API that lets developers create user-relevant maps and directions. If your users have not already permitted the app to access this data, they must go to their phones and do so. That means your users need to pull their phones from their purses or pockets before they can use your watch app.

6. Extension code can’t link to UIKit

This makes sense, but can cause problems if you want to reuse code between your iOS app and WatchKit extension. For example, if you want to share your API client code, data models, or business logic, you need to ensure that code is in a separate target that does not depend on UIKit. This is good design, but remember that your library code has to follow the same rules. Popular libraries like AFNetworking, for example, provide utilities for both low-level code and UIKit-based code. Thankfully, AFNetworking provides preprocessor directives to allow conditionally building without UIKit, but you might not be as lucky.

7. XCode crashes a few times per day

Anyone who has used XCode knows that crashes are a way of life, but programming for the watch clearly needs some kinks ironed out. Tip: be careful how you end sessions with the watch simulator. We found it’s best to stop the running app from the ■ button in XCode instead of quitting the simulator directly.

The good news for app development companies is that most of these shortcomings should be temporary. The watch is still new, and we can expect that Apple will roll out more APIs in time. Until then, I still think the watch provides interesting opportunities.

Want to learn more about software development, follow SmartLogic on Twitter.

Image Source: apple.com