Viewing entries tagged
apple

Comment

SwimIO Featured in App Store 'triathlon goals' story

A big thank you to Apple who showed our SwimIO app some love in early Feb ‘19 with a feature in their ‘stories’ section entitled ‘triathlon goals’. Apple stated,

“Why master one sport when you can combine three together to create a new one entirely? If you’re a triathlete in training, working out how to split your time between swim, cycle and run sessions can be tricky. Fortunately these apps have you covered on all fronts.”

SwimIO_Feb19_AppStoreFeature.png

SwimIO is featured alongside fellow swim coaching app ‘MySwimPro’ and the likes of Strava, Zombies Run and Nike Run Club to make sure budding triathletes have all bases covered.

SwimIO for iOS is the leading global swim app with 400k registered users and is available in 154 app store territories. Our swim community has logged swims which would circumnavigate the globe over 130 times with 3 million swims recorded and 5 billion metres swam. Our ever growing global swimming pool database is a unique resource to find pools wherever in the world you want to dip your toe in the water.

Apple unveiled the ‘stories’ feature as part of an all new app store rebrand with iOS 11 in September 2017 designed to improve app discovery.

Preview the ‘triathlon goals’ App Store Story here - https://itunes.apple.com/gb/story/id1447218202




Comment

SwimIO Integrates with Apple Watch 2!

Comment

SwimIO Integrates with Apple Watch 2!

SwimIO is the first global swimming app! It’s live in 155 countries and has recorded over 3m swims covering 4 billion meters…that’s around the world 100 times!

“Technology and water have previously caused a few issues for innovators but finally new ideas and products to encourage swimming participation are emerging…for instance when the most successful company in history, Apple, promote swimming as an activity on the series 2 Watch, you know innovation has arrived” (David Minton, 2017 State of the UK Swimming Industry Report).

SwimIO took the opportunity of taking Apple’s technology one step further by integrating the swim algorithm from the Apple Watch Series 2 meaning swimming workouts can be recorded via Apple Health.

After a couple of months of hard work, and testing the integration with Apple, the app update has finally been released and we couldn’t be more thrilled! Our developers spent hours coding the improvements and we had our team swimming virtual lengths in the office recording swims to work out the bugs. Before releasing the app to the public, we had 10 keen beta testers around the world volunteer to try it out and feedback any problems. The overall response we’ve had for this new software has been incredible so a big thank you goes out to our development team and beta testers!

This juicy, new update includes the Phase 1 release of our integration with Apple Watch (Series 2 only) & allows swims recorded within the Apple Watch Workout feature to be automatically imported into SwimIO - so no need to manually record swims anymore, you lucky people! There isn’t an app for the Apple Watch itself in our Phase 1 release, so just record your swim normally through the watch. Also, please note that we only cover indoor pool swims currently not outdoor swims.

You can supplement the Apple Watch swim data with your sets, notes and make edits to swim data on import into SwimIO if needed as well as connecting it to your favourite pool. We love swimming with the Apple watch and want to give your swims a dedicated place to shine. The new update is simple as 1-2-3 to record swims. Once you’ve enabled the integration in the app, look out for the push notification after you’ve swum and let SwimIO turn your hard-earned exercise into glorious stats and motivation.

Along with these improvements we’ve also squashed a bug which was trapping you on our swim logging screen if you selected ‘Custom Distance’ or ‘Custom Length’. Not anymore you don’t! Loads of new virtual swim map goals have been added to keep you motivated. Try and get from Cuba to Florida and if you do we’ll join you on Miami beach for a Bloody Mary in the morning. SwimIO swimmers combined circumnavigate the globe every 8 days, let’s see if we can make it around the world in a week!

Come and say hi on twitter @HelloSwimIO

Comment

77 Comments

The World’s First Swim App On The Apple Watch

It’s June 25th 2015, Dan’s in his Speedos, and we’re about to try out what is probably the world’s first swimming app on an Apple Watch. We’re at the London Aquatics Centre, host of the 2012 Olympics. It’s the first time we’ve tried it in a 50m pool and we’d be lying if we said we weren’t a little nervous.

What is this spaceship?

What is this spaceship?

In this article we’re going to show you a video of what happened next, talk a little bit about the timeline of how we got to this point and then our experiences developing a swimming app on the Apple Watch. We’ll also give a bit of background on how we created our swimming algorithm and finish with our hopes for the next Apple Watch hardware and the Apple ecosystem.

