DEV Community

Test Apple Health Permission Revocation Across the iOS App Lifecycle

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.

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

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

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.

Comments

No comments yet. Start the discussion.