[seba_dos1]

Uhmm... how exactly?

Idle, open connection won't suck your battery at all, it's just an open socket sitting somewhere in the RAM. The only problem with it is having to send keepalives due to broken NATs being prevalent that can quietly close your connection with you having no chance to know that until you decide to send something through it. Anyway, keepalive pings are way easier to process than a complete poll and will send your processor and baseband back into sleep much quicker. Also, on most networks you can actually keep a connection open for much longer than 15 minutes, and when the network is so horribly broken that you can't, you can always fallback to polling.

Both Android and iOS already employ various techniques for dealing with keepalive timeout calculation because... guess what... that's exactly how their push notification systems are working.

You gain better battery life from rarer pings, less roundtrips and easier to process responses. Periodic polling is absolutely the worst for your battery - isn't it just obvious?

[eridius]

If keepalive pings weren’t a thing, you’d have a point, but you admitted they are. The keepalive pings have to happen at least every 2 minutes I think (and usually more frequently than that) as I believe 2 minutes is a common timeout for this sort of thing. Meanwhile polling is every 15 minutes at the most frequent (or 30, or every hour, etc). This means it fires up the radio less often, which means better battery.

I’d also guess the OS tries to schedule these fetches to coincide with the radio already being on as they don’t have to be precisely timed.

[seba_dos1]

Keepalive timeout negotiated by Android on one of my test devices is usually between an hour or two. And as I said - if you're on a particularly crappy network that gets keepalive < 15 minutes, you just fall back to polling. You can only gain battery life, not lose.

After all, if your e-mail provider cooperates with Apple, you get your mail fetched by... a constantly open, 24/7 push notification service connection instead of IMAP polling. Which means better battery.

Keepalives are also scheduled by the OS - that's one of the most basic power saving strategies. I mean, it has been already implemented in 2009 in Maemo, which wasn't even tiny bit as restrictive about networking stuff as Android and iOS are.

[eridius]

The OS already has the push notification connection open, so having more stuff go over it is effectively free (when considering the case where there's no new data, it's literally free, and when there is new data it's presumably no less efficient than fetching the data via another mechanism).

In any case, my inclination here is to believe that Apple doesn't have IMAP Idle because it drains more battery than fetching every 15 or 30 minutes, as I can't think of any other reason why Apple would refuse to implement it (and they've implemented it already in desktop Mail.app, so it's not just laziness). And what's more, I'm inclined to believe Apple has actually tested this out rather than just assuming it to be the case. Apple cares more about power efficiency than any other major software vendor I know of, and email is such a fundamental piece of functionality for the device, if they could actually get better power efficiency by implementing IMAP Idle, they'd have done that years ago.

Now, it's certainly possible that on some networks, keepalive pings could be infrequent enough that IMAP Idle would not use any more power than fetching. But having that be true for some networks doesn't really matter because Apple's not likely to implement a mode that says "use IMAP Idle if it's efficient to do so, otherwise fetch" due to the potential user confusion.

In an ideal world, Apple would standardize some way for mail servers to deliver push notifications to clients (and what's more, do it in a way that allows 3rd-party clients to register to receive these pushes too, not just the built-in Mail.app¹). I don't know why this hasn't happened; maybe nobody cares enough, or maybe Apple can't convince Google to care about having push support for Mail.app² and if they can't convince Google then it's not really worth pursuing as Google accounts for such a huge percentage of the world's email accounts at this point. However, I do know it's possible for mail servers to support Mail.app push notifications, as FastMail rolled out support for it some time ago³.

¹I actually use a 3rd-party client called Spark that gets push email, but to do so, Readdle actually runs a server themselves that logs into my mail account, uses IMAP Idle, and sends the client a push every time new messages come in. This is of course a potential privacy and security violation, though I've chosen to trust Readdle and trust that they abide by their privacy policy (which, among other things, states that they throw away the email data after delivering the push notification, and don't use this data for any other purposes).

²I have to assume this is Google deliberately making the Mail.app experience inferior in order to convince people to use their own Gmail client.

³FastMail had to actually send some engineers to Infinite Loop to talk to Apple engineers directly in order to figure out how to do this integration. I'm really curious what the technical details are here.

[seba_dos1]

How is "use push notifications if it's an e-mail provider that worked directly with us, otherwise poll" any less confusing? What's more, you get the same behaviour with push notifications already - if you're on a really crappy network, you're likely to not get your notifications instantly due to having too long keepalive timeout until OS adjusts.

The answer it simple: with IMAP Idle, you could do push notifications directly from your mail server to your phone without Apple as a middle man, and one of the things Apple cares about more than power efficiency is having full control over their platform. There's no real technical reason for it to be so screwed up as it is now.

[eridius]

It's less confusing because the fetch vs push preferences are per-account, so you can see right in preferences which accounts use push and which use fetch (and what the fetch intervals are, as that's also per-account).

> What's more, you get the same behaviour with push notifications already - if you're on a really crappy network, you're likely to not get your notifications instantly due to having too long keepalive timeout until OS adjusts.

In all my years of using iOS I've never noticed push notifications becoming noticeably delayed in situations where I still have a network connection. Maybe Android sucks at this, I don't know, but iOS has always been really good about delivering push notifications quickly if my device is reachable.

[seba_dos1]

As I also said earlier, most networks these days aren't so crappy, so with well-working timeout adjustment algorithm you may never notice it. Also, with increasingly common mobile IPv6 connections, it's not an issue anymore.