Apple provides an Export All Health Data action in the Health app. Its user guide describes the output as XML, a common exchange format between apps. That export is useful for personal archiving and analysis, but a large file is not automatically a clean research dataset.

This guide explains a defensible workflow without showing real health records. Exact elements can vary with iOS version, enabled features, contributing apps, devices, and the categories a person has accumulated, so inspect the file you actually received before writing a parser around assumptions.

At a glance

What to keep in view

  • Treat the export as sensitive source data, not a convenient sample file to upload anywhere.
  • Preserve timestamps, units, source names, and record identifiers before calculating summaries.
  • Separate an absent record from a recorded zero and a parser failure.
  • Document deduplication, timezone, aggregation, and completeness decisions with every result.

Create the export and protect the original

Apple's documented route is Health, Summary, the profile picture or initials, then Export All Health Data. The person chooses how to share the generated export. Menu wording can change, so Apple's current guide is the authority for the UI sequence.

The archive may reveal intimate longitudinal information. Store the untouched archive in an access-controlled location, work from a copy, and avoid consumer upload services unless their data handling is understood and intentionally accepted. A useful analysis does not require publishing the raw archive or a screenshot of identifiable records.

  • Record the export date, iOS version, and analysis-tool version.
  • Keep an immutable original and hash it if reproducibility matters.
  • Use synthetic or aggressively minimized fixtures for development and demonstrations.

Inventory before you aggregate

An XML document represents nested elements and attributes. A parser should first inventory element names, health-data type identifiers, units, sources, devices, start and end times, and any metadata that is present. Do not assume every category uses the same shape or that every value is a simple scalar.

Health data can be contributed by more than one app or device. Overlapping intervals and repeated-looking records therefore need provenance-aware review. Removing duplicates only because timestamps or values match can erase legitimate observations; keeping every row without checking identifiers can also inflate totals.

  • Count records by type, unit, source, and calendar period before transformation.
  • Validate timestamp parsing and timezone handling around travel and daylight-saving changes.
  • Quarantine unknown types instead of silently dropping them.

What the export can and cannot establish

The export can support questions about the records present: coverage by day, values over time, contributing sources, and transparent aggregates. It cannot prove that an unrecorded event did not happen. A blank period may reflect device wear, permissions, charging, sync behavior, feature setup, or collection conditions.

A measurement and an interpretation are different layers. Daily sums, averages, medians, or trends depend on a declared method. A further statement about readiness, illness, or cause requires evidence the XML itself does not provide. Keep those layers separate in tables, charts, and prose.

  • Label missing, zero, stale, and excluded records as distinct states.
  • Report the denominator and coverage window for every percentage or average.
  • Avoid diagnosis, universal normal ranges, and causal claims from an export alone.

A small reproducible analysis pipeline

A practical pipeline has five visible stages: preserve, inventory, normalize, validate, and summarize. Each stage should produce a compact audit artifact such as a hash, schema inventory, rejected-row log, coverage table, or calculation definition. This makes an attractive chart traceable back to its inputs.

Start with a narrow question and the minimum necessary types. For example, a coverage report needs dates, source, and expected observation logic before it needs a sophisticated model. Expanding the question after the basic data contract passes is safer than treating the entire archive as analysis-ready.

Use boundary

Information, not medical advice

This article explains data and research methods. It does not diagnose a condition, prescribe treatment, establish a universal normal range, or replace qualified professional care. If symptoms or a medical decision concern you, use an appropriate clinical service.