Hello, my name is Roy and I work in LINE iOS development. With the recent release of Apple Watch, I would like to introduce the features of Apple Watch, and how it was like developing LINE for Apple Watch.
Introducing Apple Watch
Apple Watch was first unveiled on September 9th, 2014 as “one more thing” following the iPhone 6, iPhone 6 Plus, and Apple Pay. It will be available in three different versions named Watch, Watch Sport, and Watch Edition with a choice between a 38mm or 42mm watch face. Apple Watch will be able to track the user’s movements, as well as receive notifications from an iPhone. An SDK was also released so that third parties could develop for Apple Watch as well. Apple Watch comes equipped with a display that supports Force Touch, and a Digital Crown that is used to zoom the display in or out. The side button below the Digital Crown launches Friends, giving you access to all of your contacts. On the bottom is the sensor, capable of detecting the heart rate of the user. Inside Apple Watch is the built-in speaker and Taptic Engine, which will alert users with sound or haptic feedback whenever they receive a notification.
Developing for Apple Watch
In order to develop for Apple Watch, your iOS app will need a WatchKit extension. While it was possible to have several extensions for a single iOS app, you are able to add only one WatchKit extension. Adding a WatchKit extension enables three functions: the WatchKit App, Glances, and custom notifications.
WatchKit app: The iOS app equivalent on Apple Watch. Apps can have various page layouts, multiple screens, and receive user input.
Glances: The widget equivalent on Apple Watch. Glances can be seen by swiping up from the bottom of the Apple Watch display. Apps that have been favorited by the user will appear here. For example, a glance of the calendar would show your schedule, and a glance of the weather app would show you the current weather situation.
Custom notifications: By default, all iOS notifications will show up on Apple Watch as well. You can change the look of how these notifications will actually appear, similar to how you would change the design of your WatchKit app. It is also possible to display related pictures.
Apps on Apple Watch can display images or text similar to how iOS apps work. Buttons, switches, and table views are available, but there is no screen rotation, or more advanced functions like video/music playback.
Apple Watch does not actually run any code on the device itself. Instead, the iPhone does. Apple Watch is only capable of displaying the the results of the code being run on the iPhone, and it only stores image resources and storyboards needed for the display. In other words, third party apps simply stop functioning if Apple Watch is separated from the iPhone that it is paired with. For example, if connection between Apple Watch and the paired iPhone is lost, the WatchKit app will stay stuck on a command without proceeding to the next step. Apple Watch merely acts as a screen that displays data sent from the paired iPhone.
In order to share data with an iOS app, the WatchKit app can use database, user configuration data or files. Alternatively, the WatchKit app can dynamically run the iOS app to send and receive data when needed. Queries can be sent to the iOS app through the openParentApplication function, and responses can be relayed back to the WatchKit app. While this function is convenient, it is slow to use because of the time it takes to communicate with the iOS app. Even a few seconds could be critical to user experience, since users would need to lift their arms up to look at the Watch display. That is why it is best to avoid using this function. However, if there is a feature that cannot be easily implemented by only using the WatchKit app, or if the schedule does not allow more time for development, it may be used sparingly.
Things that can and cannot be done on Apple Watch
- Third party apps cannot directly control hardware. Access to the Digital Crown (other than the default functions accessible when adding a table view), heart rate sensor, and GPS is restricted. However, built-in Apple Watch apps are able to access the hardware.
- Apple Watch can convert speech to text, but it can cannot record and save audio.
- Views cannot be stacked on top of each other.
- The way gestures are recognized cannot be changed.
- Force Touch can only be used to bring up a menu.
- Notifications only show up on Apple Watch if the display on the paired iPhone is off.
- By default, all notifications will show up on Apple Watch. You cannot choose specific notifications to appear on the screen.
Developing LINE for Apple Watch
LINE on Apple Watch uses two features: custom notifications and the WatchKit app.
Whenever the user receives a text, photo, or sticker they will receive a notification on their Apple Watch. In the case of the LINE iOS app, notifications will only let users know what they received through text such as “sticker” or “photo,” unable to see the actual contents until the app is open. On Apple Watch, all those notifications are directly displayed on-screen. Any other messages will be displayed in the form of text messages. The text had to limited to three lines since it would get cut off if it was too long.
For loading Stickers or photos by only using information from the payload, we used the aforementioned openParentApplication function. We were well aware that this method would be slower, but this way we could get it done fast and come up with a solution later. It was so slow in fact, that Apple requested that we change it before Apple Watch launches.
The reply button
We tried to include a reply button on the bottom of the message notification, but it was not as simple as it first seemed. In order to add a button to the notification meant that we had to branch the notification so that it can display buttons. This would require the notification payload being modified. We needed assistance from server-side, and then we had to deploy it on the actual server. There was another problem even on the server-side; the reply button would also show up on the iPhone notification as well. This was to accommodate for situations where an iPhone could be physically far away from an Apple Watch. Working on the WatchKit app more or less affected the iPhone LINE app in this way, so we had to get confirmation from the planning team. The confirmation process was a burden, and it could also potentially cause other issues as well. Ultimately, we had to exclude the reply button feature from the 1.0 version. The design team and planning team, even the people at Apple had asked us why we decided to do so. We answered their questions by telling them we would implement it in version 1.1.
The notifications system was one of the most difficult parts during development. Simply because there was no way to test them on an actual device. With the simulator, we were only able to test notifications under the scenario that they were already open on the device. Without access to the home screen or other apps, we were unable to test scenarios where a user might receive a notification while using another app, or receiving a notification while checking a notification, or closing the notification. As a result, we were unable to undergo any actual testing until we had the actual device.
Here are a few screenshots from the WatchKit app. LINE on Apple Watch lets users read unread messages and reply to them. The first screen will display a list of chat rooms with unread messages. Once the user taps on a chat room, they can read all the unread messages and reply to them by pressing the reply button. The user may reply with Stickers or Sticons, but even Sticons will still be sent in Sticker size. Once the user leaves the chat room, the room will be marked as read and removed from the list.
Loading the chat room list (refreshing the database)
There was an issue that prevented displaying chat rooms with new messages when the app was opened right after a notification was received. This was due to the iOS app not refreshing the database in time. Now when the user launches the Apple Watch LINE app they will see a loading screen while the iOS app refreshes the database. The loading screen was made to closely resemble the default Apple Watch screen so that users would not notice any huge differences. Although we knew that it would be slower, we used the openParentApplication function to refresh the chat room list. This was because we wanted to refresh the database even when LINE was open on the iPhone, and because it already took us long enough to implement this feature just for Apple Watch. The delay felt negligible once we added in the loading screen.
Scheduling issues during chat room implementation
The chat room did not present us with any serious issues, but implementing the chat room itself took a considerable length of time. Since it was arguably the most important part of the app, there were some design issues here and there, but thankfully there was no need for any research for new technology. The most noticeable difference with the iOS app is that the WatchKit app will not display profile pics, timestamps, and speech balloon tails for messages that were received in under a minute. This was a design choice to display as much information as we could on the small display. While it was aesthetically good, the minor bugs it caused took us a while to fix.
Delays in loading Stickers/Sticker lists
There was an issues with the speed in which Stickers and Sticons were being sent. Displaying a large number of Sticker and Sticon images simultaneously brought the speed down significantly. We were able to solve the speed issue by using the below function that is also recommended in Apple documentation.
This function had a huge advantage over the previous function:
[WKInterfaceImage setImage:[UIImage imageNamed:]]. The function I was using would send an image to the iPhone and then send it back to Apple Watch, while using
[WKInterfaceImage setImageNamed:] would load images stored on Apple Watch instantly. The new function offered a significant boost in image loading speed.
Lack of performance test tools
There were no available tools to test performance on Apple Watch. As of now, the only way to measure performance is to see how long a certain feature takes to run ourselves. We also could not perform any memory checks, although we were able to check if the classes we created were deallocated properly. The table view in particular, was unlike on iOS where cell could be re-used. We had to check if cell memory was deallocated properly. Other than that, we ran the app to see if there are any crashes.
The most important thing to know about Apple Watch was the specifications needed for development. We did not have any access to a test device, nor did the device have any prior versions that we could work with. There were limits to what we could learn no matter how thoroughly we read the documentation on Apple Watch development. Any further questions we had, we perused the forums to find the answers we needed.
As it was the first SDK to be released, there were many limitations to what we could do. It was unfortunate that third party apps were restricted from accessing many of the things Apple Watch had to offer. Third party apps are unable to access all the new fancy hardware in Apple Watch, or the UI effects that are apparently used in the built-in apps. At times it was confusing, because it was difficult to tell if it was my lack of research that was stopping me from using those features. Hopefully, the SDK might just be updated incrementally, and the next version is not long away.
Developing for iOS is always a convenient experience due to the detailed documentation available. Apple Watch development was also relatively painless due to my prior experience of developing a widget for iOS devices. Although without any tools to test performance or memory limitations, I cannot say for sure how the app will perform once it is actually distributed. With the Worldwide Developers Conference (WWDC) right around the corner, I sincerely hope development for Apple Watch is more improved down the line.