Apple Watch Power Meter Support: Everything You Ever Wanted to Know

Last month at Apple’s annual developer conference the company outlined the future of Apple Watch, at least in terms of software, for the next year. One item that seemed to surprise many was the announcement that Apple would be adding support for cycling power meters (among other cycling sensor types). While that might have come as a surprise to some, the announcement wouldn’t have been a surprise when viewed through the lens of numerous other Apple sports-focused announcements over the past year. These announcements have been heavy on data metrics, and heavy on pushing the boundaries of what people have historically thought of when it comes to the native capabilities of the Apple Watch.

In this post, I’m going to dive into how power meters work on the Apple Watch, now that Apple has transitioned from developer beta to public.  Obviously, I expect (and hope) things will change between now and September, when Apple historically releases the new version of watchOS to the public as a production build (WatchOS 10 in this case). Usually, that’s done alongside new/annual Apple Watch releases. If we look at last summer with triathlon mode and running power, we saw some notable/substantial changes during beta, especially in the August timeframe.

Additionally, last month while at Apple’s Cupertino headquarters for WWDC, I had a chance to sit down with Jay Blahnik, Apple’s Vice President of Fitness Technologies, to discuss the power meter addition and why Apple chose to do it. I’ve included that in the first section below.

With that, let’s dive into it.

But Why Power?

Despite not being a surprise, I was still curious as to their reasoning for adding power. To begin, with most (virtually all?) power meter owners already having a device capable of recording power meter data, why focus on adding power meter support? To that, Jay Blahnik says:

“Last year was the most expansive update to the Workout app that we’ve ever done, was focused on runners first. This year we put a big focus on cycling. We’ve gotten feedback for years that folks would like to be able to connect their accessories to the watch. And we also also though this is a really great opportunity to have the phone play a role. So we’re really excited about where we’ve started, but I would say ‘watch this space’, we’re just as excited about what’s coming in the future”

There are two pieces of note here. What’s left unsaid in Jay’s comment is that up till now, 3rd party app cycling sensor support has sucked. There have been incredibly few apps that can even connect to power meters (without the phone), and even fewer that manage to do it even halfway correctly. Every time I considered writing an article about “How to Connect a Power Meter to an Apple Watch”, my stomach turned at the options. None were awesome.

The second piece he mentions is “the phone”, as part of this announcement, Apple also basically made a mode on your phone that mirrors your watch data fields as a full-screen bike computer. Today, it’s an exact mirror (no customization of data fields), but does have some fields larger than on the watch. More on that in a different post. It’s more ideal for things like bike commuting than most hardcore cyclists.

I was then curious whether they saw more opportunity in running power or cycling power, in terms of which one people would use more of going forward. While Jay didn’t want to try and make predictions there, he did note:

“I wouldn’t make any predictions about it. What I would say is, I think if you were to separate runners and cyclists as distinct groups, there’s probably more cyclists that have an affinity or a thought process around power, than runners that have that same sort of connection to power. Running’s a big group, but there’s probably more cyclists that are familiar with what power is then maybe runners would be familiar with what running power is.”

Of course, that immediately begs the next question: Do you see this as something that’s more likely to get existing Apple Watch users to add a power meter, or something that’s more likely to drive the adoption of Apple Watch for existing power meter users?

“We think both are great. So we’re constantly amazed at how many of our users find their way into things they never thought were interesting to them, because they have metrics available on their watch with them every day.” following with “So I would say in this space we’re certainly happy with people that have always wanted this feature. We also know that for people that understand the watch can do that, they may suddenly get excited about these features, and it’ll put them on their own journey. I think we care about both – people that are new to it, and people that are already deep in it.”

There’s more from that conversation I’ll include in the relevant new feature area posts, like the phone companion app I’ll discuss separately, or the new topographic mapping post from last week. Still, I’d say the overarching theme of that conversation is that Apple seems to be aware that power meters can be viewed as a niche thing, and they’re OK with that. There are plenty of niche things in the Apple ecosystem, and after all, competitor Peloton has built a massive empire of a business almost entirely upon the power/wattage foundations. Thus, while power meters may be geeky, the reality is that plenty of ‘normal people’ train with them day in and day out already today.

