This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actually pretty good on mobile. Between the persistent TLS connection which can let the radio go to sleep when no data is being sent (without the tail time of creating a new TCP connection constantly) and TLS style stream management it's very battery efficient when you're using a server that's optimized for mobile.

The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?

Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software).

I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too).

So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.

It was rather less than 15 years ago I had the conversations with gtalk architects (who liked XMPP and left when google abandoned interoperability) that led to my opinion.

So apparently not everybody shares your definition of 'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.

I wouldn't subscribe to the "15 years ago" statement, but we have figured out mobile battery use pretty well, and the respective solutions are avialable in both server and client implementations. Have a look at [0] and [1] for (slightly biased but more detailed) elabortations.

simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics

It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing.

[0] https://gultsch.de/xmpp_2016.html

[1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....

The Google Talk people literally never tried to implement any of it as far as anyone could see publicly (eg. stream management, compression, client state indication, etc.). I'm not sure if it was a problem with discoverability, or if they just didn't want to, but their feedback was always that things they needed didn't exist, and then stony silence when someone would point out the thing they needed.