Synopsis:

For nearly ten years, Apple Health data has played a role in significant criminal investigations, prompting ongoing and crucial discussions about its dependability and precision. One of the earliest documented instances of Apple Health data as evidence was during the 2018 trial of Hussein Khavari, accused of the rape and murder of Maria Ladenburger in 2016. Investigators noted Flights Climbed activity from Khavari’s Apple Health app, correlating it with the movement needed to ascend the riverbank after allegedly disposing of the victim’s body in the Dreisam River. Police later corroborated this finding by replicating the activity, reviewing the Apple Health data, and correlating the data with geolocation and timeline evidence from the case (BBC News, 2018). More recently, in the 2023 Alex Murdaugh double-murder trial, prosecutors presented data from Maggie Murdaugh’s iPhone Health app, which recorded 38 steps between 8:17:41 and 8:18:29 p.m. on June 7, 2021, shortly after her phone was disconnected from a charger (The Trial Channel, 2025). In the Karen Read murder retrial, defense attorneys pointed to 36 steps (approximately 25.46 meters) logged on victim John O’Keefe’s iPhone after he was reportedly left outside the Albert residence (Czajkowski, 2026). These examples illustrate how Apple Health data can powerfully reconstruct timelines and physical activity and aid in building a fuller, more reliable forensic picture when combined with additional case evidence and details. This article will detail the location of Apple Health application database files within Apple iPhone extractions, evaluate Apple Health data against established benchmarks (including direct comparisons of the healthdb_secure.sqlite and cache_encryptedC.db databases), and present the findings regarding its reliability and accuracy.

Forensic Questions:

In relation to Apple Health data, the cache_encryptedC.db is said to be far more granular than the healthdb_secure.sqlite for Steps, Walking + Running Distance, and Flights Climbed. What additional data can be obtained from these databases and how accurate is the data from either database in relation to Steps, Walking + Running Distance, and Flights Climbed (or stairs ascended / descended)?

Apple iPhone Model / OS Version:

Apple iPhone 8, iOS 15.0.2

Apple iPhone SE (2^nd Gen), iOS 26.0

Tools:

DB Browser for SQLite Version 3.13.1 on Windows 11 Pro, 25H2, referred to as “DB Browser” within this work.

Location of Health Database Files:

Within this article, we will be reviewing data from two databases. The first is the healthdb_secure.sqlite, located at /private/var/mobile/Library/Health/ within a Full File System Extraction. The Health folder stores both the healthdb_secure.sqlite database as well as the healthdb.sqlite. The healthdb.sqlite holds additional beneficial data for the current OS version, product type name, and other paired source devices. Notably, both databases can also be obtained through an Advanced Logical File System Extraction (Encrypted) or even an Apple iTunes Encrypted Backup, though both means require decryption for data review.

The second database we will be reviewing is the cache_encryptedC.db, located at /private/var/root/Library/Caches/locationd/ within a Full File System Extraction. This database is not obtained through other extraction means beyond the Full File System Extraction or an After First Unlock Extraction.

Review of Data Storage:

The healthdb_secure.sqlite stores data for Steps, Walking + Running Distance, and Flights Climbed within two tables: samples and quantity_samples. Joining these tables by the data_id and using the appropriate WHERE clause provides the beginning timestamp, ending timestamp, and the quantity of the measurement, i.e., 23 steps. Note: This article will not cover SQL queries.

Steps:

Figure 1: Example of Steps data stored in the healthdb_secure.sqlite database on an Apple iPhone running iOS 26.0, displayed using DB Browser. The figure illustrates the use of start_date and end_date timestamps and the associated quantity value representing the number of recorded Steps.

Timestamp values, start_date and end_date are Apple Cocoa Core Data timestamps, or Mac Absolute Time, and are the number of seconds since January 1, 2001. Steps are data_type 7 and our quantity value is the number of steps recorded, or 23 as depicted in Figure 1. Apple defines Steps as “the number of steps you take throughout the day. Pedometers and digital activity trackers can help you determine your step count. These devices count steps for any activity that involves step-like movement, including walking, running, stair-climbing, cross-country skiing, and even movement as you go about your daily chores” (Apple Inc., n.d.).

Walking + Running Distance:

Figure 2: Example of Walking + Running Distance data stored in the healthdb_secure.sqlite database on an Apple iPhone running iOS 26.0, displayed using DB Browser. The figure shows corresponding start_date and end_date timestamps and the recorded distance value expressed in meters.

Consistent with Steps data, start_date and end_date values are present. Walking + Running Distance is data_type 8 and our quantity value is the distance in meters, or 13.7593427104875 m as depicted in Figure 2. Apple does not define Walking + Running Distance in the same manner they define Steps; however, it does define a related metric, distanceWalkingRunning, as “A quantity sample type that measures the distance the user has moved by walking or running” (Apple Inc., n.d.).

Using a simple SQL query, we can review the beginning and ending timestamps for our Steps and Walking + Running Distance together:

Figure 3: Example of the results of a SQL query combining Steps and Walking + Running Distance records from the healthdb_secure.sqlite database, illustrating the aligned start_date and end_date timestamps for these activities. This figure is displayed using DB Browser.

Flights Climbed:

Figure 4: Example of Flights Climbed data stored in the healthdb_secure.sqlite database on an Apple iPhone running iOS 26.0, displayed using DB Browser. The figure displays the start_date and end_date timestamps associated with a recorded flight of stairs climbed, with the corresponding quantity value.

Again, start_date and end_date values are present. Flights Climbed is data_type 12 and the quantity value is the number of flights climbed, or 1 flight climbed as depicted in Figure 4. Apple defines Flights Climbed as “A flight of stairs is counted as approximately 10 feet (3 meters) of elevation gain (approximately 16 steps)” (Apple Inc., n.d.).

Using a simple SQL query, we can review the beginning and ending timestamps for our Flights Climbed:

Figure 5: Example of the results of a SQL query for Flights Climbed data from the healthdb_secure.sqlite database, showing the left and right limit time bounds and the number of recorded flights climbed. This figure is displayed using DB Browser.

