Most notifications in iOS are advisory. They can be dismissed, silenced, blocked, or swallowed entirely by Focus modes and the mute switch. For a recipe app or a news app, that is completely appropriate. Users should be in control.

For Drop, it was a problem.

Drop is used by people managing chronic conditions with injectable medications, including insulin and GLP-1 agonists. For some of those users, a missed dose has real clinical consequences. A standard notification that goes silent during sleep or work is not a safety net. It is a gap.

Critical Alerts are Apple's answer to this. They bypass Do Not Disturb, Focus modes, and the mute switch entirely. They play a sound regardless of device state. They are the iOS equivalent of an alarm that cannot be turned off without acknowledging it. Apple does not grant the entitlement to everyone who asks. You have to apply, explain your use case, and wait.

The application required a written justification describing what the alerts would be used for, who would receive them, how frequently they would fire, and how users would control them. The clinical framing had to be precise: Drop is not a diagnostic tool and does not replace medical judgement. But for a user who has set a scheduled injection reminder for a medication they have opted into critical alerting for, the difference between a notification that fires and one that does not is meaningful.

The key arguments in the application were specificity, user control, and restraint. Critical Alerts in Drop fire only when the user misses the injection window they have configured. The maximum realistic frequency is two to four per day for a user on a strict injection schedule, and zero on any day they adhere to that schedule. The feature is opt-in at the medication level: the user explicitly marks a medication as critical and sets the window. They can disable it at any time.

Apple approved it. The confirmation email arrived on a Tuesday and it was genuinely one of the better moments in Drop's development, not because of the technical capability it unlocked, but because of what getting it meant. It meant the use case was credible. It meant Drop was being taken seriously as a tool for people who actually depend on it.

Implementation uses UNAuthorizationOptions with .criticalAlert, a system-level permission prompt separate from the standard notification request, and criticalSoundVolume set conservatively to avoid startling users at night.

The implementation is live. The entitlement is one of a small number of things in Drop that required external approval, and the process of getting it was worth the effort: it forced a precise articulation of exactly who Drop is for and what it is trying to protect them from.

That clarity is useful well beyond the permission request.