What’s so special about the potential of the Apple Watch for swimming?

At the time of writing there are no available consumer level swim tracking devices which are also capable of monitoring heart rate in the swimming pool. Heart rate is an incredibly useful metric for calorie burn estimation, tracking fitness improvements and pacing during workouts.

edit: thanks to people commenting re: the Suunto Ambit3 which can also capture heart rate data in the pool. It uses a chest strap which buffers up data whilst swimming. When out of the water (for example resting at the side), the strap is able to burst transmit the stored data to the watch. Unfortunately most men don't get on well with chest straps as they tend to slip down during tumble turns - women fare a bit better due to swimming costumes holding it up. A wrist based sensor would still be a superior solution for this reason.

Swimming workout technology at it's best!

Swimming workout technology at it's best!

Beyond that, the Apple Watch has the storage and capabilities to guide you through a workout in the pool, whilst showing instructional videos explaining specific drills and terms. Haptic feedback has the potential to subtly communicate things to you during your swim — when to speed up or slow down if aiming for a specific heart rate for instance.

Meanwhile with its standalone wifi connectivity it could download training plans whilst resting at the edge of the pool or even communicate with friends or a coach. Maybe you could even be taking turns playing a swimming game with someone whilst in different pools.

Smart phones rocket fuelled the popularity of running & cycling apps, will the smart watch do the same for swimming?

The Apple Watch screen is fantastically visible underwater.... even with fogged up goggles.

The Apple Watch screen is fantastically visible underwater.... even with fogged up goggles.

The Apple Watch announcement

On the 9th September 2014 we were anxiously watching the live Apple event having heard the rumours that the Apple Watch was being announced. Perhaps a little differently from most people, there were two headline features we were looking for:

  1. Waterproof (enough for surface swimming at least)
  2. Standalone (native) apps on the device

We came away with a promise of native apps sometime in 2015 and no definitive answers about waterproofing. So why was this important to us?

A bit of our History

We’ve been working on swimming technology for the past six years with our very first app called ‘Splashpath’ (now in partnership with Speedo and branded as Speedo Fit’) Our aim has always been to put swimmers on equal terms with runners and cyclists in the world of wearables and software.

We developed the first version of our accelerometer based swim tracking algorithm on the Pebble when it was first released on Kickstarter. We’re currently refining the second version, based on over 20,000 crowd-sourced lengths from real swimmers from across the world. It currently boasts 98% accuracy for freestyle and we’ve been eager to test it out on different devices.

We’ll go into more details of our algorithm, for those who are interested, towards the end of this article.

The Apple Watch is released

Fast forward to April 2015 and the Apple Watch was released along with it’s final specifications. Unfortunately this didn’t include a waterproof rating good enough for swimming. This left us with the uncertainty of when the Apple Watch 2 might be released and if it might be waterproof or not.

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.

Submersion has a similar effect to 'palming' the device. The screen turns off. Pressing the digital crown underwater will wake up the screen.

Submersion has a similar effect to 'palming' the device. The screen turns off. Pressing the digital crown underwater will wake up the screen.

HealthKit

In iOS 8 HealthKit really pushed running, walking and cycling to the forefront. You can see this in the inclusion of running/walking distance graphs and cycling graphs which you can use to populate your Health app dashboard. Although it’s possible to enter swim workouts (we do so with manual workouts in Speedo Fit), the distances are absent from any summary graphs and make a swimmer look like they’re lying in bed every time they go for a swim.

It would be really great if we saw swimming become better represented in iOS 9. Here in the UK, for instance, more people swim every week than go for a run.

There are, however, a lot of improvements in HealthKit which have really helped make this swimming app possible.

First of all there’s now the ability to start a workout via HealthKit. This puts the watch in the same mode that Apple’s own Workout app does — when waking the screen after sleeping your app is the first thing the swimmer sees - rather than having to navigate back via the apps menu. 

For a swimmer glancing at their wrist in the pool and not being able to interact with a wet or submerged screen easily, this is in invaluable.

Next there’s the way HealthKit on the watch and on the iPhone interact with each other. HealthKit on the watch is almost like a little satellite. It keeps a record of recent health data and allows you to write new information to the HealthKit Store which will then be synced back to the iPhone the next time they’re in range.