While the healthdb_secure.sqlite stores data for Steps, Walking + Running Distance, and Flights Climbed in a clearcut manner, obtained through basic SQL queries, the cache_encryptedC.db data storage of these same values differ rather significantly. This data is stored within one table, StepCountHistory, where there is a startTime value column, no column associated with an ending timestamp, and definitive quantity values are instead running counters (i.e., 23 steps would now be obtained from a difference in row values over the same period.) The StepCountHistory table contains data for Steps, Walking + Running Distance, and Flights Climbed activity events within columns: count, distance, and floorsAscended / floorsDescended.

Also, while the healthdb_secure.sqlite database can record data from numerous devices (paired Apple Watch, third party wearable devices, etc.), the cache_encryptedC.db solely records data for the Apple iPhone itself.

Looking at the cache_encryptedC.db, we will focus on six columns: id, startTime, count, distance, floorsAscended, and floorsDescended. Notable mention, this table also contains a pushCount column – additional research is required but likely this is the stored value for Pushes, which Apple defines as “the approximate number of wheelchair propulsions detected by your Apple Watch throughout your day” (Apple Inc., n.d.).

Figure 6: Example of the StepCountHistory table from the cache_encryptedC.db database on an Apple iPhone running iOS 26.0, displayed using DB Browser. The figure highlights selected columns that will be examined in this study, including id, startTime, count, distance, floorsAscended, and floorsDescended.

Reviewing the focused six columns:

• id, the primary key for this table and is autoincrement – it will increase chronologically with each new row of data.
• startTime is the starting timestamp and matches our start_date value from the healthdb_secure.sqlite database.
• count is the incremental Steps count.
• distance is the incremental Walking + Running Distance count, in units of meters, and operates the same as count for accumulating meters traveled.
• floorsAscended and floorsDescended is partly our Flights Climbed. An increase in the number of floorsAscended values will correspond with the same Flights Climbed within the healthdb_secure.sqlite, i.e., 2 floorsAscended = 2 Flights Climbed.

Calculating Activity Quantities from the count, distance, floorsAscended, and floorsDescended Columns:

Outside of the extractions obtained through this testing, additional available FFS Extractions, iOS 13.3.1 being the oldest, were processed and the cache_encryptedC.db was present. Within iOS versions 13.3.1 and 17.3; Steps, Walking + Running Distance, Floors Ascended, and Floors Descended were derived from their corresponding columns using a LEAD-based approach (Digital Corpora, n.d.-a, n.d.-c). In this context, LEAD returns the value from the row immediately following the current row within the table, and the activity measurement was obtained by subtracting the difference of the subsequent value minus the current value (i.e., x number of Steps).  

Figure 7: Example of the LEAD-based approach applied to the StepCountHistory table, illustrating how activities are calculated by the difference between the subsequent row value and the current row value, within the ordered dataset.

As shown in Figure 7, the Steps data stored within the healthdb_secure.sqlite database indicates 14 Steps between the starting timestamp (start_date, highlighted with green) and the ending timestamp (end_date, highlighted in red). When these values are compared to data present for the same timestamps within the cache_encryptedC.db, the LEAD-based approach yields a matching total of 14 Steps.

By contrast, the LAG-based approach, where the current value is compared to the proceeding row value, produces a value of 7 Steps which does not align with the Steps count recorded in the healthdb_secure.sqlite database. For iOS versions prior to iOS 26, the LEAD-based approach consistently produces matching results across Steps, Walking + Running Distance, Floors Ascended, and Floors Descended.

iOS 26 and newer stores data slightly differently:

Figure 8: Example of the LAG-based approach applied to the StepCountHistory table, showing how activities are calculated by the difference between the current row value and the preceding row value, within the ordered dataset.

Beginning with iOS 26.0, the LEAD-based approach no longer produced activity measurements matching those recorded within the healthdb_secure.sqlite database for Steps and Walking + Running Distance. Instead, a LAG-based approach was observed to yield matching values. Floors Ascended and Floors Descended, though, remained unchanged into and through iOS 26.0 – still requiring a LEAD-based approach.

As shown in Figure 8, the healthdb_secure.sqlite database records 7 Steps between the starting and ending timestamps. When compared to the cache_encryptedC.db for this same period, the LEAD-based approach yields 14 Steps which does not align with the activity record. The LAG-based approach returns a value of 7 Steps, matching the value recorded within the healthdb_secure.sqlite.

Looking Deeper at Real Data:

Figure 9: Example of queried Steps data from the cache_encryptedC.db database of an Apple iPhone running iOS 26.0, viewed using DB Browser. The figure shows calculated Steps values alongside their corresponding starting timestamps, the raw count column values as stored within the StepCountHistory table for each row, and a cumulative calculation of the Steps – completing 23 Steps total.

By converting the startTime values, calculating Steps, reviewing the raw data from the count column, and adding a cumulative column derived from the count column values, a clearer representation of the activity recorded is revealed.  The total reflects the same 23 Steps recorded in the healthdb_secure.sqlite database (Figure 2); however, this view provides the first glimpse of the granular data contained within the cache_encryptedC.db. Pairing starting timestamps and Steps values we can review the beginning of the first 10 steps, the next 5 steps, the following 4 steps, and the final 4 steps.

Figure 10: Example of queried Walking + Running Distance data from the cache_encryptedC.db database of an Apple iPhone running iOS 26.0, viewed using DB Browser. The figure displays the calculated Walking + Running Distance values (in meters) with their starting timestamps, the raw distance column values as stored within the StepCountHistory table, and a cumulative total distance of 13.7593427104875 m.

Applying the same approach, Walking + Running Distance can be examined at a more granular level. The cumulative distance reflects the same 13.7593427104875 m recorded in the healthdb_secure.sqlite database (Figure 2); however, the cache_encryptedC.db records display distinct time segments tied to the first 6.01 m, the next 2.83 m, the following 2.4 m, and the final 2.49 m.

A focused review of Floors Ascended and Floors Descended isolates Flights Climbed data for analysis. Using a SQL query against the StepCountHistory table of the cache_encryptedC.db database, the starting timestamp and number of recorded Floors Ascended or Floors Descended can be reviewed.

Figure 11: Example of queried Floors Ascended data from the cache_encryptedC.db of an Apple iPhone running iOS 26.0, viewed using DB Browser.

