Sort of. Apple's and Google's notifications infrastructure only delivers to signed applications. Even if you run your own IM server, you can't use your own open source client without building and signing it yourself, and then setting up the backend infrastructure, which requires using the developer certificate for the application to generate authentication credentials to Apple's and Google's notification service. IIUC (and I think as you point out) the way it works for XMPP is a client informs the server about its gateway, which will be run by the client publisher; when the XMPP server wants to generate a notification, it contacts that gateway which then pushes the notification through Apple's/Google's service API for delivery to the client. For a nominally self-hosted IM server, notifications are traversing two third parties, either of which might be logging the metadata, which may include the full body of a message, depending on the application's frontend and backend architecture and configuration.

So in a sense it is part of the application, especially if you're a small entity with a single app (as opposed to large entities like Facebook where you have dozens of applications under a complex hierarchy of developer and application certificates).

I can understand why things are done this way. It helps to avoid abuse and spam as there's no way to inject notifications without strict accountability. But it does kind of suck. To fully self-host IM, you need to build, sign, and distribute the client yourself, as well as run a notification gateway with the appropriate credentials. And I'm not aware of any plug-and-play open source solutions for the gateway, at least not for XMPP. (I could be mistaken, though.) Maybe Matrix servers have it builtin, but I wouldn't be surprised if they don't, especially the reference implementation, as this complexity provides a moat for monetization.