Test Apple Health Permission Revocation Across the iOS App Lifecycle

OpenAI published 'Launching Health in ChatGPT' on July 23, 2026, announcing a feature that lets eligible US users age 18+ connect Apple Health and medical-record data on web and iOS. The company states that connected data and relevant conversations are not used to train foundation models or target ads. A proposed test matrix outlines expected behaviors for permission revocation across the iOS app lifecycle, emphasizing that stale data must be labeled before any new read and that reconnection requires a new consent receipt.

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 https://openai.com/index/health-in-chatgpt/ for those statements; it does not supply the test results below. 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 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. 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. 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 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. | 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. 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.