Depicted in Figure 11, the number of Floors Ascended derived from the incremental floorsAscended column matches the Flights Climbed data recorded within the healthdb_secure.sqlite database (Figure 5). While the cache_encryptedC.db database stores data for both Floors Ascended and Floors Descended, there is no corresponding data_type for Flights Descended within the healthdb_secure.sqlite database.

This is particularly interesting as the healthdb_secure.sqlite database can store Stair Speed data, or the measurement of how fast the user walked climbed or descended stairs. These records, when present, are segmented into Stair Speed: Up and Stair Speed: Down. Stair Speed data requires the user wear an Apple Watch product while ascending or descending stairs.

Estimating Ending Timestamps: Review of the PednetHistory Table:

The cache_encryptedC.db extracted from the Apple iPhone 8 running iOS 15.0.2 contained 16 tables. Beginning with iOS 16.1.2, the ActiveConfig table was observed as being present, although this table contained no data across any analyzed iOS version. iOS 26.0, examined on the Apple iPhone SE, was the first version to include the PednetHistory table.

The presence of this table provides additional context for interpreting Steps and Walking + Running Distance activity, particularly through the inclusion of an endTime timestamp. This addition supports the LEAD-based approach used to derive ending timestamps for records within the StepCountHistory table, which does not contain an explicit endTime column.

Figure 12: Example of PednetHistory table data from the cache_encryptedC.db of an Apple iPhone running iOS 26.0, viewed using DB Browser.

The PednetHistory table, as shown in Figure 12, contains the following columns:

• recordID – the primary key for the table, configured as an autoincrement value and not associated with any id column in other tables within the database.
• startTime – the starting timestamp, corresponding to the startTime value in the StepCountHistory table and the start_date value in the healthdb_secure.sqlite database.
• endTime – the ending timestamp, corresponding to the end_date value in the healthdb_secure.sqlite database.
• count – the number of Steps, provided directly as an integer value without the need for additional SQL functions or calculations.
• distance – the Walking + Running Distance, also stored as integer values within the table.
• currentPace – the final column within this table; no analysis of currentPace was conducted for this study.

Notably, the Pednet History table did not contain data pertaining to Floors Ascended or Floors Descended.

The presence of the PednetHistory table is dependent on the iOS version and, when present, the data it contains is more limited in scope than that stored within the StepCountHistory table. In the dataset examined from the Apple iPhone SE, the StepCountHistory table contained 3,170 rows of data for Steps and Walking + Running Distance, spanning 6 days, 22 hours, 33 minutes, and 33 seconds. By contrast, the PednetHistory table contained 1,965 rows of data, covering a shorter duration of 1 day, 4 hours, 15 minutes, and 32 seconds.

Figure 13: Example of SQL query results for Steps data incorporating an ending timestamp from the PednetHistory table of an Apple iPhone running iOS 26.0, viewed using DB Browser. The id, starting timestamp, steps count values originate from the StepCountHistory table, while the Timestamp Source column indicates the ending timestamp is derived from the PednetHistory table.

When present, the PednetHistory table can be used to obtain ending timestamps for granular analyses of Steps and Walking + Running Distance. This data also enables verification of derived ending timestamps from the StepCountHistory table for activity records that fall outside the temporal coverage of the PednetHistory table.

Figure 14: Example of SQL query results for Steps data deriving an ending timestamp from the StepCountHistory table of an Apple iPhone running iOS 26.0, viewed using DB Browser. The Timestamp Source column indicates the ending timestamp is derived from the StepCountHistory table.

Because Steps, Walking + Running Distance, and Floors Ascended / Descended data do not overlap other data measurements within the StepCountHistory table, a working ending timestamp can be derived using the next available starting timestamp. As shown in Figures 13 and 14, this approach produces consistent beginning and ending timestamps, with only minor variation at the sub-second level. A ‘Timestamp Source’ column was included to explicitly document whether an ending timestamp originated from the PednetHistory table or was derived from the StepCountHistory, ensuring transparency in timestamp attribution.

Analysis revealed that ending timestamp behavior for Floors Ascended and Floors Descended differs from that of Steps and Walking + Running Distance within the cache_encryptedC.db. Although the smallest recorded value for Steps was 1 and was approximately 0.46 m for Walking + Running Distance, the smallest value for Flights Ascended (1) is not directly comparable. Apple defines a single flight as approximately 3 meters of elevation gain, indicating a substantially larger movement threshold is required to trigger recording. This distinction may account for the change in timestamp calculations for Floors Ascended / Descended data.

For Steps and Walking + Running Distance, the starting timestamp is obtained from the startTime column, and a LEAD-based approach is used to derive the ending timestamp from the subsequent row. In contrast, Floors Ascended and Floors Descended require a LAG-based approach, where the starting timestamp of the preceding row is used to establish the effective beginning of the interval and the current startTime serves as the derived ending timestamp.

Figure 15: Example of SQL query results for Floors Ascended data from the cache_encryptedC.db database of an Apple iPhone running iOS 26.0, viewed using DB Browser. The figure displays the record ID, derived starting and ending timestamps, a single recorded Floor Ascended, no corresponding Floors Descended (NULL), and the calculated duration derived based on the timestamp interval.

Using this logic, the derived starting and ending timestamps match those recorded in the healthdb_secure.sqlite data for the corresponding movement, as depicted in Figure 5.

Testing for Steps and Walking + Running Distance:

Doughboy Stadium, located on Fort Benning, Georgia, was selected as the testing location due to its unobstructed, flat environment and the presence of fixed, known distances that allow for precise determination of starting and stopping points.  

While the field configuration may vary seasonally to accommodate athletic and recreational activities, the stadium includes permanent American football yard markers integrated into the stadium seating, providing consistent and repeatable distance references for testing.

Figure 16: Overview of Steps and Walking + Running Distance testing area at Doughboy Stadium, as visualized using Google Earth. The figure illustrates the fixed walking path used for repeated trials (highlighted in yellow) and the total measured distance.

The yard markers span 100 yards, or 91.44 meters, and were measured for accuracy prior to the initiation of testing. As depicted in Figure 16 by the highlighted yellow path, a straight walking route was established by maintaining alignment with the yard markers throughout each trial.

