Fortunately, a month later, the awesome DCRainmaker got hold of an Apple Watch and did some very extensive waterproof testing. His tests gave us the hope that the watch would be waterproof enough for us to develop our algorithm on the watch when the native apps SDK became available.

WWDC 2015 & WatchOS 2 Beta 1

At WWDC this year the wait for us was over with the announcement of watchOS 2. With the addition of native apps, as well as the APIs needed for our swimming algorithm, we began a skunk works project on our app that Friday — before the conference had even finished.

Two of us had been using the Apple Watch for a few weeks at that point and had grown rather attached to them. The idea of giving up one of them to install the beta and the prospect that it might get destroyed by swimming was pretty difficult. After talk of tossing coins, Dan nobly volunteered to sacrifice his Apple Watch to the cause.

How difficult was it?

Once we had ourselves setup to develop on beta 1, things went surprisingly smoothly. Our algorithm is developed in pure ANSI C which meant that it compiled first time on the Apple Watch with no code changes at all. It also uses fixed math to ensure known mathematical precision.

We’re also used to developing on the Pebble. The Pebble has an incredible battery life of about seven days, but this is partly achieved by having very limited, almost monastic, resources available to apps. The resources available on the Apple Watch, in comparison, are quite amazing.

We were also helped greatly by the similarities in data coming from the accelerometer (the sensor which measures movement) on both the Pebble and Apple Watch. They both give 25 samples per second, are measured in gravities (Gs) and are relative to the same orientation.

Architectural challenges

There are of course some quirks to developing this on the Apple Watch.

On the Pebble, once your app is running it stays active until the user quits. That means you have a continuous stream of data which you can interpret in realtime and alert the swimmer.

With the Apple Watch it constantly switches off the screen to save battery. Not only that, but when the screen is off, your app is suspended — no realtime processing of data.

Fortunately Apple have provided APIs which get around this in an interesting way. The various sensors allow you to say in advance which data is needed and will then buffer this up for you whilst your app is suspended. As soon as the screen turns on again, your app wakes up and can then request all the data which was produced whilst it was sleeping.

You can see this happening in our video above — after the four laps, Dan looks at his watch which initially displays 0 laps and then after a short delay it receives and processes the accelerometer data and updates the display.

It’s a clever solution to the problem of battery life vs. data, and we’re confident with some creative UX solutions we can counteract this slight delay and ensure a graceful experience for the swimmer.

On a similar theme, the water has some positive and also problematic interactions with the screen. The screen is incredibly bright and clear — possibly the best we’ve ever used whilst swimming. On the downside we initially had some buttons on the in-swim screen and found that the water was activating them. Our solution there was to hide all functions behind a force touch menu.