At the time of this writing (pre-WWDC 2015), there are a number of limitations on what Apple Watch code can do. The primary limitation is that watch apps cannot exist by themselves. It is necessary for the watch app to be a part of a corresponding phone app. Apple has said they will not accept watch apps where the phone app does not do anything itself. Also, watch-only apps (such as watch faces) are not allowed for this same reason—although it’s rumored that this may change after WWDC 2015.
Another Apple Watch limitation is that Core Graphics animations are not supported, but animated GIFs are. Complex layouts (such as overlapping elements) are not allowed. However, elements can be positioned as if they overlap—provided only one element is visible at a time. Using actions such as taps and timers, the visibility of these “overlapping” elements can be changed. This can be implemented to provide a more dynamic interface. Another major limitation (also whispered to change after WWDC 2015) is that watch apps cannot access any of the hardware on the watch including the motion sensor and heart sensor.
Most watch app processing (controller logic) is done on the phone instead of the watch, and some delays are inherent in the Bluetooth communication that transpires between the watch and the phone as the view (on the watch) talks back to the controller (on the phone). This view/controller split is not obvious in the code, but the watch/phone split is obvious in the code, as the watch cannot access anything from the phone, even though the controller logic is running on the phone side—except via a specific watch-to-phone request.
One notable feature is the watch app’s ability to explicitly call the phone app with a dictionary and obtain a dictionary response. This functionality allows the developer to then set up a number of client-server style requests, where the watch is the client, and the phone is the server. For example, the watch can request information from—or record information to—the phone. The phone (which has storage and may have Internet connectivity) can then fulfill the request and provide data in response to the watch. This can drive the phone app’s UI to provide near-real-time synchronization of the watch app display, as well as the phone app display.
Custom notifications (both local notifications and push notifications) are supported on the watch. These custom notifications can have a somewhat customized layout as well as having the ability to define a set of custom actions. After performing one of these actions, the watch app is started. Apple mentions not to use notifications as a way to just launch the watch app from the phone app. Apple maintains that the notifications should provide useful information.
One developer test limitation relates to custom watch notifications (for local notifications). Since watch notifications are only displayed if the phone is asleep, there is no direct way to test custom watch notifications. Because of this, XCode does provide a mechanism to test push notifications in the simulator (using a JSON file), but there is no similar mechanism to test local notifications. Still, one can certainly test local notifications with the physical device.
