Guideline 1.4 physical harm safety review checklist
Apps that influence real-world behavior need safety evidence. Reviewers need to see where advice stops and user judgment or professional help begins.
Map every harm scenario before submitting safety-sensitive features. Apple Guideline 1.4 addresses physical harm concerns. AppReviewReady interpretation: a safety app should show limits, fallback routes, and evidence near the feature, not only in Terms.
List real-world harm scenarios
Identify where the app could influence driving, workouts, medication, emergency response, navigation, machinery, weather decisions, self-defense, diet, medical triage, mental health, or child safety. Then define what the app will and will not claim.
A feature can be risky even without medical language if users may rely on it for urgent or physical decisions.
Limit claims to supported evidence
- Avoid emergency, diagnostic, guaranteed outcome, or professional-equivalent claims unless properly supported.
- Place warnings near the decision point, not only in Terms.
- Use conservative language for estimates, forecasts, recommendations, and scores.
- Provide manual override, stop, cancel, or seek-help paths.
- Document expert review, source data, or regulatory status where applicable.
Design fallback states for unsafe conditions
No network, stale data, denied permission, low battery, sensor error, wrong unit, poor GPS, or unavailable region should produce a safer message rather than confident guidance.
AppReviewReady interpretation: safety is a state machine. The app must know when not to advise the user.
Test safety-sensitive routes
- Run the feature with good data, stale data, missing data, and contradictory data.
- Test warnings, disclaimers, stop states, and escalation links.
- Check screenshots and metadata for overbroad safety claims.
- Confirm support can route urgent reports or corrections.
- Record evidence for any professional, health, finance, weather, or navigation claim.
Physical safety ledger
The ledger forces teams to discuss foreseeable misuse before review. It also gives reviewers a clear path to verify that the app behaves cautiously.
After launch, monitor safety reports separately from general support. Even low-volume reports can justify copy changes, feature limits, or stronger onboarding before the next release.
For community or marketplace apps, consider harm caused by other users, not only by first-party advice. Meeting locations, service providers, fitness challenges, or repair instructions can each move risk into the physical world.
If the feature depends on sensor or third-party data, state freshness and uncertainty near the recommendation. Users should know when the app is estimating, extrapolating, or waiting for better information.
Escalation paths should work when the user is signed out or distressed. A safety report that requires a perfect account state may fail exactly when the user needs help most.
If the app includes challenges, streaks, or competitive prompts, check whether they encourage unsafe escalation. Growth mechanics should not pressure users into physical risk or hazardous comparison.
Safety ledger: Feature: [name] Potential harm: [scenario] Claim limit: [wording] Evidence/source: [source] Fallback: [message/path] User control: [stop/override] Support escalation: [route]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check safety evidence
Review harm scenarios, claim limits, fallbacks, and safety-sensitive metadata before submission.
Open the tool