You would have to write a transport [0] (or something like that) for push notifications, probably (which are usually http/2 now) since they are different from websockets and long poll with which channels work right now.

It would be easier to just use one of the libraries made exactly for push notifications [1][2][3] and call their functions from within your channels.

You might also want to consider using something like a queue or a genstage [4].

[0] Phoenix.Socket.Transport — Phoenix v1.8.8
[1] GitHub - inaka/apns4erl: Apple Push Notification Server for Erlang · GitHub – ios only (supports http/2)
[2] GitHub - codedge-llc/pigeon: iOS and Android push notifications for Elixir · GitHub – ios and andriod (supports http/2)
[3] GitHub - chvanikoff/apns4ex: APNS for Elixir · GitHub – ios only (http/1.1 only?)
[4] https://blog.discordapp.com/how-discord-handles-push-request-bursts-of-over-a-million-per-minute-with-elixirs-genstage-8f899f0221b4

I went through the Pigeon library’s docs. It uses HTTP2. FCM too relies on persistent HTTP connection. Below I have attached a comparison of HTTP and MQTT.

MQTT was designed for connecting devices, sensors, etc. over an unreliable network. It has a low network overhead. Thus, keeping persistent TCP connection is more battery efficient. Further MQTT was built for remote sensors which don’t have huge power backups available. Read the articles below as they have done a better job at explaining the why and how.

https://medium.com/@shubhanshusingh/http-vs-mqtt-9008d448bf88
https://systembash.com/mqtt-vs-websockets-vs-http2-the-best-iot-messaging-protocol/

https://www.ibm.com/developerworks/community/blogs/sowhatfordevs/entry/using_mqtt_protocol_advantages_over_http_in_mobile_application_development5?lang=en

But there might be other reasons as to why you wouldn’t want MQTT. If you or your organization is reluctant to monitor security at ports other than 80 or you already have running infrastructure over HTTP2 or other preferences then you wouldn’t want to run MQTT.

And there is a good use case where a firm opted out of MQTT.

I for one feel there are too many benefits with MQTT along with customisability to overlook. MQTT gives necessary autonomy and fliexibility to build a highly customised mobile app, IoTproduct.

Check my answer on the same topic. Many answers here are not battery friendly.

How exactly is mqtt more battery friendly than something like apns? Both of these require a persistent tcp connection, do they not?

I do like mqtt as well, but the overhead from ws/mqtt/http2 is negligible in comparison with that of tcp, so I don’t think there is much difference in practice.