For our app this means that when the swim ends, we instantly create a HealthKit workout. That workout contains information indicating it’s a swim, the exact times of the laps performed in the pool as well as the calories burned and heart rate data captured from the strap. We also store our own extended information in the workout metadata identifying the stroke types and which pool the swim was done at.

Our swim is added to HealthKit and now contributes towards our daily activity.

Our swim is added to HealthKit and now contributes towards our daily activity.

The swim then appears within the Apple Health app and Activities app, contributing towards your daily scores. It’s also available for other HealthKit supported apps such as MyFitnessPal.

When can you get the app?

For the moment this unfortunately has to remain an interesting technology demo. Although iOS 9 and watchOS 2 should be making an appearance later this year in September, the Apple Watch itself is not officially waterproof.

13.1 Apps that encourage users to use an Apple Device in a way that may cause damage to the device will be rejected
— Section 13.1 of the App Store Review Guidelines

 

So, we’ll just have to hold out until the Apple Watch 2 and hope that it has the required waterproof ratings.

The SwimIO Algorithm

As promised earlier, here are a few details about our swim tracking algorithm.

Version 1

This was released as an open beta on the first Pebble and had a companion iOS app (SwimIO Motion). We initially developed the algorithm only with test data recorded on ourselves and a small group of volunteers from our local pool.

The companion app invited people to participate in the beta test and swim with the algorithm. Swimmers marked up their swims with the correct turns whilst deleting incorrect turn markers. They also added metadata information about the stroke they were doing, the pool length and any extra information.

We sent out weekly ‘Swim Missions’ inviting them to do specific workouts to help refine our accuracy in one area or improve our coverage. For example, “This week everyone we need 10 laps backstroke followed by 10 laps fast freestyle” (our beta testers were incredibly responsive to these missions and this proved an immense asset to us. Thanks guys! )  

Version 2

Thanks to version 1 and our audience of swimmers, we now have what is probably one of the largest data sets of marked up real world pool swimming. It covers everything from casual swimmers right through to training athletes. All in a variety of strokes, pool lengths and swim conditions. 

It’s this real world aspect of the data which has massively benefited our work on version 2 of the algorithm. 

Our first piece of work was to create a testing framework in order to objectively evaluate each new candidate version. We built this as a Rails app which is capable of running an algorithm against any subset of our swimming database. We have all of our swims tagged according to various factors such as stroke type and swim conditions (e.g. did they stop and start a lot, knock a lane rope). We also defined a known set of inputs for the algorithm and outputs along with the ability to generate custom graphs from any given run and see all of them for a set of swims on a single page.

When evaluating a given candidate run there are generally always a few problematic swims. Our setup enables us to run that algo locally on the selected swim and then tweak the algorithm whilst live viewing the results in our IDE to see how we can better fit the swim. What has really helped us here is initially prototyping new algo ideas using the R statistical computing language. Tuning parameters to work well for one swim can be quite distorting — being able to then run that tuned algorithm back across the whole data set again keeps things honest and objective.

We’ve built our algorithm up in layers in this way, whilst keeping each aspect parameterised. Once we’ve got a set of promising mechanisms, we’re able to combine machine learning with our test framework in order to find the best possible configuration to maximise accuracy on the highest percentage of swims.

Bravas

It’s at this point that we had to take a step back and really look at what the accelerometer data on a wrist is measuring (at least in terms of turn detection): unusual disruptions in signals. Although we optimised as much as possible to look for disruptions matching the profile of a turn, unusual things are always going to happen at other times. The person swimming in front might suddenly stand up or slow down, someone behind might overtake, or you stop to adjust your goggles.

We’ve developed a technology called Bravas which builds up a picture of the swim as it happens and then constantly re-analyses the swim finding turns where a normal signal based algorithm might have missed them and removing misclassified interruptions. I like to visualise it as a loosely fitting wetsuit which gradually adapts to the swimmer until by the end of their swim it’s a perfectly fitting skin-suit anticipating their every move.

Putting it all together

With Bravas layered on top of our base algorithm and the two of them tuned via machine learning applied using our test framework, we’ve now got an incredibly good algorithm for real world conditions. 

