DEXA Scan Body Fat 3D Visualizer UI for iOS Apps

A DEXA body fat visualizer renders the user’s body composition as a rotatable 3D model, colors each region by its fat percentage, and shows the numbers and trends beside it. On iOS the pragmatic build is a segmented body mesh in SceneKit with a material per region, the metrics in a panel, and a Swift Charts trend across scans, fed by data the user enters or imports from their DEXA report. It is a way to see results, not a medical device, so it should present the user’s own numbers and leave interpretation to a professional. The screen around the 3D view, the metrics panel, the region legend, and the scan history, is fastest to build from a free VP0 design with Claude Code or Cursor.

What a DEXA body fat visualizer needs to show

It needs to turn body-composition numbers into something a person can read at a glance, then let them go deeper. The core is a 3D body that the user can rotate, with regions, arms, legs, trunk, and the android and gynoid areas a DEXA report breaks out, colored by their fat percentage. Around it sit the headline metrics (total body fat percentage, lean mass) and a way to compare one scan to the next.

The data is the user’s, and that shapes the design. A DEXA scan is performed at a clinic, so your app is not measuring anything; it is visualizing results the person brings in. That means the experience should make manual entry painless, present the numbers clearly, and never imply a diagnosis. Apple exposes body fat percentage and lean mass as HealthKit types, so the headline figures can read from and write to Health, while the regional breakdown is custom data you store yourself.

SceneKit or RealityKit for the 3D body?

For a rotatable body model that is not in augmented reality, SceneKit is the simpler and usually better choice. It is built for exactly this kind of self-contained 3D scene, loading a mesh, assigning materials, and responding to a rotate gesture, without the AR session machinery RealityKit assumes. Here is how the realistic options compare.

Engine	Best for	AR support	Effort
SceneKit	A rotatable body model on screen	Limited	Low
RealityKit	Placing the body in AR space	Native	Higher
WebGL in a web view	Reusing an existing three.js model	Manual	Medium

SceneKit handles the common case, a body you spin with your finger, with the least code, as the SceneKit documentation shows. Choose RealityKit only if you genuinely want to place the body in the room in AR, since it adds capability you otherwise will not use. A WebGL model in a web view is worth it only when you already have a three.js body you want to reuse rather than rebuild.

Sourcing and segmenting the body mesh

The mesh is the asset that makes or breaks the feature, and it has to be segmented before colors mean anything. You want a body model where the regions a DEXA report covers, arms, legs, trunk, and the android and gynoid areas, are separate named nodes, because the heatmap recolors each node independently. A single fused mesh cannot show regional fat, so either source a model that is already segmented or split one in a 3D tool before importing.

Format and size matter for a smooth app. USDZ is the native choice for SceneKit and RealityKit and imports cleanly, and keeping the model low-poly enough to rotate at a steady frame rate beats chasing realism the screen does not need. Plan for body-type variants too: one neutral model is a fine start, but users will expect a body that roughly matches them, so design the data flow so the same region nodes work across whichever meshes you ship. The mesh is the one piece a design cannot hand you, so budget real time for getting it right.

Coloring the body by region

The visual payoff is a heatmap, so each region needs to be its own material you can recolor from data. Use a body mesh that is segmented into named nodes for the regions a DEXA report covers, then map each region’s fat percentage to a color on a gradient, for example trending toward blue near 10% and toward red past 35%, with a clear legend so the colors mean something. Because each region is a separate material, updating the visualization is just setting colors from the latest numbers.

Keep the mapping honest and readable. Pick a gradient that stays distinguishable, pair it with a legend and on-tap labels so a user can read the exact value rather than guess from a hue, and avoid implying that a color is a verdict. The 3D view shows where fat sits; the panel beside it carries the precise figures. Pairing the model with direct labels matters for accessibility too, since color alone is not enough for every user.

Getting the data in: DEXA reports and HealthKit

The data path has three options, and a good app offers at least two. Manual entry is the baseline: a clean form for total body fat, lean mass, and the regional values from the printed report. Importing is the convenience layer, parsing a PDF or CSV the user exports from their clinic, though formats vary by provider, so treat parsing as a helper with manual entry as the fallback. HealthKit is the third path for the headline figures, reading existing body fat and lean mass and writing new values back so other apps benefit.

The split matters because only some of the data has a home in HealthKit. Total body fat percentage and lean body mass map to standard HealthKit quantity types, so store those there and the user’s history stays consistent across apps. The regional breakdown has no standard type, so keep it in your own store keyed to each scan date. For the Health integration pattern itself, the HealthKit step counter template shows the permission and read flow you will reuse.

