Developing our Apple Watch app
Before developing our Apple Watch app, we had to figure out its purpose. Are we developing it just because it is this “new thing” or can we really provide our users an experience we cannot provide elsewhere. When we put ourselves in our writer’s shoes, we saw this obsessive need to check how our own stories are doing. How many people read it? How many people voted for it? We can obviously use our phones to check those numbers but the watch just gave us a way to make that tedious task more pleasant and helpful. Every time the user checks the statistics for one of their stories, we show them the delta in the numbers from the last time they checked it. This idea also applied to the number of followers of the writer. Our designers came up with a beautiful animation to complement this as well.
When we started developing, we didn’t have an Apple Watch so we had to rely on the simulator to develop the app. That was a challenge by itself as we did not know how our app would perform on an actual device. Nevertheless we charged on. After reading documentations and going through some sample code we had a basic app ready which communicated with the phone. However, we quickly started noticing communication issues between the two. The dreaded spinner would spin on forever. Turns out, we were not that good at reading method documentation. The description of handleWatchKitExtensionRequest: states that you should start a background task to handle the request to prevent the app from being suspended. Otherwise, the watch will never get a response from the phone because the app is suspended. Apart from this we also discovered that one of our methods would never call the completion block. It would check for a condition early in the method and would just return without calling the completion block if the condition failed. This was one of the reasons why we were seeing the dreaded spinner for most of the times while developing the app
Another challenge was bringing our designers’ animations to life. One of the main components was an animation sequence which consisted of lots of bubbles animating into the screen continuously and then fading away. The number of bubbles depended on the number of new reads or votes the story got. Our ambitious designers gave us a sequence of images to use for the animation. We copied them to the phone and ran the app. The app slowed to a crawl. On investigating we determined that both the size and number of images in the animation sequence were too high, so we decided to compress the images using pngcrush and voila! The size was cut in half. But it was not enough. We also had to move the images to the watch itself as Apple recommends and drop some frames from the animation. After taking the above steps, the app started behaving like we wanted it to.
One of our main goals, which is also what is expected of Apple Watch apps, is that the user shouldn’t have to wait too long before they see anything meaningful when they raise their wrist. In order to achieve that we had to do a few things. First, minimize the amount of data transferred between the phone and the watch. We only sent the data that was required by the watch to display. And we sent them in batches. Also, we ensured that the user’s profile image, story covers and any other assets are all sized for the watch before sending them to it. Second, we had to compromise a bit on the animation sequence images as discussed above. We had to compress the images and also reduce the number of frames so that the user is not waiting for an animation. And third, we had to prioritize content loading. The focus of the app is to show the statistics of a user’s stories, so we ensured that we first fetch the latest data for the stories first, and then load the profile images and avatars.
In the end, we developed a beautiful app which actually serves a need for our users. We hope that this app encourages writers to write even more engaging stories on Wattpad so that they can watch their rise to fame, on their watch.