The last stage in our development was creating a C implementation which is fast enough to run on a device such as the Pebble. Fortunately we’ve got a good depth of knowledge in our team with a background ranging from telecommunications engineering to console graphics and physics engines. All through our development we tried to make sure we only used methods which would quickly and easily translate to small processors and memory footprints. 

Our test framework allowed us to run the C implementation on the same set of swimming data as the R reference and quickly find any differences in results which we could then isolate and fix.

The Apple Watch 2 and the future

We really hope that Apple see the demand for an official, fully waterproofed Apple Watch. Once that is available, we’ll be able to ship a fully featured swimming app.

In the mean time, it would be great to see swimming become a first class citizen in the Apple Health and Activities apps. Running and cycling both have their own distance graphs you can view in the dashboard whilst for swimming you have to drill down to individual workouts. Although you can’t swim with the Apple Watch, many people swim with other devices as well as logging their swim workouts manually on other apps (including our own manual swim tracker app ‘Speedo Fit’) 

If there is a future ambition for Apple Health/HealthKit, Apple Watch, the new Activity app and ResearchKit to all tie up and tell the narrative that "Apple user's live longer healthier lives", then recording all fitness activity, including swimming, is a must.

We hope you’ve enjoyed reading what’s turned out to be quite a long post.
It’s been a real team effort with the entire team working in the evening and at weekends on the different component parts to make it a reality.

We’d also really like to thank London Aquatics Centre for their kind permission to film our test in their amazing pool and of course DCRainmaker for his extensive Apple Watch waterproofing tests which made us brave enough to try this.

@earltedly 

If you're interested in receiving more news about our swimming algorithm, potential beta testing and being notified of releases, please sign up below.

77 Comments

5 Comments

HealthKit in depth: from the perspective of a swimming app

Introduction

Wouldn’t it be nice if an app you use to track one activity could share data with apps you use to monitor other activities? You’d then have a more complete and intelligent picture of your health. For example a calorie counter app, such as MyFitnessPal, could increase your daily food allowance automatically when you’ve been for a swim. Your activity tracker wouldn’t think you’d been slacking off all week when you’ve actually spent 2 hours a day in the pool!

Well that is the promise of Healthkit, Apple's new Health 'aggregation' framework. 

This post is going to explore HealthKit from a user perspective and use our implementation of Healthkit in v3.1 of the Speedo Fit swim tracking app to illustrate different elements.

What is HealthKit?

New in iOS 8, HealthKit is a technology which app and hardware developers can use as a store for all of your health and fitness data. You ultimately control which apps are allowed to add data to this store, read data from the store and also the specific data types involved.

The idea is that developers no longer need to write special code for each other when they wish to exchange data. I’ll talk a little bit later about to what degree Apple have achieved this.

Apple envisage there being three types of apps:

  1. Analysis of data & graphs
  2. Recording of information
  3. Sync data with medical records

At the moment we’re mostly type (2).

Apple's Health app itself is actually just another developer app accessing HealthKit. It just has special permissions allowing it to write 'characteristics' such as gender, height and birthday. It can also allow you to change the permissions of othe…

Apple's Health app itself is actually just another developer app accessing HealthKit. It just has special permissions allowing it to write 'characteristics' such as gender, height and birthday. It can also allow you to change the permissions of other HealthKit apps.

How it works

I tend to think of HealthKit as being like a mixing desk in a recording studio. All the apps are the different instruments and HealthKit is responsible for managing all the inputs and outputs. Each app only has to worry about it's connection to HealthKit.

Apple have defined over 60 different data types which can be stored. The list of data types is determined by Apple, so a bit like an exclusive nightclub, if it’s not on the list it’s not going in. Data types include things such as steps, heart rate, blood pressure, resting calories (basal metabolic rate), active calories, weight, sodium consumption and sleep - so it's pretty extensive!

When recording data there is the idea of it being a sample. Each sample is tied to one data point and has a start and end time. So say you took my heart rate at 2:01pm, then recorded the average over a minute and found it was 61 bpm, you’d record a heart rate sample with a start time of 2:01pm, an end time of 2:02pm and a value of 61 bpm. Samples can really be any length of time so as part of a swim recording I might have a sample spanning half an hour with a single active calorie measurement representing the entire swim.

CC Image courtesy of choreographics on Flickr

CC Image courtesy of choreographics on Flickr

