Because they don't work directly with web services. Read the author's article: https://medium.com/@re_dmitriy/what-is-refl-me-67e6eb151f27

> The application with the required frequency directly checks JSON on the web service side

How charming.

What's wrong with that?

Because it is the most inefficient approach possible. You either have potentially long delays before receiving a notification (if you poll service once an hour, average delay would be 30 minutes), or you do LOTS of polling, draining the battery/abusing the service. If you have 20 notifications / day and you check service every minute, in a day you'll make 24*60 poll requests, only 1,38% of which would yield some meaningful payload.

There is no need for frequent updates for a lot of data. This application is not for instant messages.

And yet, this is exactly how push notifications are implemented on mobile phones. You have the illusion to push a message from server to device while in fact you also push a message onto a queue that is polled at regular intervals by the mobile. No way around it, mobile devices don't have guaranteed connectivity as servers do.

No. That's not how it works.

From the Apple Developers Documentation [1], "On initial launch of your app on a user’s device, the system automatically establishes an accredited, encrypted, and persistent IP connection between your app and APNs."

This persistent connection is, in fact, an XMPP session (likely, a modified one) [2].

Google's FCM too uses XMPP [3].

[1] https://developer.apple.com/library/archive/documentation/Ne...

[2] https://www.quora.com/What-technology-does-the-iOS-Apple-Pus...

[3] https://firebase.google.com/docs/cloud-messaging/xmpp-server...

If you look at the format of APNS messages, they are nothing like XMPP. It seems very unlikely Apple uses it. That link you post does not confirm it.

Format of APNS messages is just a payload. The information about APNS being based on XMPP was widely available on developer.apple.com and was often mentioned in developer sessions in 2010..12 when I was actively following it.

The current absence of direct XMPP mentions on Apple Deveoper website might mean that they consider their internal technology not important for developers, or it might mean that Apple had changed the protocol for some reason (they could have opted to use some binary protocol, for example), but claiming that push notifications work on iOS devices by polling servers is beyond ridiculous. VoIP pushes arrive in ~1 second. Such response times would require 40000 poll requests/day or more

I never claimed APNS worked by polling. I was developing iOS apps in the 2010-2012 time frame and never saw a mention of XMPP. I simply don't believe they are using it. They must have their own proprietary solution.

> I never claimed APNS worked by polling.

I was referring to earlier comments by nicolas314, sorry if it wasn't clear.

> I was developing iOS apps in the 2010-2012 time frame and never saw a mention of XMPP

I might have been more attentive to these details because XMPP was relevant for my projects. Anyway, Apple definitely does use port 5223 [1][2] for push notifications. What protocol is known to use this port?

Speaking of proprietary, it is very likely that they have modified it (by stripping it down, mostly). Many XMPP features are excessive or inefficent for push notifications, but core functions - message routing and persistent TCP connection are extremely well suited for serving several billion devices.

[1] https://support.apple.com/en-us/HT203609

[2] https://support.apple.com/en-us/HT210060

> No way around it, mobile devices don't have guaranteed connectivity as servers do.

Not sure what "guaranteed connectivity" has to do with it, your phone is connected to network ~90% of the time, and when it is, it has a socket connection with the Google Cloud Messaging API (or iPhone equivalient) which pushes down data as it comes into the queue. If messages come in while you're disconnected, you get them all the next time data is pushed.

Ah but sockets are only an illusion that fall apart under the next tunnel. Mobiles are not constantly connected, they use a wireless packet-based network. The only way your mobile is registered as part of a network is because it is the one polling stations at regular intervals. Can't go the other way around, really. How could the network know you are now out of that tunnel? You may want to have a look at how APN are implemented on iOS to see how a push is in fact a poll from device.

No. See my answer above. Mobile devices on both iOS and Android have a built-in XMPP client that reconnects to APNS/FCM servers every time it regains connectivity.

If they’re using XMPP like others in the thread mentioned, they’re likely using STUN/TURN for signaling. IIRC according to google, something like 10% of hole punched traffic needs to be routed through the TURN server due to symmetric NAT. For all other types, a nearly persistent connection from server to client is possible with STUN/TURN, since a client can resignal when its connection changes.

Not the poster but it may be useful to know that Andrew_nenakhov is a CEO of company that provides a Jabber messanger (Xabber).

My occupation is not really relevant here, but yes, such service could be coded in maybe 60 minutes tops to accept a JSON and forward it to XMPP, and it would be way more efficient. Don't like XMPP? Ok, make a Telegram bot and receive notification with it.

I'm glad.

> Because they don't work directly with web services.

Then why not make a relay, i.e. a server that forwards messages from a webclient to Whatsapp, email, etc.?

This would be nice for websites and services users want to get push notifications from. I get that html5 notifications should be able to do this at some point but there is still merit in having another way of getting stuff to your phone and possibly desktop.

Thing is, it does not offer push notifications. It's very opposite of that - the app seems to just poll the service with regular intervals.

Yes, but the interval is set in JSON, which is convenient. Besides, there is a manual mode.

Do you realize that's the opposite direction of this? In that case you SEND something to a chat app, but this app can RECEIVE data from a web service. Way simpler architecture.

> Do you realize that's the opposite direction of this? In that case you SEND something to a chat app, but this app can RECEIVE data from a web service. Way simpler architecture.

Well, it receives data by hitting a specific endpoint with a specific protocol. It’s “simpler” in that it may be easier to implement, but you still have to modify your service to get that to work. And if you must modify your service, you may want to implement something that’s better supported and doesn’t require users to install (and configure) yet another app.