A non-test device was used to capture start and stop timestamps for all testing iterations. The website http://www.timeanddate.com was used to establish a known good local time standard, against which the times displayed on the testing devices were compared and incorporated into timestamp conversions for subsequent statistical analysis (timeanddate.com, 2026).

The defined testing path was walked ten times, with all steps counted for each iteration. A six-minute interval was maintained between the start of each walk. During the first five iterations, the Apple iPhone SE was within the right pant pocket and the Apple iPhone 8 in the left pant pocket. During the final five iterations, the Apple iPhone SE was carried in the right hand and the Apple iPhone 8 in the left hand. When carried in hand, a natural arm swing was maintained throughout each walk. A FFS Extraction of each device was obtained upon completion of all testing.

Figure 17: Steps and Walking + Running Distance testing records for each walking iteration, showing recorded starting and ending timestamps and the corresponding Steps and distance values.

Apple iPhone 8, iOS 15.0.2, Steps Results:

Steps data from the healthdb_secure.sqlite database revealed that walking iterations were aggregated, with iterations 1 and 2 combined, as well as 3 and 4, 5 and 6, 7 and 8, and 9 and 10.

Figure 18: Steps data recorded in the healthdb_secure.sqlite database for an Apple iPhone 8 running iOS 15.0.2, illustrating the aggregation of walking iterations and the associated starting and ending timestamps for recorded Steps.

Comparison of recorded timestamps to the known good local time revealed a consistent delay in both starting and ending timestamps. Recorded starting times were, on average, 26.8 seconds behind the known start time, while recorded ending times were delayed by an average of 22.4 seconds. Aggregating walking iterations for comparison against the healthdb_secure.sqlite data yields the following results.

Figure 19: Comparison of known Step counts to Steps recorded in the healthdb_secure.sqlite database for aggregated walking iterations on an Apple iPhone 8 (iOS 15.0.2).

Actual steps taken were consistent across all five walking iterations and their combined groupings. As shown in Figure 19, recorded Steps reflect this same general consistency when aggregated. Step counts derived from the healthdb_secure.sqlite database were slightly lower when the devices were carried in pant pockets and slightly higher when held in hand with natural arm swing. The largest observed discrepancy occurred during iterations 5 and 6, where 246 known Steps corresponded to 239 recorded Steps.

By contrast, Steps data from the cache_encryptedC.db database revealed that walking iterations were not aggregated and were instead recorded in much shorter temporal segments, typically spanning approximately 2.5 seconds. Examination of Iteration 1 illustrates this increased temporal granularity:

Figure 20: Example of Steps data from the cache_encryptedC.db database for Iteration 1 on an Apple iPhone 8 (iOS 15.0.2), showing Steps recorded in discrete temporal segments of approximately 2.5 seconds.

Iteration 1 consisted of 25 rows of data. Each subsequent iteration contained 26, 27, 26, 26, 25, 27, 27, 26, and 24 rows, respectively. Reviewing the recorded starting times, derived ending times, and Steps values from the cache_encryptedC.db in comparison to known Steps yields the following results:

Figure 21: Comparison of recorded Steps values derived from the cache_encryptedC.db database and known Steps counts for each walking iteration on an Apple iPhone 8 (iOS 15.0.2).

To provide a clearer visual comparison of recorded and known Steps counts across iterations, this same data is visualized in Figure 22.

Figure 22: Graphical representation of recorded Steps values derived from the cache_encryptedC.db database compared to known Steps counts for each walking iteration on an Apple iPhone 8 (iOS 15.0.2).

The granular data recorded within the cache_encryptedC.db allows for a direct comparison between known Steps taken and the corresponding activity data stored within the database. While the cache_encryptedC.db provides substantially higher temporal granularity – with Steps recorded over average intervals of approximately 2.5 seconds compared to aggregated intervals of approximately 7 minutes and 6 seconds – the total number of Steps remains consistent between the databases, as shown in the following figure.

Figure 23: Comparison of total Steps values recorded in the healthdb_secure.sqlite and cache_encryptedC.db databases for the walking iterations on an Apple iPhone 8 (iOS 15.0.2).

Across all walking iterations, the total number of Steps recorded is consistent between the healthdb_secure.sqlite and cache_encryptedC.db databases, as are the beginning and ending timestamps for aggregated activity groups.

Apple iPhone SE (2^nd Gen), iOS 26.0, Steps Results:

Steps data from the healthdb_secure.sqlite database on iOS 26 revealed that walking iterations were aggregated in the same paired manner (iterations 1-2, 3-4, 5-6, 7-8, and 9-10). However, unlike the iOS 15.0.2 dataset, the aggregated data for each paired iteration was stored across multiple rows (i.e., 23 and 225, 46 and 200).

Figure 24: Steps data recorded in the healthdb_secure.sqlite database for an Apple iPhone SE (2nd Gen) running iOS 26.0, illustrating aggregation of walking iterations and the distribution of aggregated values across multiple rows.

Aggregating walking iterations for comparison against the healthdb_secure.sqlite data yields the following results:

Figure 25: Graphical comparison of recorded Steps counts derived from the healthdb_secure.sqlite database and known Steps counts for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

As shown in Figure 25, recorded Steps counts derived from the healthdb_secure.sqlite database generally exceeded the known Steps counts across most walking iterations. Differences ranged from two additional steps (iterations 1 and 2) to six additional steps (iterations 7 and 8). By contrast, iterations 5 and 6 exhibited an under recorded of three steps relative to the known counts.

Iterations 1 – 10 consisted of 26, 28, 28, 27, 26, 26, 26, 26, 28, and 27 rows of data, respectively. Reviewing the recorded starting timestamps, derived ending timestamps, and Steps counts from the cache_encryptedC.db allows for examination of the same walking iterations at a more granular temporal resolution, as shown in the following figure.

Figure 26: Comparison of recorded Steps values derived from the cache_encryptedC.db database and known Steps counts for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

To provide a clearer visual comparison of recorded and known Steps counts across walking iterations, this same data is visualized in the following figure.

Figure 27: Graphical comparison of recorded Steps values derived from the cache_encryptedC.db database and known Steps counts for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

The more granular view provided by the cache_encryptedC.db reveals differences between recorded and known Steps counts generally ranging from +3 to -2 Steps, with a potential outlier observed for iteration 7, were recorded Steps exceeded the known count by eight steps.