This is a very important concept - HealthKit is essentially a huge timeline spanning your life with all of your health & fitness data laid over it with precise start times, end times and values for each sample.

Each sample has extra data attached to it. This includes the app the sample comes from as well as things such as whether the data was from a device (e.g. a heart rate or blood glucose monitor) or was manually entered, as well as unique identifiers to help the app developer manage the data their have recorded. In our case swims are manually recorded and we store our unique id for your swim so that we’re able to remove or update it within HealthKit if the swim is deleted or altered within Speedo Fit.

Workouts

CC Image courtesy of GrejGuide.dk on Flickr

CC Image courtesy of GrejGuide.dk on Flickr

Workouts are a bit more special in that they group a collection of samples together and classify what they represent as a whole. For instance when I go running I have my GPS watch, I also have a foot pod and a heart rate monitor. The data points I have from all of that include:

  • distance
  • duration
  • active calories
  • activity type
  • steps
  • heart rate

My watch samples all of this about every 5 seconds so I might go for a one hour run and with 12 of these samples a minute, I end up with 720 samples for the whole hour. Those samples will then all be written to HealthKit across those separate data points and provide a very rich snapshot of my body for that time period.

For Speedo Fit we don’t quite have access to the same level of detail yet, but we log still log the following information as a workout:

  • distance
  • duration
  • active calories
  • activity type

When a swim is logged we store a single sample for the active calories which spanned the whole time from the start of the swim to the end.

Active Calories

As an aside, we have added the estimation of swim calories as part of this release. We felt that it was an important addition to make your swims in HealthKit more relevant to other apps.

The generally accepted method for estimating active calorie burn is via metabolic equivalents (METs). Every activity has a MET score reflecting the amount of exertion. An MET is the number of calories burned during an activity per kilogram of bodyweight per hour. 

hours x MET x kg

There are lots of charts estimating the METs of all kinds of activities ranging from hoovering to horse riding. For our first version we’ve mapped a range of 6 METs to 12 METs for swims and we scale that based on the time in the pool and the distance swum.

This allows us to add an estimation of calories when recording swims to HealthKit, provided we are either given access to your weight via HealthKit or you provide one manually within the app.

The fact that we can request your weight via HealthKit is another example of its benefit. For example I have Withings WiFi scales at home so my weight is automatically synced whenever I weight myself. This keeps my calorie estimates always as accurate as possible.

Lastly, calorie estimations are not just for HealthKit users! You will still get them if a weight is entered in your profile and you set a start and end time on your swim.

Start times, duration & historical swim data

I think one of the guiding principles of any app contributing to a users HealthKit store is that the timeline must be sacrosanct. What I mean by that is that if the data is not complete enough then it shouldn’t be added.

When swim recording was first added to Speedo Fit, we decided to just set the date of the swim and to not worry about start times or end times so as to make it as quick and easy as possible to record a swim. In Speedo Fit 3.1 we added the ability to set a duration.

Going back to the timeline concept though, this isn’t enough for HealthKit. Without a specific start and end time for each swim in your history, it’s not possible to record them. If we were to pick and arbitrary start and end time for each swim, there’s a high chance they would overlap with other activities and future apps analysing your data would get very confused.

We have therefore made start and end times mandatory when recording a swim when HealthKit is enabled.

My data is in HealthKit, now what?

This is now really up to other app developers. Any time you turn on HealthKit in another app and it requests access to read workouts and active calories, the chances are your swimming data will be contributing in some way to the view of your health data that app is giving you.

Unfortunately Apple’s Health app currently only shows distance for running and walking, not swimming. You will see your swims on the active calories graph, so don’t worry, your data is in there! 

Data, Privacy and iCloud

An interesting thing about HealthKit is that the data just lives on your iPhone. Although your HealthKit store is backed up with iCloud backup it is not synced to iCloud. There’s an important distinction there. For example, if you have a work iPhone and a personal iPhone, each iPhone will have its own distinct HealthKit store. However, providing you have iCloud backups turned on, if your phone is lost or stolen or you buy a new one, restoring from an iCloud backup will restore your HealthKit store.

Apple are making quite a big deal about this. The recorded data is of an incredibly private and personal nature and they’re preventing HealthKit stores from being passed over any kind of network except as part of a secure iCloud backup. Part of the App Store submission guidelines specifically prohibits developers from storing HealthKit information in iCloud without user permission and all apps using HealthKit have to have a privacy statement explicitly saying what we do with your data.

