Start with one device and one transition: permission is available, the app enters the background, the person changes access, and the app returns to the foreground. The product must not present previously displayed information as freshly synchronized. This is a lifecycle test, not a claim about any current app’s behavior.
OpenAI published “Launching Health in ChatGPT” on July 23, 2026. OpenAI says Health in ChatGPT is rolling out to eligible logged-in US users age 18+ on web and iOS, and lists supported Apple Health and medical-record connections. It says the dashboard can cover labs, medications, activity, sleep, and other health information. OpenAI also states that connected data and relevant conversations are not used to train foundation models or target ads. Consult the exact primary source for those statements; it does not supply the test results below.
Declare the device envelope
Before execution, fill this in rather than writing “tested on iPhone”:
device_model: TBD
os_version: TBD
app_build: TBD
account_region_and_eligibility: TBD
connection_type: wifi | cellular | offline
power_state: charging | battery_percentage
initial_app_state: foreground | background | terminated
initial_permission_scope: document exact categories
sample_data: synthetic_or_preapproved
Enter fullscreen mode Exit fullscreen mode
Do not infer availability from the announcement. Confirm that the account is eligible and that the tested connection is actually offered before beginning. Use synthetic or specifically approved data where the platform and test environment allow it; never add someone else’s records merely to populate a screen.
Permission and revocation matrix
This is a proposed, unexecuted matrix. “Expected” means desired product behavior, not observed iOS or ChatGPT behavior.
| Start | Transition | Network | Expected observation | Recovery |
|---|---|---|---|---|
| foreground, access available | change access, return | Wi-Fi | refresh authorization state; mark old view stale | explain reconnect path |
| background sync pending | change access before resume | Wi-Fi | pending read must not gain broader scope | cancel or re-authorize |
| terminated | change access, relaunch | cellular | startup rechecks state before refresh | preserve navigation context |
| foreground | disconnect product connection | offline | local UI records intent; no false completion | reconcile when online |
| disconnected | attempt reconnect | Wi-Fi | require a new explicit review | show requested categories |
| access available | device locks during refresh | Wi-Fi | no sensitive content in unsafe surfaces | resume deliberately |
For each row, record timestamps for user action, app state change, authorization recheck, request start, request finish, and visible freshness label. Capture whether the operation recovered, restarted, was denied, or silently disappeared. Do not invent latency or battery numbers; measure them on the declared setup if they matter.
Assertions worth automating at the application seam
GIVEN displayed data from sync version 12
WHEN lifecycle resume reports changed authorization
THEN version 12 is labeled stale before any new read
AND no queued task may expand its category set
AND reconnect creates a new consent receipt
Enter fullscreen mode Exit fullscreen mode
Keep OS permission status, product connection status, and data freshness as separate states. They may change at different times. A green “Connected” badge should not imply that every category is authorized, that data is current, or that a background task succeeded.
Manual evidence sheet
| Field | Record |
|---|---|
| test case ID | stable name from matrix |
| device/app state | before and after |
| requested categories | exact, no health values |
| visible status text | verbatim UI copy |
| operation outcome | recovered/restarted/denied/lost |
| privacy check | lock screen, app switcher, logs |
| cleanup | connection revoked; fixture removed |
Screenshots and screen recordings can themselves contain sensitive information. Redact them before sharing, minimize retention, and confirm that app-switcher snapshots, notifications, and logs do not reveal content.
Limits and release gate
This plan does not describe Apple Health internals, undocumented APIs, availability, or exact authorization semantics. It makes no security, compliance, battery, performance, or clinical claim. Results from one device and OS build do not generalize; rerun meaningful lifecycle rows across supported versions and connection states.
OpenAI says its health experience is designed to support rather than replace medical care, and not diagnosis or treatment. A passing mobile lifecycle matrix only demonstrates expected permission and recovery behavior in the tested envelope. Release should stop if revocation can leave a queued broader read, stale data appears current, reconnect bypasses review, or sensitive content reaches logs or system surfaces.
AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.