Notably, the iOS 26.0 dataset exhibited exact matches for both timestamps and Steps counts between the StepCountHistory and PednetHistory tables across all ten walking iterations.

When comparing the healthdb_secure.sqlite and cache_encryptedC.db databases, recorded Steps counts and the beginning and ending timestamps of aggregated activity groups were consistent across both data sources, as shown in Figure 28.

Figure 28: Comparison of total Steps values recorded in the healthdb_secure.sqlite and cache_encryptedC.db databases across all walking iterations on an Apple iPhone SE (2nd Gen) running iOS 26.0. The higher granularity of the cache_encryptedC.db data allowed for aligned aggregation, enabling direct comparison of recorded Steps totals and corresponding beginning and ending timestamps.

Steps Findings:

Figures 29 and 30 present a summarized view of step count accuracy for each test device across all walking trials. Figure 29 illustrates the results for the Apple iPhone 8 running iOS 15.0.2, while Figure 30 depicts the corresponding results for the Apple iPhone SE (2nd Gen) running iOS 26.0. Each figure compares recorded step counts against known values under two placement conditions: device carried in a pant pocket and device held in hand.

Figure 29: Device‑specific Steps accuracy summary for Apple iPhone 8 (iOS 15.0.2)

As shown in Figure 29, the Apple iPhone 8 demonstrated consistently reliable step recording across all trials, with observed errors remaining within a narrow range. A slight undercounting bias was observed overall, particularly when the device was carried in a pant pocket. When held in hand, recorded step counts more closely aligned with known values, indicating reduced measurement variance under more stable device orientation.

Figure 30: Device‑specific Steps accuracy summary for Apple iPhone SE (2nd Gen, iOS 26.0)

Similarly, Figure 30 shows that the Apple iPhone SE (2nd Gen) also produced step counts closely aligned with known Steps. In contrast to the iPhone 8, this device exhibited a slight overcounting tendency across most trials. The effect of device placement was again evident, although less pronounced, with hand‑held measurements showing marginally greater deviation from the known step counts than pocket‑based measurements for this device.

Figure 31: A comparative synthesis across both devices and conditions (overall error, bias direction, placement effects)

Figure 31 consolidates the results from both devices into a comparative overview, highlighting overall accuracy trends and measurement bias. Across all conditions, both devices remained within approximately +/- 1% of known step counts, indicating high reliability of Apple Health Steps data regardless of database source. While the cache_encryptedC.db provided substantially greater temporal granularity, the aggregated step totals recorded in the healthdb_secure.sqlite database remained consistent and accurate.

Taken together, the results shown in Figures 29 through 31 indicate that Steps data is robust across device models, iOS versions, and carry conditions. Minor differences in bias direction were observed between devices, and device placement had a measurable but limited influence on step count accuracy. Importantly, no loss of measurement accuracy was attributable to data aggregation within the healthdb_secure.sqlite database, supporting the forensic reliability of both data sources for step‑based activity reconstruction.

Apple iPhone 8, iOS 15.0.2, Walking + Running Distance Results:

Walking + Running Distance data from the healthdb_secure.sqlite database revealed that walking iterations were aggregated in the same paired manner observed for Steps, with iterations 1-2, 3-4, 5-6, 7-8, and 9-10 combined. This aggregation behavior is consistent with the close relationship between Steps and Walking + Running Distance measurements, which are typically recorded concurrently during walking activity.

Figure 32: Walking + Running Distance data recorded in the healthdb_secure.sqlite database for an Apple iPhone 8 running iOS 15.0.2, illustrating aggregation of walking iterations into paired activity groups and the associated starting and ending timestamps with total recorded distance values.

Aggregating walking iterations for comparison against the healthdb_secure.sqlite Walking + Running Distance data yields the following results:

Figure 33: Graphical comparison of known Walking + Running Distance values and distances recorded in the healthdb_secure.sqlite database for aggregated walking iterations on an Apple iPhone 8 running iOS 15.0.2.

As shown in Figure 33, distances recorded in the healthdb_secure.sqlite database consistently undercalculated the known distance when the devices were carried in pant pockets. When devices were held in hands, recorded distances more closely approximated the actual distance, though slight overcalculation was observed in the final iterations.

Walking + Running Distance data from the cache_encryptedC.db database, consistent with Steps data, revealed that walking iterations not only were not aggregated and were instead recorded in discrete temporal segments of approximately 2.5 seconds. Examination of the data from iteration 1 illustrates this increased temporal granularity:

Figure 34: Example of Walking + Running Distance data recorded in the cache_encryptedC.db databases for iteration 1 on an Apple iPhone 8 running iOS 15.0.2, showing distance recorded in discrete temporal segments.

Consistent with Steps data, Walking + Running Distance records in the cache_encryptedC.db database were stored across multiple rows, with iterations 1 through 10 consisting of 25, 26, 27, 26, 26, 25, 27, 27, 26, and 24 rows of data, respectively. Reviewing the recorded starting times, derived ending times, and Walking + Running Distance values from the cache_encryptedC.db allows for examination of the same walking iterations at a more granular temporal resolution, as shown in the following figure.

Figure 35: Walking + Running Distance data recorded in the cache_encryptedC.db database for the Apple iPhone 8 running iOS 15.0.2, showing calculated distance values with corresponding starting and derived ending timestamps across discrete temporal segments for individual walking iterations.

To provide a clearer visual comparison of recorded and known Walking + Running Distance values across walking iterations, this same data is visualized in the following figure.

Figure 36: Graphical comparison of recorded Walking + Running Distance values from the cache_encryptedC.db database and known distances for each walking iteration on an Apple iPhone 8 running iOS 15.0.2.

As shown in Figure 36, distances recorded in the cache_encryptedC.db database consistently undercalculated the known distance when the devices were carried in pant pockets. When the devices were held in hand, recorded values more closely approximated the known distance, with slight overcalculation observed during iterations 7, 8, and 9.  

While the cache_encryptedC.db provided substantially higher temporal granularity, the aggregated Walking + Running Distance totals correspond directly with those recorded in the healthdb_secure.sqlite database, shown in the following figure.

Figure 37: Comparison of aggregated Walking + Running Distance totals recorded in the healthdb_secure.sqlite and cache_encryptedC.db databases across all walking iterations on an Apple iPhone 8 running iOS 15.0.2.