I think the fact your phone is the central hub of information there, collecting data from apps and health devices is indicative of Apple’s vision of the future. One where your phone is a mini-portable server and you have an set of satellite devices (Apple Watch!) which you use to send and receive data. The Apple Watch, for starters, has at least two sensors which will be directly feeding into your iPhone - heart rate and accelerometer.

The Apple Watch

The Apple Watch

HealthKit and third party Hardware

I already mentioned earlier that a data sample can be tagged as being manually entered or being from some kind of device. Most modern devices are adopting Bluetooth Low Energy as their method for synchronising with your phone. Bluetooth.org have published standards for certain classifications of devices. Apple are actually supporting four of these initially so that they can be paired with your phone and their data written automatically to HealthKit whenever they are in the vicinity of your iPhone. This includes heart rate monitors, glucose sensors, blood pressure monitors and health thermometers. So long as a device implements the specification in a standard way the manufacturer will no longer have to make their own app to live on your iPhone. I suspect that other devices will be supported as more categories become established.

Wahoo Tickr X

Wahoo Tickr X

So how do apps know when new information is available?

One of the other aspects of HealthKit is that an app can subscribe to data points. An app can choose any number of the 60+ data points and then, with permission, ask to be notified whenever there is new information.

That means that another app might wish to know whenever you go for a swim so as to remind you to hang your wet swim shorts out to dry (instead of leaving them in your gym bag for days as I often do). It could subscribe to the workouts sample type and as soon as a swim comes in it wakes up and sends you a little notification.

A more real world case is that hospitals are starting to create out-patient monitoring apps. Whenever a patient uses their blood pressure monitor, the hospital app gets notified of the new reading, sends that data to the hospital computers, a doctor might then review it, see there’s a problem and call the patient in. And of course if the patient forgets to do a reading the app could then remind them to do one.

What are the downsides?

Perhaps one of the most clever things Apple have done is offload all of the work on to app developers. HealthKit really is just a dumb repository. An example of this is Basal Metabolic Rate (BMR). This is the calorie burn of your body when at rest. There are any number of algorithms for estimating this and it really depends heavily upon your genetics, level of muscle and fitness. At the moment it’s sitting in my HealthKit as a blank data point. Despite having a number of fitness apps installed on my phone which estimate this in-app none of them have quite plucked up the courage to be the one to write this to my store.

And that’s perhaps the crux of it, most health information, despite the exact numbers, really are just estimates. Very useful estimates which can help us to make informed health related decisions. Unfortunately by recording these to a definitive central store, it’s going to make a lot of developers nervous about committing these estimates for posterity.

Lastly, Apple are holding the keys on data points. If an app wants to record something interesting not included on those data points, they’ve got two options:

  1. Don’t record it in HealthKit
  2. Appropriate a related data point and record it as custom meta-data

For a couple of examples of (2), take sleep and swimming. For sleep you can only record awake / asleep. It is not possible to record different sleep modes such as light sleep, deep sleep and REM sleep. For swimming it’s not currently possible to record the strokes or intervals in the swim.

There is a solution to those - custom metadata. Each sample can have associated data set by the developer which other apps can read. The only problem there is that we’re going to have to agree between ourselves, as developers, how exactly we store specific data there. Without agreed metadata keys everyone is going to have their own way of doing things.

Still, it’s a lot less work than having to implement an entire custom API for every service you wish to link with!

Summary

I’ve covered a lot of ground in this post. Hopefully you’ve got a better idea of how we are using HealthKit in Speedo Fit as well as the possibilities of what can be done with HealthKit as it currently stands.

I’m personally extremely hopeful that as more developers and hardware companies adopt HealthKit, we’ll begin to get a much more detailed view of our health and daily lives. In turn this will give us meaningful insights which help us to lead happier lives.

I think it’s going to be incredibly interesting to see what is done with this data and how it is going to force developers to focus on and improve each of their areas of expertise.


Speedo Fit swim app to track your swim workouts is available from US, Canada, UK, France and Mexico app stores here. Version 3.1 with HealthKit integration will be live in the app store later today (16th October).

I'm on twitter as @earltedly if you'd like to chat more about HealthKit.

5 Comments