Ah. You were thinking ios as mobile. ios is not the only mobile. Xmpp is fine on android.

Well, not really fine. You should trust me in this, because our Android xmpp app is closing on 2 million installations on Google Play. There are a lot of problems maintaining a persistent connection, and Google makes it harder with each new version of Android. And if we go for push notifications, without persistent connection, the problems are the same as with iOS.

To counter this and make XMPP work well on mobile and in browsers, we had to develop our own server and a bunch of new protocol extensions.

I believe there are problems, and a million thanks for maintaining clients.

Real question: for email, I use K9, which supports IMAP Push, which, as far as I know, needs a live connection as well. Do you know if they are struggling as well, or is the xmpp push and imap push significantly different in some way?

Mobile OS pushes on both iOS (APNS) and Android (FCM) work the same: push can only be initiated by the developers of an application. So, no third-party server can push an app without intermediation by the application developers. Scheme is this:

Service -> Push service -> APNS / FCM -> Applications

With XMPP, servers act as 'service' from the scheme above, then relay a push initiation to 'Push service', maintained by a client app developers, Push service relays information to a respective service by Apple / Google, who deliver push to an Application, which connects to Service (or does not, pushes can contain all necessary information for displaying in notification, but that's a story for another time).

With email, I'm not really familiar with how IMAP Push works, but the scheme must be the same: an email server must relay info to a push service maintained by app developers, in your case, K9 guys.

From what I was able to gather after reading wikipedia for 5 min, an IMAP server upon receiving an email sends info to some 'mail user agent'. From wikipedia it's not really clear, but it appears that is is supposed to work on end devices. In this case, it won't really work as 'push'.

Google (or any other email provider, like Protonmail, who have their own app) get around this because they control both email server and push server, so it's trivial for them to initiate a push when an email is received.

Perhaps Apple deserves some of the blame here? Is the protocol just too chatty?

My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.

Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.

But one could open and close a desktop XMPP app as well at arbitrary times. What is the difference?

The difference is control. A person knows that if he disables a desktop client, he won't be receiving any messages.

A phone user expects that messages would be displayed to him in notifications when received. One does not expect to be cut off communications because he had pressed a 'home' button, but it's what happens, and a user does not have any control to prevent it from happening.

How do Whatsapp et al. work differently on iOS than XMPP clients?

XMPP problem is that in classical way a client needs to resume a stream. But to work well on iOS, an app must synchronize a state.

WhatsApp is a heavily modified xmpp, and does just that. That's what it works so well. Such approach is way easier in a federated environment.