Well, sure. Logically, your language/libraries almost certainly present it as something resembling a persistent connection, though, probably not a ton different from how they present TCP (just with fewer features).

However, technically correct is the best kind of correct :-)

I may also be mis-remembering, and APNS might use TCP. Either way, you're spraying bits at a socket and not getting any kind of feedback (until later, on a separate connection), aside from getting dropped if your cert doesn't check out (again, IIRC).

Particularly in the earlier days before APNS revamped their APIs to provide better feedback, yeah - you could spray and pray and honestly it'd work pretty well, but oh boy was doing anything complex difficult. UA legitimately simplified a solid chunk of that, and you could just hammer their API however you pleased rather than needing to maintain stable connections to APNS.

Where I worked did eventually drop them and start using our own redis queue + long-running process and that was plenty sufficient for what we did. We lost the "+1 to iOS's counter" feature (this was prior to background processing of notifications existing at all), but we had solid evidence that it simply wasn't providing us much benefit for the complexity/cost compared to just a numberless dot.

Oh no I forgot about badges! IIRC early on on iOS all you could do was set them to a specific number, so you had to track that state server-side (by having the app report when a notification was seen). There was no "take whatever it is and add one", you just (optionally) set an exact integer in the message payload and that number would go on the badge. That was a pain.

Yep, that's exactly what it was. UA had a feature that let you say to increment/decrement by N, and they maintained a cache + cleared it appropriately when the app launched.

Obviously we could do that too with some additional storage, but handling it across multiple OSes and weird iOS + Android lifecycle details was enough of a pain that we didn't end up doing it.