Hacker News new | ask | show | jobs
by xtajv 403 days ago
Ok sorry, I'm going to state the obvious.

The "Apple Critical Alerts" API is clearly intended as a replacement channel for cellular emergency alerts[0]. (If not a "replacement", then perhaps a "supplemental" option. Redundancy is good when we're talking about whether "911" works).

The "Apple Critical Alert" API policy, restricting who's allowed to call the API, is a good thing. You just do not get performant public notifications if you allow just anybody to broadcast. (Milli)seconds count, people.

I hate Singleton patterns as much as anybody. And I hate when business happens behind closed doors, with limited public access, and restricted opportunity for public comment.

But again, if we're talking about the choice between """ locking down this one special channel, because it's responsible for real-time public safety alerts """ vs. """ asking how many broadcasters can possibly share that channel, before contention and congestion result in human-perceptible delays to alert delivery. """ Then I would opt for the former.

--- [0] You know how your phone will buzz REAL loud if there's like, an Amber Alert or Tsunami or something? That's a feature of the cellular system. To my knowledge, emergency alerts and 911 calls go over a separate dedicated mini-channel, which has gone by various names through POTS/2G/3G/5G and beyond. A.K.A.s: - Public Warning System (PWS) - Wireless Emergency Alerts (WEAs) - CMAS (Commercial Mobile Alert Service)

10 comments

The article, and Apple's messaging therein, contradicts your understanding of this feature.

> Because Critical Alerts are disruptive, they are meant to be used for a very restricted number of purposes. This include medical- and health-related notifications, home- and security-related notifications, and public safety notifications.

Only the last use case matches what you describe. And as the article says, Apple's own Health app uses this feature, along with, apparently, simple TODO apps. Apple's health app makes sense, since Apple specifically calls out medical apps. Is a medicine reminder app a medical app? I would say so.

Apple's developer documentation states:

> Critical alerts ignore the mute switch and Do Not Disturb; the system plays a critical alert’s sound regardless of the device’s mute or Do Not Disturb settings. You can specify a custom sound and volume. > > Critical alerts require a special entitlement issued by Apple.

Apple's Critical Alerts aren't a broadcast system though. It's just an API to bypass the mute switch and DnD, but users have to go into settings to enable it on a per-app basis. The alert is otherwise just a normal notification.

It does tend to be used for public safety notifications, but it's strictly opt-in. There are also several apps using it for smart home security alerts, health reminders, etc. already.

I haven't seen any hint that the Critical Alerts entitlement would use any special infra compared to regular push notifications.

It's just metadata in the notification body indicating to the device to ignore silent mode etc.

It's e.g used by Pagerduty [0]. It's just a way to override notification settings.

The software for the systems you mention have this entitlement (or some equivalent), but are otherwise completely unrelated to this.

[0]: https://support.pagerduty.com/main/docs/mobile-app-settings#...

Nice to see PagerDuty mentioned here. I was on the mobile team at PagerDury that battled to get the entitlement to use Critical Notifications in the app. We were refused multiple times before we got the entitlement.
> The "Apple Critical Alerts" API is clearly intended as a replacement channel for cellular emergency alerts

I don't see how it is "clearly intended" for this purpose, and nothing seems to be indicating that.

Apple's own applications use it for a lot of things that are not at all related to those large-scale alerts, and so do many other applications. Their critical alerts API is just about bypassing the silent mode when needed.

You say it yourself, there is another system for large-scale alerts, which is unrelated to Apple.

That would make sense if Apple's description and usage didn't completely contradict what you wrote. It's not "clearly intended" for that purpose if Apple uses it for other purposes. This seems like your interpretation rather than Apple's policy.
P.S. I'm sorry to be grouchy about it- I just don't think folks realize that yes, 1. emergency infrastructure really does run over the same networks as everything else 2. That We carve out special lanes for emergency/911 packets. That traffic is special.
What?!

You mean I don’t get to have every phone in a store buzz, when we have a special on tinned prunes?

What is the feature for, if not that?

Overzealous marketing is why we can’t have nice things.

Agreed. Apple also has the category of Time-sensitive notifications which is available to all apps and would fit fine for this usecase. Worst case one would need to direct users to add the app as a Do Not Disturb exception.
Yet zenduty is allowed to use critical alerts api while being unrelated to public safety in general
Zenduty is very much related to public safety depending on the industry.

If you're at a power company an incident could mean a life saving medical machine goes offline.

And I've personally seen a P1 related to a power outage at an infectious diseases lab.

Nah it’s for apps like those that monitor a user’s continuous glucose meter. In addition to simple monitoring they alert the user when the reading is on the extreme ends of a safety range. The app for Abbott’s Freestyle Libre requires the setting to be enabled and will not allow the use of the app without it enabled. I suspect that’s what Apple means in their rejection. I can turn it off but the app won’t work without it.
I don't think it's just about latency. Actually I think it's mainly about not diluting the meaning of emergency alerts and opening it for abuse. But yeah, I agree. I think what TFA has run into is by design, and frankly I'm kinda glad it works this way.