Setting it up:

Pairing a power meter with the Apple Watch is silly easy. To do this, you’ll go into the Bluetooth menu on the watch (Settings icon > Bluetooth), and then you’ll see ‘Health devices’ listed. Obviously, as the setting implies, it only supports Bluetooth power meters. Though, virtually all power meters made in the last 8+ years are dual ANT+/Bluetooth. You can save multiple power meters here, alongside heart rate sensors and cadence/speed sensors. Further, you can pair smart trainers as long as they broadcast as a Bluetooth power meter (all do). You cannot directly pair the Bluetooth FTMS signal at this time, but again, all smart trainers on the market now dual-broadcast Bluetooth FTMS & Bluetooth Power.

Apple will pull in cadence values from the power meter signal (including on trainers), as virtually all power meters send cadence signals. What’s super interesting about this OS-level pairing, is that *ANY* watch app can take advantage of these sensor pairings. Thus, watch apps no longer have to write their own pairing code, nor do they have to deal with calibration, etc… They can simply leverage the native system for that, just like they’d have done previously with heart rate.

Once paired, you’ve got a few options. This includes setting the crank length for power meters that have that option (mainly pedal-based ones), as well as forgetting the pairing:

 

Further, you can send a calibrate command. When you do this it’ll go off and (hopefully) do the calibrate thing. However, it doesn’t return back the calibration value, unfortunately, so you can’t use it to determine when things are going wrong. I’ve also found it to be a bit finicky in some cases, whether it works at all.

It’s important to now add the power meter data fields to your cycling sport profiles. By default, these won’t be there. While it will record the data to the file regardless, if you don’t add these to your watch bike profiles, you won’t see the power during the ride. Simply go into the ‘Workout’ app, then next to both Outdoor Cycle and Indoor Cycle, choose the “…” to get to more settings, then choose ‘Preferences’, and then choose ‘Outdoor Cycle Workout Views’. Scroll down a bunch and toggle the ‘Power’ option, and then ‘Power Zones’ below that, if you want that.

 

Additionally, in those menus, just back one level, you can always set a per-workout target, including cycling power zones. This includes a target power level, a power range (custom one-off zone), and then your existing power zones (or off).

 

With that, you’ll start your workout and then will see your power data on your watch. As the workout progresses, you’ll get more and more data in that little graph, just like you would for other data metrics on the Apple Watch. That all works the same way.

Likewise, cadence will show up too, assuming you’ve got that data field configured. At the end of the workout, you’ll see both your average power and average cadence:

From there, it’ll save the workout to Apple Health, making it accessible to the Apple Fitness app on your phone. Note that at this time, Apple doesn’t leverage any of the cycling sensors within their Apple Fitness+ classes/platform.

Post-Ride Data:

With the ride complete, back on your phone, you can crack open the ride data in Apple Health (the underlying database Apple uses), or, more likely, in Apple Fitness (the pretty side of it). You can see here a few screens from a ride:

   

Likewise, over in Apple Health, you’ll see the data in the Cycling Power section under Activity, including samples at the per-second realm:

 

Now comes the tricky part: Getting the data to any other platform.

You see, as with all past workouts types, Apple doesn’t have any file exporter (e.g., to export to a .FIT/TCX/etc…). Instead, they leave that up to 3rd party apps. Thus, as of today, there are officially none that support this. Of course, in various private betas, companies are working on it. I’ve been using a private beta of the HealthFit app (3rd party) to get the data out of Apple Health and into standard .FIT files. Thus, allowing me to upload to 3rd party platforms, or use it within the DCR Analyzer, like so (this is a comparison side-by-side of the same power meter, one recorded on the Apple Watch, the other recorded on a Garmin Edge cycling computer):

But, the process to get apps updated is gonna be long, slow, and bumpy. I outline some of the challenges in the ‘Bugs’ section below, both in terms of normal bugs, but also quirks. We’ll also have to wait and see if companies like Strava will update their apps to import the power data now included within the Apple Watch recorded workouts.

Power Zones & FTP:

