Here’s a continuation of key takeaways for various watchOS 3 sessions from WWDC16. If you haven’t read part 1, check it out here.
My notes from this session:
A lot of random tidbits in this talk. All 3rd party apps are encouraged to have complications, even if there’s no data to show. With easy access to multiple watch faces, it allows the user to have a lot more complications at hand and as a quick launch into the app itself if it’s not already in the dock.
The most interesting thing to remember is that the main path to optimize is not the launch any longer, it’s the app resume. Since apps are staying around in memory longer, you should make sure that your lifecycle interface controller methods are as optimized as possible. These include methods like
willDisappear. These events are going to be seen quite often as they will be triggered as users are scrolling through their app dock.
One last thing to note is about
WKTableView. There’s a new vertical paging navigation interaction that allows users to not have to constantly move back and forth between a table view and the detail view once they tap on an element. After setting a couple of conditions and making sure you use segues in Interface Builder, users will be able to scroll up and down to get to the previous and next item in the table view. See my third note up above for a drawing of this action.
Probably my favorite watchOS 3 session at WWDC this year. This session really boiled down to one fact: Apple wants users to only have 2-second interactions with their watch. Therefore, they’ve added a number of things that will help developers get their interactions down to this short time period including gesture recognizers, access to digital crown events, the new notification framework, SceneKit & SpriteKit, and background app updates (basically everything that was covered in all watch specific sessions).
Gesture Recognizers/Digital Crown Events
You now have access to the following gesture recognizers in watchOS 3 (via Interface Builder):
- Long press
As well as rotation events for the Digital Crown:
WKCrownSequencer(number of rotations per second)
WKCrownDelegate(number of crown rotations represented by the
One of the best practices for these gestures is to attach them to groups, rather than any one specific control. This is because groups tend to be the largest interface element on the watch screen and you want to give your user plenty of room to maneuver around.
SceneKit & SpriteKit
An interesting thing that Apple is pushing is that they want all developers to adopt SceneKit and SpriteKit, not just game developers. They showed a nice example of a non-gaming use of SceneKit, mixed with elements of SpriteKit too and emphasized how adopting both of these frameworks could create a much richer experience for your users. Integration with Apple Watch seems fairly easy. All you need to do is drag a screen from Interface Builder onto one of your interface controllers or notification controllers and use SceneKit and SpriteKit APIs as normal.
There’s a new UNUserNotificationCenter which handles most of the interactions your watch app will have with the notification framework. Since this framework is supported across all of the platforms, you’ll have to handle presenting and receiving notifications by setting:
UNUserNotificationCenter.current().delegate = self
in your extension delegate. From there, there are a couple of new APIs depending on what you want to do with the notification:
//when presenting a notification with the app in the foreground func userNotificationCenter(center: UNUserNotificationCenter, willPresent: UNNotification, withCompletionHandler: (UNNotificationPresentationOptions)) //handling a foreground action that makes the app active or for background actions on notifications func userNotificationCenter(center : UNUserNotificationCenter, didReceive: UNNotificationResponse, withCompletionHandler: (UNNotificationPresentationOptions))
These notifications can be sent locally just to the watch itself, or also to both the watch and the phone. In order to prevent duplicate notifications, you can set a notification identifier and the framework will automatically take care of properly displaying the notification only once.
No more loading indicators!!! In order to achieve the 2-second interaction goal, Apple is recommending that we do away with loading indicators. Instead, they recommend giving users feedback about their interactions with the watch and then use a local notification in order to confirm that what they wanted went through. The example that they gave was for the use case where a user wanted to buy something on their watch. The user would press the buy button and then get feedback saying that their order was processing (not confirmed necessarily). In the meantime, they would then use a background
NSURLSession to actually execute the purchase and then send a local notification to the user once their order had actually gone through. Great stuff. 👏
Some fun bits in The Talk Show with Phil Schiller and Craig Federighi about watchOS 3. Turns out Apple was so paranoid about keeping the promise of having all day battery life for the Apple Watch that they super conservative with ram utilization for the first couple of versions of watchOS. Luckily they figured out that they didn’t actually need to be so conservative, which allowed them to include background updates and keeping your favorite apps in memory without any negative battery repercussions. Lots of other cool nuggets of information from this chat. Highly recommended if you want a break from technical sessions.