Showing trends across scans

A single scan is a snapshot; the value is the trend, so plan for a chart from the start. Swift Charts renders total body fat and lean mass over time with little code, and a simple line per metric across scan dates tells the user far more than one number. Let them tap a point to see that scan’s full breakdown, including the 3D view for that date.

Store each scan as a dated record with its metrics and regional values so the history is queryable. That record is what powers both the trend chart and the ability to compare two scans side by side, which is the comparison most people actually want. Keep the chart axes stable and labeled so a small real change does not look dramatic, and so progress reads honestly.

Designing the screen fast

The 3D view is your custom work, but everything around it is a known layout worth starting from a design. A complete screen has the 3D container, a metrics panel, a region legend, a scan selector or history, and the trend chart, arranged so the model has room to breathe without burying the numbers. Getting that balance right by hand takes iteration.

The VP0 library helps because each screen has a hidden source page an AI builder reads from a pasted link:

Build this iOS body composition screen in SwiftUI.
Read the layout and tokens from this VP0 source page: <pasted VP0 link>.
Embed a SceneKit view for the 3D body, add a metrics panel and a region
legend, and a Swift Charts trend below. Read body fat from HealthKit.

For the 3D interaction itself, the 3D product viewer with 360 spin and the 3D model viewer carousel cover the rotate-and-inspect gestures you will reuse for the body. VP0 gives you the screen and the panels; the body mesh, the SceneKit scene, and your data model are the parts you supply.

Keeping it a visualizer, not a diagnosis

The honest limitation is that this is a presentation of the user’s own data, and the app should say so. A visualizer can show where fat sits and how it changes, but it does not measure body composition, and it is not a substitute for clinical interpretation. Present the numbers the user provides, avoid health verdicts or risk labels, and point people to a qualified professional for what the results mean.

This framing is also the safer product. Apps that imply medical assessment invite both review scrutiny and user harm, while a clear visualizer of self-reported scan data is useful and appropriate. Keep claims to what the app actually does, show the data plainly, and let the trend speak for itself.

What to choose

For almost every DEXA visualizer, choose SceneKit for the 3D body, a material per region for the heatmap, HealthKit for the headline metrics, and Swift Charts for the trend, with manual entry plus optional report import for the data. Reserve RealityKit for a genuine AR feature and a web-view model only when you are reusing an existing three.js body. Keep the experience a clear presentation of the user’s own results, and test the rotate gesture and frame rate on a real device rather than the simulator, where 3D performance is not representative of what users will feel.

For the build, start the screen, the metrics panel, the legend, and the history from a free VP0 design, generate it with Claude Code or Cursor, and spend your effort on the segmented body model and a data layer that keeps each scan honest.

Frequently asked questions

How do I build a DEXA body fat 3D visualizer for iOS?

Render the body as a segmented mesh in SceneKit with a material per region, color each region from its fat percentage, and show the metrics and a Swift Charts trend beside it. Read total body fat and lean mass from HealthKit and store the regional breakdown yourself. Start the screen and panels from a free VP0 design and build them in SwiftUI with Claude Code or Cursor, then supply the body mesh and data model.

Should I use SceneKit or RealityKit for the 3D body model?

Use SceneKit for a body the user rotates on screen, since it is built for self-contained 3D scenes and needs the least code. Choose RealityKit only if you want to place the body in augmented reality, because it adds an AR session and capability you otherwise will not use. A WebGL model in a web view makes sense only when you already have a three.js body to reuse.

Can I read DEXA results from HealthKit?

You can read and write the headline figures. Total body fat percentage and lean body mass are standard HealthKit quantity types, so your app can pull existing values and write new ones. The regional breakdown that a DEXA report provides, such as arm, leg, and trunk fat, has no standard HealthKit type, so store that in your own data keyed to each scan date.

Is a body fat visualizer app considered a medical device?

Treat it as a visualizer, not a diagnostic tool, and design accordingly. Presenting a user’s own scan results and showing trends is generally fine, but implying medical assessment or risk invites both App Store scrutiny and user harm. Keep claims to what the app does, avoid health verdicts, and direct users to a professional for interpretation of their results.

Where can I get a free template for the body composition screen?

VP0 is a free iOS design library where each screen has an AI-readable source page, so you can browse a dashboard or detail layout, copy its link, and have Claude Code or Cursor build it in SwiftUI with a 3D container, metrics panel, legend, and trend chart. You supply the segmented body mesh and the data; the screen comes from the design.