In addition to the recording of power meter data, Apple will also calculate your FTP – which is your Functional Threshold Power. Generally speaking, your FTP value is the maximum amount of power you can hold for one hour. There are a variety of tests you can do to determine this, but many wearables and bike computers will automatically calculate it for you now.

In Apple’s case, that calculation requires both a power meter (obviously) and heart rate data (which the watch provides, assuming you wear it on your wrist). Further, it requires at least 5 sessions of 10 minutes in length. The idea behind the multiple sessions is to ensure that they’ve at least got some baseline of data to work with. There’s no point in you doing a single easy ride and giving you a low FTP value because you haven’t put up bigger numbers. On the flip side, the idea behind leveraging the heart rate in the algorithm is to understand whether or not you’re working hard to produce a given wattage. That gives them insight into whether an effort was easy or hard.

This data shows up in a bunch of places, albeit most are kinda buried. First, it’ll show up in Apple Health, if you dive down into your data metrics you’ll find Cycling FTP:

 

In my case, I’ve done sporadic cycling (with power) workouts over the past month, mainly because of a combination of travel and…well…more travel. These included indoor and outdoor workouts, up to about 2.5 hours in length and on varying intensity from super easy to moderate but not all-out-dying trainer workouts. Throughout this entire time period, my FTP after initial detection, has stayed exactly at 251w. Now, Apple also says that it’ll update your FTP every 30 days. Thus, I think my 5th workout from June was exactly 30 days ago, thus, it appears I need to wait until the next power workout outside that 30-day period. Either way, this seems pretty ripe for confusion.

In terms of accuracy of the FTP value, if this was early June, then that’d be woefully below value (where I last tested in the 300-310w ballpark). However, the month of cycling power-meter enabled workouts as noted as being lighter side. And in particular, I haven’t given it a huge amount of hard (high wattage) workouts to do its computations from. Thus, for the moment I’ll have to sidestep accuracy there and come back to it. However, I don’t quite think it’s working right, given that value has never once changed. This matches a friend who has also seen the same thing.

Now, this FTP value is then pushed back to your cycling power zones on the watch. You can override these zones with custom zones if you want. Here are my default zones:

What’s cool here is that Apple allows you to create custom zones not only of varying power ranges, but also allows you to vary the quantity of zones. For example, if you want an 8-zone system, you can do that. Or, if you want a 4-zone system, you can do that too. If you make custom zones, Apple will not override them with FTP detection.

  

These can be done in the Apple Watch app on your phone, as seen above. And note that cycling power zones is separate from running power zones, as there are actually no running power zones at all today in the Apple world. Note that at present Apple doesn’t calculate VO2Max from cycling, that’s still a walking/running activity.

Bugs & Stuff:

It goes without saying that beta involves bugs. Given the firmware is currently in public beta 1 (or developer beta 3), it stands to reason there are some bugs. Things like the aforementioned static FTP value being one of them. However, I’ve also encountered a number of others. Thus, while some portions of the platform in this beta are perfectly fine, I wouldn’t say power meter data collection is one of them.  There are two clear bugs I’ve stumbled into, and then one quirk. Plus, a thing or two I’d like changed. To begin:

(I’ll update, or remove, or something, this section once these issues are resolved)

1) Half-Cadence (Bug): All cadence values are halved (e.g., 90RPM becomes 45RPM) across a number of power meters I’ve tried (including Garmin Vector 3 and Rally, the most popular power meter models out there). Every once in a while it’ll randomly show the correct value for a second or two, but then it goes back to halving it. Here’s an example of that:

 

2) Sticky watts (Bug): For at least some of my data sets, I’m seeing substantial sticky-watts issues. Sticky-watts is when you stop pedaling, but the power values continue to be recorded at the original value for a period of time. For example, if you do a sprint, and then stop pedaling, it’ll continue to record “600w, 600w, 600w, 600w” for 6-8 seconds (or more). This is despite the power meter having properly transmitted “0w, 0w, 0w, 0w”, which I can validate using secondary recording files. You can see an example of that here:

