[HN Gopher] I can't understand Apple's Critical Alert policy (2023)
___________________________________________________________________
I can't understand Apple's Critical Alert policy (2023)
Author : logistra
Score : 90 points
Date : 2025-05-08 03:04 UTC (19 hours ago)
(HTM) web link (jhan.bearblog.dev)
(TXT) w3m dump (jhan.bearblog.dev)
| DecentShoes wrote:
| It's easy to understand: Apple is deliberately abusing its power
| to gain an unfair competitive advantage.
| gambiting wrote:
| >> By this logic, even the Health app shouldn't be allowed to use
| it.
|
| Apple is well known for giving their own apps permissions that
| no(or few) other apps can get - it's an unfair advantage and they
| keep getting slapped for it in courts but clearly not enough for
| them to stop doing it.
| dinkblam wrote:
| > What's even more confusing is that I've seen general-purpose
| to-do or reminder apps on the App Store that somehow got approved
| for Critical Alerts, even though their use case seems far less
| urgent
|
| thats because App Store review is a.) random and b.) they play
| favorites so the same rules don't apply to everyone
|
| we got rejected because of "Mac*" in the name. we pointed them to
| a dozen others that had it, where it seemingly was no problem.
| didn't help.
| codetrotter wrote:
| > we got rejected because of "Mac*" in the name. we pointed
| them to a dozen others that had it, where it seemingly was no
| problem. didn't help.
|
| To be fair, it's understandable for many reasons that they
| don't want other companies to use "Mac" in the name of the
| software.
|
| - Brand dilution
|
| - Losing trademark if Mac becomes a generic word
|
| - It's also annoying actually with apps that name themselves
| that way. Just because I'm on a Mac doesn't mean I need that a
| whole bunch of my apps start with "Mac" in their name. Likewise
| for apps that start their name with lowercase i on iOS, and
| apps that end their name with droid on Android.
|
| Also, for the ones that were allowed anyway, were those already
| big outside of App Store by chance? Or have they been allowing
| even new apps that don't have an existing user base into the
| App Store with names like that?
| Agentlien wrote:
| > Losing trademark if Mac becomes a generic word
|
| This is interesting considering that it was a common word
| before Apple started. Both the variety of apple called
| Macintosh and a Mac raincoat (named after Charles Macintosh).
|
| Though it would be really funny if the Beatles were referring
| to a computer in Penny Lane:
|
| "And the banker never wears a mac in the pouring rain. Very
| strange"
| brazzy wrote:
| Trademarks are specific to a kind of product or service. A
| Mac raincoat does not violate a trademark on Mac computers
| or software.
| lapcat wrote:
| > Losing trademark if Mac becomes a generic word
|
| > Also, for the ones that were allowed anyway, were those
| already big outside of App Store by chance?
|
| These two points contradict each other. If Apple were
| concerned about losing a trademark, they would have already
| sued popular apps that have "Mac" in the name.
| cwillu wrote:
| So you agree that "thats because App Store review is a.)
| random and b.) they play favorites so the same rules don't
| apply to everyone"
| indianmouse wrote:
| They seem to shoot based on vague reasons. And they don't reason.
| If it is a no, it is a no.
|
| Time for an alternative app store. It is needed across the world.
| Single point of failure and control is not good for any
| ecosystem. Too much dependence on one single entity if one wants
| to exists in that is really some sh*ty concept.
|
| Break free and break good! EU has to help here...
| _factor wrote:
| Let the App Store contain backup providers that are allowed to
| compete with iCloud while you're at it. The ability to self
| host it yourself would be a game changer for the lockdown.
|
| There are too many apps with local data that can only be backed
| up via iCloud. For what's essentially an archive upload to
| storage, Apple raises a lot of barriers.
| jeroenhd wrote:
| You can install alternative app stores on iOS (within the EU).
| AltStore, Epic Games Store, and even a corporate-targeting
| store from Mobivention.
|
| Apple is pulling some shit that will probably be declared
| illegal the moment it hits the courts with installation fees
| when distributing apps outside of Apple's ecosystem, but AFAIK
| Epic is taking care of that for AltStore and Mobivention
| probably factors it into its corporate pricing structure.
|
| There's a lack of apps on these stores, though.
| nazgu1 wrote:
| You can, indeed, but all apps have to pass Apple review. So
| they can still reject app on vague reasons.
| dewey wrote:
| That's not true, they get notarized but not reviewed.
| nazgu1 wrote:
| You are right, apps are not reviewed by humans. But there
| is automatic review in the process of notarization. And
| you still need to ask apple for all entitlements you need
| (Critical alerts, CarPlay etc), as in the case mentioned
| in this blog post.
| socalgal2 wrote:
| guessing it won't be long until they add an LLM type
| thing into the mix. Then they will "claim" it's automated
| and fair.
| kalleboo wrote:
| Bullshit. "Notiarization" for iOS apps in the EU is just
| App Review by another name, completely different from the
| automated Notarization they originally introduced for
| macOS apps.
|
| https://mjtsai.com/blog/2024/03/17/ios-notarizations-
| human-r... https://mjtsai.com/blog/2024/06/14/utm-
| blocked-outside-app-s...
|
| "have it evaluated based on the Notarization Review
| Guidelines (a subset of the App Review Guidelines)"
| https://developer.apple.com/help/app-store-
| connect/distribut...
| WhyNotHugo wrote:
| > You can install alternative app stores on iOS (within the
| EU).
|
| And you need a few million dollars in the bank to be allowed
| to implement one (plus some other ridiculous requirements).
| The whole system still makes it impossible for a small team
| to develop and shift software without a huge middleman
| WhyNotHugo wrote:
| > Time for an alternative app store.
|
| Not really. Just allow users to install applications without a
| middleman. Like we've been doing since forever in pretty much
| any other platform.
|
| The whole point of an app store is to limit and control what a
| user is allowed to run. Alternative app stores just shift the
| blame elsewhere
| Zealotux wrote:
| Why can't I, the user, give a special permission to a specific
| app to override the silent mode just like I can with my emergency
| contacts?
| akimbostrawman wrote:
| Because you are always only the user instead of the owner with
| an apple device and software.
| aziaziazi wrote:
| I understand and share your feeling, however I think OP
| question is interesting enough to deserve a more complete
| response. Trying to frame it another way:
|
| Is that specific non-par feature voluntary from Apple or
| might them just didn't thought about it yet? If that's
| voluntary, what's the logic that make them think it's better
| for their business to not allow that feature?
| akimbostrawman wrote:
| From my experience apple tries very hard to remove or hide
| any feature it can, there argument is probably to not
| overwhelm user and simplicity
| aziaziazi wrote:
| That's a fair hypothesis. Thanks.
| jwatzman wrote:
| For do not disturb, you can: settings -> focus -> do not
| disturb has a section at the top for allowing specific apps or
| specific people.
| nottorp wrote:
| You have functionality that is overlapping with something
| provided by Apple.
|
| It's possible they will find reasons to reject your app
| indefinitely.
| agos wrote:
| if that is so they could just say that they reject the app
| because it replicates built in functionality - it's a well
| known cause for rejection
| nottorp wrote:
| They could be A/B testing.
|
| Or more likely, Apple reviewers aren't paid so well and have
| 3 minutes to review each submission so they just reject for
| the first reason that comes up.
| zug_zug wrote:
| Sounds like apple really needs a better review/appeal process,
| official set of standards, etc. Seems like it's bad for their
| ecosystem at this point.
| threeseed wrote:
| a) They have an appeals process:
| https://developer.apple.com/distribute/app-review
|
| b) Standards has been in place for over a decade:
| https://developer.apple.com/app-store/review/guidelines
| logistra wrote:
| The appeals process does not apply to Critical Alert
| Entitlement requests, which must be submitted through the
| external form:
| https://developer.apple.com/contact/request/notifications-
| cr...
| nazgu1 wrote:
| The same is with CarPlay for example. You need to apply form
| entitlement. For me this is weird, it is user choice if he would
| like to have critical alerts, CarPlay UI and so on. And Apple
| have review process to not pass apps that abuse this mechanisms./
| SuperShibe wrote:
| This seems like something you could fix by reminding them that
| the DMA exists (if your app is available in the EU)
| petercooper wrote:
| I could shorten this to _" I can't understand Apple"_ much of the
| time. I love Apple products, but they do make some wacky
| decisions that surely make sense _somehow_ (probably due to
| scale, regulation, or business aims) but the reasoning is
| entirely opaque nowadays. One thing I thought Steve Jobs did
| reasonably well was at least try to justify Apple 's decisions,
| but they don't have anyone who levels with people in that way
| anymore.
| xtajv wrote:
| 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)
| xtajv wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| cnity wrote:
| 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.
| iLoveOncall wrote:
| > 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.
| viraptor wrote:
| 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.
| gagik_co wrote:
| 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.
| nurumaik wrote:
| Yet zenduty is allowed to use critical alerts api while being
| unrelated to public safety in general
| threeseed wrote:
| 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.
| rezonant wrote:
| 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.
| HelloImSteven wrote:
| 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.
| filleokus wrote:
| 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#...
| hofo wrote:
| 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.
| uni_baconcat wrote:
| I have checked all apps on my phone. Besides Apple first party
| apps such as Home and Message, only one earthquake alert app has
| this level of notification.
| bitpush wrote:
| People should realize that Apple plays favorites and lets their
| own apps use private APIs. Developers that bet on Apple platforms
| (iOS in particular) are at the mercy of Apple, and the company
| doesnt even try to play fair most of the time.
| threeseed wrote:
| Apple has always considered their apps to be part of the OS.
|
| It was only because of legal disputes that they were ever split
| off.
|
| And it is shocking that Apple the OS company has a favourable
| relationship with Apple the app company. Never happens in IT.
| mimsee wrote:
| If this reminder app to take meds can't access this API, how can
| HomeAssistant's iOS app access it where, I the user, can base the
| trigger for a critical notification on virtually anything?
| logistra wrote:
| Yeah. That's why I am so confused.
| os2warpman wrote:
| I don't know if a pill reminder app rises to the level of
| importance where a critical alert is needed.
|
| There are only five apps on my phone, out of over a hundred, that
| use critical alerts.
|
| PulsePoint, if someone near me is having a heart attack
|
| Messages, if one of my kids is in trouble
|
| Health, if I am having a heart attack
|
| Home, if my smoke alarm is going off
|
| ActiveAlert, my fire department's dispatch notification app,
| which will tell me where to drive the ambulance if someone is
| having a heart attack
|
| If I'm in a darkened theater and someone nearby needs cpr, my
| house is on fire, or one of my kids is in trouble I want the
| phone to make a sound.
|
| I want someone else's phone to make a sound if they get those
| notifications, too.
|
| If it's time to take their atorvastatin I don't give a shit their
| phone better stay shut the hell up.
|
| If someone's calendar app slipped through the cracks and got
| permission to issue critical alerts, THAT is the problem, not the
| fact that a pill reminder app can't.
| Martinussen wrote:
| If I miss the dosing window by more than an hour or so it'll
| either ruin my sleep or ruin my day after lunch, I have
| responsibilities and can easily lose track of time for an hour
| or two while working or in meetings, so the iOS medication
| reminders are very useful to me personally, at least.
|
| edit: though if I remember or see the initial reminder and log
| it, it obviously won't go off with sound. If it pings, I've
| basically always already forgotten.
| xattt wrote:
| With all due respect and without knowing your clinical
| history _at all_ , this level of sensitivity to a statin
| probably warrants a review of your med with your provider.
| BrandonSmith wrote:
| Now evaluate a glucometer.
| os2warpman wrote:
| Bluetooth-enabled continuous glucose monitors are medical
| devices and have access to critical alerts.
| kalleboo wrote:
| > _I don't know if a pill reminder app rises to the level of
| importance where a critical alert is needed_
|
| Doesn't that depend a lot on the types of pills a person takes
| and their mental needs?
|
| > _If it's time to take their atorvastatin I don't give a shit
| their phone better stay shut the hell up._
|
| I have it on good authority that some people's phones even make
| sounds when they get something as trivial as _a phone call_
| TZubiri wrote:
| But not in dnd
| bArray wrote:
| I think the main point is being missed here:
|
| > Apple's own Health app uses Critical Alerts for its medication
| reminders, so I assumed my use case would qualify. I submitted a
| request for access to the API, but it was rejected.
|
| I think what is being developed is a competitor to a space that
| Apple are in and want to be more involved in, and that is why you
| will not get permission to use the necessary API.
| LadyCailin wrote:
| That anti competitive stance has been working very well for
| Apple lately.
| maratc wrote:
| I use "Apple's own Health app" medication reminders and from
| what I can see, _they do not use Critical Alerts_. They behave
| differently from the app I use that prompts me of the sugar
| levels of a relative (that app _does_ use Critical Alerts, and
| the difference is very clear.)
| terabytest wrote:
| Critical alerts are available as an optional setting for
| medication reminders in the iOS Health app.
| lapcat wrote:
| For some reason the submission title is labeled (2023) even
| though the blog post is dated 08 May, 2025.
___________________________________________________________________
(page generated 2025-05-08 23:02 UTC)