Apple iPhone SE (2^nd Gen), iOS 26.0, Walking + Running Distance Results:

Walking + Running Distance data from the healthdb_secure.sqlite database on iOS 26 revealed that walking iterations were aggregated in the same paired manner (iterations 1-2, 3-4, 5-6, 7-8, and 9-10). However, unlike the iOS 15.0.2 dataset, the aggregated distance values for each paired iteration were stored across multiple rows (i.e., 13.759 m and 141.226 m; 29.017 m and 124.526 m).

Figure 38: Walking + Running Distance recorded in the healthdb_secure.sqlite database for an Apple iPhone SE (2nd Gen) running iOS 26.0, illustrating aggregation of walking iterations and the distribution of aggregated values across multiple rows. Combined Values rows were added to aid the comparison of the recorded aggregated values against the known distance.

Aggregating walking iterations for comparison against the healthdb_secure.sqlite data yields the following results:

Figure 39: Graphical comparison of recorded Walking + Running Distance derived from the healthdb_secure.sqlite database and known distance for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

As shown in Figure 39, distances recorded in the healthdb_secure.sqlite database consistently undercalculated the known distance when the devices were carried in pant pockets, most notably for iterations 1-2 and 3-4. When devices were held in hand, recorded distances more closely approximated the actual distance, seen for iterations 7-8 and 9-10.

Iterations 1 – 10 consisted of 26, 28, 28, 27, 26, 26, 26, 26, 28, and 27 rows of data, respectively. Reviewing the recorded starting timestamps, derived ending timestamps, and Walking + Running Distance from the cache_encryptedC.db allows for examination of the same walking iterations at a more granular temporal resolution, as shown in the following figure.

Figure 40: Comparison of recorded Walking + Running Distance values derived from the cache_encryptedC.db database and known distance for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

To provide a clearer visual comparison of recorded and known distance across walking iterations, this same data is visualized in the following figure.

Figure 41: Graphical comparison of recorded Walking + Running Distance values derived from the cache_encryptedC.db database and known distance for each walking iteration on an Apple iPhone SE (2nd Gen) running iOS 26.0.

As shown in Figure 41, the more granular view provided by the cache_encryptedC.db database reveals differences between the known distance and recorded Walking + Running Distance clearer than that of the healthdb_secure.sqlite database. Iterations 1-5 consistently undercalculated the known distance when the devices were carried in pant pockets. When devices were held in hands, recorded distances more closely approximated the actual distance, seen especially for iterations 7-10.

The iOS 26.0 dataset exhibited exact matches for both timestamps and Walking + Running Distance values between the StepCountHistory and PednetHistory tables across all ten walking iterations.

When comparing the healthdb_secure.sqlite and cache_encryptedC.db databases, recorded distances and the beginning and ending timestamps of aggregated activity groups were consistent across both data sources, as shown in Figure 42.

Figure 42: Comparison of total Walking + Running Distance values recorded in the healthdb_secure.sqlite and cache_encryptedC.db databases across all walking iterations on an Apple iPhone SE (2nd Gen) running iOS 26.0.

Walking + Running Distance Findings:

Figures 43 and 44 present a summarized view of Walking + Running Distance accuracy for each test device across all walking trials. Figure 43 illustrates the results for the Apple iPhone 8 running iOS 15.0.2, while Figure 44 depicts the corresponding results for the Apple iPhone SE (2nd Gen) running iOS 26.0. Each figure compares recorded distance values against known distances under two placement conditions: device carried in a pant pocket and device held in hand.

Figure 43: Device‑specific Walking + Running Distance accuracy summary for Apple iPhone 8 (iOS 15.0.2)

As shown in Figure 43, the Apple iPhone 8 demonstrated unreliable distance recording across the first five iterations when the device was carried in a pant pocket. Overall, recorded distance values were undercalculated by -22.03% relative to the known distance. When the device was held in hand, recorded distances showed improved agreement with known values, with a slight overcalculation of +2.56%.

Figure 44: Device‑specific Walking + Running Distance accuracy summary for Apple iPhone SE (2nd Gen, iOS 26.0)

Similarly, Figure 44 illustrates that the Apple iPhone SE also demonstrated unreliable distance recording across the first five iterations when the device was carried in a pant pocket. Overall, recorded distance values were undercalculated by an average of -15.75% compared to the known distance. When the device was held in hand, recorded distances again showed improved agreement, with a slight undercalculation of -1.43%.

Figure 45: A comparative synthesis across both devices and conditions (overall error, bias direction, placement effects)

Figure 45 consolidates the results from both devices into a comparative overview, highlighting overall accuracy trends and measurement bias. Similar to Steps data, Walking + Running Distance values were consistent across database sources, indicating no observable loss of aggregate distance measurement due to data aggregation. Overall, both devices exhibited a tendency to underestimate total distance, with average errors of -9.73% (Apple iPhone 8) and -8.59% (Apple iPhone SE).

Device placement had a pronounced impact on distance accuracy. When carried in a pant pocket, both devices showed substantial underestimation – -22.03% for the Apple iPhone 8 and -15.75% for the Apple iPhone SE – suggesting a systematic limitation in distance estimation under less stable device orientation. When held in the hand, both devices demonstrated significantly improved accuracy: the Apple iPhone 8 exhibited a slight overestimation (+2.56%), while the Apple iPhone SE showed a slight underestimation (-1.43%).

Across all trials, distance estimation was notably less accurate than step counting, particularly when the device was carried in the pocket. However, when held in the hand, both devices produced Walking + Running Distance measurements within a few percentage points of actual distance. These findings indicate that device placement is a primary factor influencing distance accuracy and that, while both devices perform similarly overall, they exhibit different bias tendencies under comparable conditions. Unlike step counting – which remained consistently accurate across conditions – distance estimation showed significant sensitivity to device placement, with pocket-based measurements introducing substantial systematic underestimation.

Testing for Flights Ascended and Flights Descended:

As with prior testing, Doughboy Stadium was selected for Flights Ascended and Flights Descended analysis. A fixed flight of stadium stairs was used due to its proximity to the Steps and Walking + Running Distance testing areas and its permanent structure, allowing for repeatable and controlled movement testing.

