Which Alerts Should Qualify for Time‑Sensitive Interruption Level in Our iOS Objective‑C App?

Answer the exact question first

Only alerts that are truly "time‑sensitive"—that is, the user would miss a critical event if the notification were delayed or suppressed by Focus—should be sent with UNNotificationInterruptionLevelTimeSensitive. Typical candidates are:

• Emergency or safety alerts (e.g., fire alarm, medical emergency).
• Health‑related events that require immediate action (e.g., abnormal heart‑rate warning).
• Real‑time transaction confirmations that the user cannot afford to miss (e.g., payment received).
• Context‑aware alerts that only make sense while the user is actively engaged with the app (e.g., a ride‑share ETA while the user is in the vehicle).

Anything that can be delayed, snoozed, or that is not context‑dependent should fall back to .passive or .timeCritical only if the circumstances truly demand it.

Why the criteria matter

Apple's entitlement model is strict: you must explicitly request the timeSensitive entitlement in your App Store metadata, and you must provide a clear, documented justification. Misusing the level can trigger entitlement revocation or App Store rejection, and it can erode user trust if notifications appear in the middle of a Focus session when they aren't truly urgent.

Practical steps for your app

1. Define categories. Create a UNNotificationCategory for each type of alert. Add an interruptionLevel property only to those that meet the criteria above.

   UNMutableNotificationContent *content = [[UNMutableNotificationContent alloc] init];
   content.interruptionLevel = UNNotificationInterruptionLevelTimeSensitive;
   

2. Document justification. In the app's privacy policy and developer documentation, list the use cases for each time‑sensitive category and why they must bypass Focus.
3. Opt‑in flow. Present an explicit opt‑in screen before requesting the entitlement. The user should see a concise description of why the app needs to deliver these alerts even when Focus is active.
4. Test with Focus. On a test device, enable a Focus mode (e.g., Do Not Disturb) and schedule a time‑sensitive request. Verify the banner appears immediately. Repeat with a non‑time‑sensitive request to confirm it is suppressed.
5. Monitor post‑release. Use crash logs and analytics to track user complaints or Focus‑mode analytics. If you see a spike in notifications during Focus that users find intrusive, consider downgrading the level.

Verification commands (safe, scoped)

• Check user authorization:

  [UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings *settings) {
      NSLog(@"Time-sensitive auth: %@", @(settings.timeSensitiveAuthorizationStatus));
  }];
  

• Schedule a test notification (replace identifier and content appropriately):

  UNMutableNotificationContent *content = [UNMutableNotificationContent new];
  content.title = @"Test";
  content.body = @"Time-sensitive test";
  content.interruptionLevel = UNNotificationInterruptionLevelTimeSensitive;
  UNTimeIntervalNotificationTrigger *trigger = [UNTimeIntervalNotificationTrigger triggerWithTimeInterval:5 repeats:NO];
  UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:@"test" content:content trigger:trigger];
  [[UNUserNotificationCenter currentNotificationCenter] addNotificationRequest:request withCompletionHandler:nil];
  

Ask for missing diagnostic detail

If any of your alerts need to be delivered while the user is performing a high‑risk activity (e.g., driving, operating heavy machinery), that would strengthen the case for making them time‑sensitive. Let us know if that applies, and we can refine the recommendation accordingly.