The payload can be picked up and managed via REST API as well.
I'm building a similar solution for a slightly different usecase, so wanted to have a look under the hood. There's nothing I can see that would stop you using this for iOS so maybe they just don't have a iOS dev on the project.
So, their conclusion in the end that it is technically impossible to build a self-hosted notification solution on iOS due to Apple's restrictions. Shame because I would love to be able to deploy something like this internally at work, but of course, half the business is walking around with iPhones. I'm kind of curious though why it doesn't ruin every single XMPP client out there - there seem to be a few on the App store.
Either the server is sending pushes through APNS or the client is simply not getting messages reliably when the screen is locked or the app backgrounded, as the network restrictions very much apply to those clients as well (and to everything, to save power by sleeping the NICs).
Thanks for clarifying. This could be a good solution for a non Google play type phone, or just someone who doesnt want t rely on Google servers. It would just mean in the latter case there would always be 2 open connections listening for messages...
New messages in the queue are then notified (gotified) via the websocket. https://gotify.net/api-docs#/message/streamMessages
The payload can be picked up and managed via REST API as well.
I'm building a similar solution for a slightly different usecase, so wanted to have a look under the hood. There's nothing I can see that would stop you using this for iOS so maybe they just don't have a iOS dev on the project.
Edit: Ah, here's why. https://github.com/gotify/server/issues/87