Figure 46: Overview of Flights Ascended / Flights Descended testing area at Doughboy Stadium, as visualized using Google Earth.

Figure 47: Measurements of Stadium Stairs.

Each stair was measured for both height and width, and the values were recorded. The total elevation change from the base of the stairs to the top was 3.60 m. Based on Apple’s definition of Flights Climbed, this elevation change was expected to be recorded as a single flight.

The flight of stairs was ascended four times and descended four times, with a five-minute interval between the start of each movement. During the first two ascent and descent trials, the Apple iPhone SE was carried in the right pant pocket and the Apple iPhone 8 in the left pant pocket. During the final two ascent and descent trials, the Apple iPhone SE was in the right hand and the Apple iPhone 8 in the left hand. When carried in the hand, a natural slight arm swing was maintained throughout movement.

Figure 48: Floors Ascended / Floors Descended Testing Records.

Apple iPhone 8, iOS 15.0.2, Flights Climbed Results:

Flights Climbed data from the healthdb_secure.sqlite database indicated movement was recorded only for Flights Climbed, corresponding to Floors Ascended. No data was present for Floors Descended. Of the four Flights Climbed movements, two were aggregated, while the remaining two were recorded as individual events.

Figure 49: Flights Climbed data from the healthdb_secure.sqlite database of an Apple iPhone 8 running iOS 15.0.2.

Analysis of the recorded timestamps indicated that starting times were delayed by an average of approximately 48 seconds relative to the known starting times, while recorded ending times were delayed by an average of approximately 34 seconds.

By contrast, Floors Ascended and Floors Descended data derived from the cache_encryptedC.db database provided substantially greater temporal precision and included explicit records of downward stair movement (Floors Descended), which were not present in the healthdb_secure.sqlite data.

Figure 50: Floors Ascended / Floors Descended data from the cache_encryptedC.db database of an Apple iPhone 8 running iOS 15.0.2.

Analysis of the cache_encryptedC.db records indicates that all stair movements were captured with more defined starting and ending timestamps than those observed in the healthdb_secure.sqlite database. Most recorded movement durations ranged between approximately 2.5 and 7.7 seconds. Two notable outliers were observed for the first two Floors Descended movements, with recorded durations of 4 minutes and 36 seconds and 4 minutes and 35 seconds, respectively.

The PednetHistory table did not contain data for Floors Ascended or Floors Descended. Correspondingly, beginning and ending timestamps for stair movement events did not align with any startTime or endTime values from the PednetHistory table, consistent with Floors Ascended / Descended not being supported within the table.

Apple iPhone SE (2^nd Gen), iOS 26.0, Flights Climbed Results:

Flights Climbed data from the healthdb_secure.sqlite database revealed that movement was, again, recorded only for Flights Climbed, corresponding with Floors Ascended. As observed in the prior dataset, two Flights Climbed movements were aggregated while the remaining two were recorded as individual events.

Figure 51: Flights Climbed data from the healthdb_secure.sqlite database of an Apple iPhone SE (2nd Gen) running iOS 26.0.

Review of Floors Ascended and Floors Descended data derived from the cache_encryptedC.db database again demonstrates greater temporal precision and includes explicit records of downward stair movement (Floors Descended), which are not present in the healthdb_secure.sqlite data, as shown in the following figure.

Figure 52: Floors Ascended / Floors Descended data from the cache_encryptedC.db database of an Apple iPhone SE (2nd Gen) running iOS 26.0.

All stair movements were recorded within the database with well-defined starting and ending timestamps. Recorded movement durations ranged between approximately 2.5 and 7.7 seconds, with no observed outliers.

Flights Climbed / Floors Ascended and Descended:

Floors Ascended and Floors Descended data were evaluated for both devices while being carried in the pant pocket and in the hand. Unlike Steps and Walking + Running Distance metrics, all ascent and descent events were correctly identified across all trials, resulting in 100% event detection accuracy within this sample. As a result, no percentage-based error analysis was performed, as no discrepancies were observed between recorded and actual event counts.

While event detection was consistent, differences were observed in the timing of recorded events. For the Apple iPhone 8, recorded start times were typically delayed by approximately 30–50 seconds relative to actual movement. Recorded end times for ascent events were generally close to the recorded start times; however, descent events occasionally exhibited significant delays, extending up to several minutes beyond the actual movement period. For the Apple iPhone SE, recorded start times were closer to actual movement, typically within 10–30 seconds, and recorded end times remained consistently aligned within a few seconds of the detected event. No meaningful differences in detection accuracy or timing behavior were observed between pocket and in-hand conditions, indicating that device placement has minimal impact on flight detection performance.

Across all trials, both devices demonstrated reliable detection of floor transitions, with no missed or incorrect events. The primary difference between devices was temporal precision, with the Apple iPhone SE providing more closely aligned timestamps relative to actual movement. These results indicate that while flight detection is robust across devices and conditions, timestamp accuracy may vary by device and implementation, particularly for descent events. Unlike Walking + Running Distance estimation – which showed significant sensitivity to device placement – flight detection remained consistent across conditions, with timing latency representing the primary source of variation.

Note on cache_encryptedC.db Timestamp Behavior:

Analysis of cache_encryptedC.db timestamps indicates that temporal precision is generally highest closer to the point of extraction. Even at the beginning of the available retention period (approximately six to seven days prior to extraction), timestamp values may vary when compared to those recorded in the healthdb_secure.sqlite database.

As discussed elsewhere in this study, the id column within the StepCountHistory table serves as the primary key and is implemented as an autoincrement value. This implementation enables reliable missing‑ID analysis. Within the interval from 2026‑04‑02 09:40:00 to 2026‑04‑03 17:34:08 (maximum observed startTime) of the Apple iPhone SE (2nd Gen), 4,104 rows were present with no missing IDs. Across the broader dataset, missing‑ID analysis identified 452 groups of missing rows, accounting for a total of 15,026 absent records.

Despite the presence of missing rows, the pairing of startTime values with associated count, distance, floorsAscended, and floorsDescended measurements remains reliable. However, when missing rows are present, the use of LEAD‑ or LAG‑based methods to derive ending timestamps may result in reconstructed time intervals that exceed the true duration of the underlying activity. In such cases, intermediate samples are absent, causing derived intervals to span longer periods.

