Last time we covered what you can do with the Apple Watch from a developers perspective in our Apple Watch series, but of course, there are limitations to what we’ll be able to do as developers too. Here, we’ll be looking at some aspects of the current Apple WatchKit API that make certain things impossible (at least with the first generation device).
Note: This post goes into a bit more technical detail
One of the major limitations of the WatchKit API, is the inability to access any of the sensor data – so we won’t be able to access the new heart rate sensor, accelerometer, or gyroscope. This could simply be because an actual device hasn’t been made yet, so the behaviour isn’t set in stone and an API hasn’t been created. Also, as there isn’t an actual device for developers to purchase, there would be absolutely no way to test if any of our sensor code actually worked.
The watch also seems to be a little light on gestures controls – there are the different kinds of taps and single finger swipes, but that’s pretty much it. There could be several reasons for this:
- A connected iPhone will actually be running all the code for the Watch, so the time lag between the two devices communicating might mean that gestures wouldn’t look like they were working to the user
- Multi-touch gestures will be hard on a small device and would definitely obscure content on the screen
- Apple have said they will be including Accessibility support in the Apple Watch. So scrolling with two fingers might already be taken here
Additionally, more recent articles discuss Apple pulling features from the Apple Watch due in part to sensors not reporting reliable information, or consuming too much valuable battery. See this article from 9to5Mac for more information.
The next major omission from the WatchKit API is the lack of being able to access feedback mechanisms, like the exciting Taptic Engine, or to customise “taps” for different events. Again, this could be because the device doesn’t physically exist yet.
Also, there is oddly no method to connect with either the microphone or speaker on the Apple Watch, which would mean notifications and Siri would be virtually unusable for developers. Apple have also published a few contradictory articles on their developer forums, stating that there is no speaker on the watch. Personally, I’m almost certain there will be a speaker on the Watch, I just don’t think developers will have access to it yet.
The Apple Watch has a kind of symbiotic relationship with an iPhone, and won’t operate any apps at all if it loses connection with that phone. This is down to the fact that the processor inside the watch isn’t great (which helps the device conserve battery life), so the iPhone will be doing a lot of the grunt work of running the Apple Watch apps.
This means, if your iPhone runs out battery, or disconnects, you will be greatly limited to what you can do. On the bright side, Apple have guaranteed that the “watch” functionality of the device will remain operational, and any alarms configured will definitely go off. This is also true if the battery on the watch goes below a certain level, it’ll automatically shut down any apps so that it can be an operational watch for as long as possible.
It is likely that these forgotten features might be included in future updates, especially the sensor and feedback items. However, who really knows what Apple might add! Most developers on the Internet currently seem really happy with the amount of access to the WatchKit API’s so hopefully it’ll only get better with time.
In our next blog, Calvium’s Creative Director, Jo Reid, is going to talk through how we as a company are hoping to use the Apple Watch and introduce our own Apple Watch that we have been developing.