Updated Info Regarding Discrepancies in Member's iOS Calorie Adjustment

Tuesday, November 22, 2016, 2:08pm PST


To all of our iOS members, thank you for continuing to voice your feedback about the calorie adjustment you're receiving after our latest iOS update.

We have continued to investigate based on your reports, and have found a second error that we will be fixing in the next update of the iOS app. This fix should result in an increase in calories in your adjustment in most cases.

For those who are interested in a more detailed account of the two fixes, please continue to read. If the technical details are a snooze, you may want to skip the rest of this post.  Again, thank you for providing these specific scenarios, they've been instrumental in our investigation of the issue.

First Fix:

Prior to version 7.5 of the app, we accounted for step data at five minute intervals. Once the step count was synced, we would then calculate the estimated calorie burn, factoring in the interval, number of steps, the user’s BMR, and other variables. But while the data was collected in five minute segments, the code that calculated the calorie burn based the calculation on a one minute interval, resulting in an inflated calorie burn estimation. We fixed this in 7.5 by changing the interval at which we sync step count to one minute. Now that the step-count and calorie intervals are the same, the calculated calorie burn is more accurate, but has changed noticeably in some scenarios.

As an example, in prior versions if a user walked 100 steps in five minutes, we would record those 100 steps, and then calculate the calories as if the user had walked 100 steps in ONE minute. This compression of the same number of steps into a shorter time period incorrectly indicated that the user was walking at a much swifter pace, which inflated the estimated calorie burn.

We expected that this fix would result in lower calorie awards than users were accustomed to, in cases where many steps were taken within five minutes.  But your reports of excessive drops in highly active periods led to the discovery of the second issue, for which a second fix is coming (hopefully in the next release) of the iOS app.

Second Fix:

In the original version of the steps feature, when we were capturing and evaluating step data at 5 minute intervals, we processed truncated values of calories for each 5 minute period. 

For instance, if a user took 170 steps and burned 2.7 calories, we sent a 2 calorie value to the server. For each five minute segment, there was a potential "loss" of a maximum of .9 calories.

When we converted to evaluating steps in one minute increments, and deployed Fix #1 above, the truncation remained in place. However, we were now truncating up to .9 calories PER MINUTE. Over the course of five minutes, this could result in a "loss" of a maximum of 4.5 calories.

We have now updated our backend step server to accommodate fractional calories from steps, and in the upcoming iOS release we will be sending fractional calories for steps for processing, rather than the truncated, integer step count sent previously. The impact of the truncation was trivial in the previous system, but absolutely was causing lower than desired calorie adjustments over periods of high activity.

Thanks again for your reports. We make every effort to test and verify our software updates in beta testing, but some issues only surface when large numbers of users with a variety of use cases get their hands (or feet) on the features. We'll have the fix to you as soon as we can.


MyFitnessPal Staff

Last Updated: Dec 12, 2016 03:07PM PST

Contact Us

Don't see the answer to your question?

Your fellow MyFitnessPal users and our Customer Happiness Team are always here to help.