[dgivney]

From what I can tell it appears to be a replacement FCM/APNS. The client subscribes directly via websocket to a self-hosted server (Go binary).

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

[zmmmmm]

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.

[petronio]

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).

[dlhavema]

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...

[damian2000]

Those open connections would be very hard to keep open indefinitely in an Android app that gets optimized or goes into sleep / doze mode.