Hacker News Reader

Comment by jonplackett | Hacker News Reader

Anyone know how long ago that system would have been introduced?

It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?

The notification API is quite old (iOS 3). It's explicitly an untrusted API that you shouldn't use for something like showing the restore in progress UI, so I suspect that was something written quite a bit later. Widget extensions are iOS 14. There's older ways to run background tasks, but none of them would give the soft brick. Background fetch, for example, originally didn't run until after you launched an app for the first time after restarting.

This is an internal broadcast notification API (akin to dbus on Linux), distinct from the API used to display notifications to the user.

Yes, I am aware. I'm not sure what makes you think I was talking about UI notifications?

FWIW I also thought you meant UI notifications (the reason is: I’m dumb). But anyway, I found the point of clarification helpful even though it wasn’t strictly necessary.

Wasn’t it in OS X before that?

Documentation claims 10.6, which is the equivalent OS X version (both are the 2009 releases).

That's actually just for the block-based APIs like notify_register_dispatch(), the other notify APIs have no availability annotations at all.

Manual page says Mac OS X 10.3.

Darwin notifications are so old they don't have any availability annotations (block-based darwin notification APIs like notify_register_dispatch() were introduced in macOS 10.6 / iOS 3.2, but the rest of them are declared as always available). They absolutely predate any notion of an AppStore, of being able to install apps without implicitly putting a lot of trust in the app to not be malicious.

Reply on news.ycombinator.com