3) Multiple values per second (quirk): Now, this isn’t a bug per se, and some might see it as a feature. But it’s a challenging feature for app developers. You see, power meters transmit data in different ways. Simplified: Some can be once per crank revolution, and others once per second.  Normally, this doesn’t matter to consumers, because watch/bike computer companies will consolidate this to a single value per second. The ‘problem’ is that Apple actually can write up to two values per second, unconsolidated. Again, there’s nothing wrong with that in the right context, but it’s confusing to app developers, who mostly just pick one value, since virtually all fitness file types today operate on a single-value-per-second timeline. Thus, on one hand, kudos to Apple for allowing extra data. But on the other hand, it’s already causing data discrepancies (as apps will decide how to deal with this differently). Here’s an example of three different valid power meter data points for the 19th second of that minute:

   

In any case, for the two bugs, the first one surprises me. I wouldn’t have expected to see that this far along. The second one though, doesn’t really surprise me. This is the ‘fun’ part of the Bluetooth power meter specification that many companies have struggled with over the years. And now Apple gets the pleasure of hanging out in that garden for a while too. The only real solution there is for them to spend more time looking at more data sets from power meters. The good news, as I alluded to previously, is there are simply not that many power meters out there. The bad news is that there ARE many versions of firmware for those small set of power meters, of which have vastly different behavior’s over the years. And most consumers never update their power meter firmware. On the bright side, I do appreciate that Apple is recording the power meter firmware version to Apple Health. That’ll help them quite a bit in troubleshooting (as seen above).

Finally, the one thing that isn’t a ‘bug’, but rather ‘by design’, is that Apple isn’t recording left/right power split (for dual power meter sensors). Their system does correctly take the total power value, but does not record the individual left/right metrics. At this stage in development, I think that’s a substantial mistake. I’m already seeing developers struggle with Apple’s power implementation here, and once developers get it sorted out – they sure as heck aren’t going to change it later on to add left/right power split when Apple does get around to adding it. It’s far easier to add that now in the developer/public betas and make it a foundational baseline thing going forward. I’m not asking for all sorts of other fancy power metrics, I’m just asking for simple left/right split. There are a million other silly health/fitness metrics that Apple records (including far more detailed running efficiency metrics), to not record left/right power is just weird (since it’s already part of the data stream being sent to them). Hopefully that changes.

Going Forward:

It’s incredibly cool to see Apple add power meter support. In many ways, it’s core to ‘legitimizing’ the Apple Watch as an endurance sports-focused watch. Or at least, a cycling watch. Certainly, there are many hurdles left. But like with triathlon mode last summer, and advanced running metrics last year, and track mode, and on and on. Each one of these things is part of a foundation to do more advanced things. Be it natively by Apple, or for 3rd party apps.

Undoubtedly, a very small portion of Apple customers will use power meters today. Inversely, a very large portion of the sport-focused cycling scene are using power meters today (yes, the definition is loose there, but if you’ve got a semi-modern GPS bike computer and a dedicated cycling kit to wear, there’s a strong chance you’ve got a power meter on your bike). And certainly, that segment continues to grow. As bike OEMs have begun to charge only a few hundred dollars (if that) upsell for a power meter, the ability to even buy a mid-range road bike without a power meter is going to dissipate. Thus, Apple is getting ahead of that.

Again, I see this move as more about box-ticking within the serious athlete side, rather than Apple trying to win over every cyclist out there. Instead, it’s ticking a box that might keep an iPhone user who rides once or twice a week and happens to have a power meter on their bike, from buying a Garmin watch. It’s unlikely to keep most serious cyclists from buying dedicated bike computers. But again, that’s unlikely to be Apple’s goal.

Still, one glaring gap here is the lack of transmission of heart rate over Bluetooth to 3rd party apps. When I posted my initial WWDC video/post (that video now has nearly 400,000 views), by far, the most common question was some form of “Can I see my Apple Watch heart rate on XYZ app/device/platform?”, nearly 25% of all comments in the first few days asked that (an insane percentage). The answer to that remains no. If I were to look at value for dev time, I’d argue that allowing that would open up far more gym/connected fitness opportunities to leverage an Apple Watch than cycling power (globally speaking). It also legitimizes further the Apple Watch as a sports-focused device, given almost all their competitors in this space have this feature. Hopefully, that’s something that can change during the beta process.

With that – thanks for reading!