As a result, while activity quantities (Steps, Walking + Running Distance, Floors Ascended, and Floors Descended) remain accurate overall, temporal precision may be reduced for affected records. These events should therefore be interpreted as representing activity over a broader reconstructed interval rather than the original finer‑grained sampling windows.

Conclusion:

Apple Health data, when properly interpreted, provides reliable and forensically useful information regarding user movement, particularly for Steps and floor transition events (Floors Ascended / Descended). This study empirically examined the accuracy, granularity, and database‑level behavior of Apple Health activity metrics across iOS versions and device models, with a specific focus on Steps, Walking + Running Distance, and Flights Climbed / Floors Ascended or Descended.

Key findings from this analysis include:

• Steps count data demonstrates high accuracy and consistency across devices, iOS versions, and carry conditions. Across all testing scenarios, recorded Steps counts remained within approximately +/- 1% of known values. Minor bias differences were observed between devices, but these differences were small and did not materially affect interpretive reliability.
• Data aggregation within the healthdb_secure.sqlite database does not result in a loss of measurement accuracy. While activity intervals may be aggregated over longer time spans, aggregated Steps, Walking + Running Distance, and Flights Climbed values remained consistent with those derived from the more granular cache_encryptedC.db records.
• The cache_encryptedC.db provides substantially greater temporal granularity but records equivalent activity quantities. Forensic value is gained through finer segmentation of activity events and improved alignment with movement timelines; however, total Steps, Walking + Running Distance, and Flights Climbed counts remain consistent across both databases when correctly derived.
• The method of deriving data is dependent on the iOS version. For Steps and Walking + Running Distance data, pre‑iOS 26 versions require a LEAD‑based approach when analyzing cache_encryptedC.db data, while iOS 26 and newer versions require a LAG‑based approach. Failure to apply the correct method may result in inaccurate activity reconstruction.
• Walking + Running Distance measurements are more sensitive to device placement than Steps. Pocket‑based measurements exhibited systematic underestimation of Walking + Running Distance, while hand‑held measurements produced substantially improved accuracy. These placement effects should be considered if interpreting Walking + Running Distance metrics in isolation.
• Floors Ascended and Descended events were reliably detected across all trials from the cache_encryptedC.db database. Event detection accuracy was consistent regardless of device model or device carrying placement.
• Steps and Walking + Running Distance events should not be interpreted interchangeably. Steps demonstrated the highest reliability across conditions, while Walking + Running Distance estimation and precision exhibited greater sensitivity to orientation, sampling gaps, and database behavior.
• Caveat: This analysis was conducted by comparing Apple Health database records against known, controlled movements under defined testing conditions. The observed consistency, accuracy ranges (+/- 1% for steps), and database behaviors therefore reflect how the system responds to verifiable activity. It does not imply that every entry in the database will always be perfectly accurate in real-world use. Device movements may occasionally be over- or under- interpreted (recording activity that was not fully completed to the expected degree), and some physical movements may go unrecorded altogether (for example, working on the 5^th floor and comparing known elevator usage to a lack of registered Floors Ascended /Descended data).

Taken together, these findings support the forensic reliability of Apple Health data when interpreted with proper attention to database structure, iOS version behavior, and contextual limitations. When combined with additional artifacts – such as location data, system logs, and application usage artifacts – Apple Health data can meaningfully contribute to accurate activity and timeline reconstruction in digital forensic examinations.

Software Support Note:

The cache_encryptedC.db artifacts described in this work are supported by the freely available digital forensic software HEART by Metadata Forensics (Health Events and Activity Reporting Tool), developed by Metadata Forensics, LLC. At the time of this study, HEART by Metadata Forensics Version 1.4.0.0 included support for parsing and interpreting cache_encryptedC.db data consistent with the artifact behavior and derivation methods described herein. HEART by Metadata Forensics is publicly available at: https://github.com/MetadataForensics/HEART_by_Metadata_Forensics

Acknowledgements:

The author acknowledges and appreciates the work of Ian Whiffin and Apple Health Accuracy & Reliability, whose research brought this subject to light and provided a solid analytical foundation. The incorporation of iOS 26 as an additional dataset enables further insights, extending the scope of the original work while supporting its conclusions.

References:

Apple Inc. (n.d.). HKQuantityTypeIdentifier. Apple Developer Documentation. Retrieved April 24, 2026, from https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifier

Apple Inc. (n.d.). PushCount. Apple Developer Documentation. Retrieved April 24, 2026, from https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifier/pushcount

Apple Inc. (n.d.). Step count definition from HealthApp.sqlite database [Mobile application data]. Apple Health (iOS).

BBC News. (2018, January 12). Apple Health data used in murder trial. https://www.bbc.com/news/technology-42663297

Czajkowski, B. (2026, January 26). Karen Read murder trial: How Apple Health data played a role. A&E. https://www.aetv.com/articles/karen-read-trial-apple-health-data

Digital Corpora. (n.d.-a). iOS 13.3.1 forensic images [Dataset]. AWS S3 Explorer. https://digitalcorpora.s3.amazonaws.com/s3_browser.html#corpora/mobile/ios_13_3_1/

Digital Corpora. (n.d.-b). iOS 16 forensic images [Dataset]. AWS S3 Explorer. https://digitalcorpora.s3.amazonaws.com/s3_browser.html#corpora/mobile/iOS16/

Digital Corpora. (n.d.-c). iOS 17 forensic images [Dataset]. AWS S3 Explorer. https://digitalcorpora.s3.amazonaws.com/s3_browser.html#corpora/mobile/iOS17/

DoubleBlak. (n.d.). Apple Health accuracy & reliability. https://www.doubleblak.com/blogPost.php?k=healthaccuracy

Google LLC. (n.d.). Google Earth [Satellite imagery of Doughboy Stadium, Fort Benning, GA]. Retrieved April 2026.

The Trial Channel. (2025, October 3). Murdaugh trial (Pt. 13.1): Lt. Britt Dove (SLED) — Maggie’s iPhone [Video]. YouTube. https://www.youtube.com/watch?v=LzvVJ2ec3ic

timeanddate.com. (2026, April 23). Timeanddate.com. https://www.timeanddate.com/