Newspaper subscriptions are a dying breed. Online news makes money from ads. To sell more ads, you have to sell more views or get sponsored content (native advertising)
It is in the interest of news companies to tell us things that we want to hear, or what a large group will want to hear.
Unfortunately I’m finding this to be the case with much of TC’s content. A shame because there used to be genuinely interesting commentary all over the sure not long ago.
As a Maemo user that recently got both Android and iOS devices for software porting and testing: hardly. When it comes to reliability, glitches, etc. they're pretty comparable, with Android being slightly better.
However, I have only seen Replicant, AOSP and LineageOS. What you get packaged by your hardware vendor might be worse.
How about per-app VPNs with Apple Configurator, i.e. no MDM?
If Apple wants to support privacy, it should be possible to route one or more apps to a dedicated VPN where their traffic can be restricted and monitored closely.
Doubtful as they'd get on the bad side of a lot of governments doing that. VPNs are something that the upper brass are aware about and will make a fuss about if they're added. It's a high profile security measure.
In some countries, enabling an IKEv2 VPN on iOS will cause any app (including Apple Mail, Safari or even Settings) to crash the first time it uses the active VPN.
Those countries may be exploiting an iOS bug, by injecting packets into IKEv2 streams. Observed for more than a year, still present in iOS11. This doesn't happen with OpenVPN, possibly because it's easier to break OpenVPN wire traffic without compromising the phone OS.
The point is: governments can already use VPN traffic as justification for exploiting targeted devices, they don't need any help from Apple. Android has many options for network security, why should Apple be hamstrung by hypothetical governments who will break iOS anyway? Apple customers are paying a premium and still being needlessly exposed on insecure WiFi networks.
Millions of Apple users would benefit (motivating device purchases!) if Apple removed their VPN dark patterns from iOS, e.g. make it easy to enable Always-On VPNs which don't leak unprotected packets.
It's a way better idea than periodic polling, which is the current behaviour when the mail server operator doesn't collaborate directly with Apple to implement their push notifications.
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?
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.
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.
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.
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.
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.
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.
I'd say performance is better than iOS11 at this point. There's still a lot of rough edges and I suspect they have a debug build released at this point. I think the final build will be really good.
For phones specifically, only a small portion of people are using iPhones older than 5 years. So basically the vast majority of active iPhones are supported by iOS 12.
There’s probably a decent number of active iPads that can’t run this iOS version but that’s probably for the better since the older ones would probably be too slow.
Oh the irony. I updated to iOS 12 after reading this post, and now I cant paste quotes into the response box from reply view on HN from my iPhone SE. It's pretty obvious the smaller phones have been abandoned at this point.
34 comments
[ 2.2 ms ] story [ 345 ms ] threadNewspaper subscriptions are a dying breed. Online news makes money from ads. To sell more ads, you have to sell more views or get sponsored content (native advertising)
It is in the interest of news companies to tell us things that we want to hear, or what a large group will want to hear.
However, I have only seen Replicant, AOSP and LineageOS. What you get packaged by your hardware vendor might be worse.
How about per-app VPNs with Apple Configurator, i.e. no MDM?
If Apple wants to support privacy, it should be possible to route one or more apps to a dedicated VPN where their traffic can be restricted and monitored closely.
Those countries may be exploiting an iOS bug, by injecting packets into IKEv2 streams. Observed for more than a year, still present in iOS11. This doesn't happen with OpenVPN, possibly because it's easier to break OpenVPN wire traffic without compromising the phone OS.
The point is: governments can already use VPN traffic as justification for exploiting targeted devices, they don't need any help from Apple. Android has many options for network security, why should Apple be hamstrung by hypothetical governments who will break iOS anyway? Apple customers are paying a premium and still being needlessly exposed on insecure WiFi networks.
Millions of Apple users would benefit (motivating device purchases!) if Apple removed their VPN dark patterns from iOS, e.g. make it easy to enable Always-On VPNs which don't leak unprotected packets.
Not having imap mail push on iOS is annoying to say the least.
https://news.ycombinator.com/item?id=9901686 (HN thread where Rob @ FastMail dives in depth why push notifications are superior to IMAP IDLE)
https://stackoverflow.com/questions/17262511/how-do-ios-push... (How do iOS Push Notifications work?)
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?
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.
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.
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.
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.
> 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.
Apple journalists don't and happily chime on about how great it is without understanding the realities.
I'd say performance is better than iOS11 at this point. There's still a lot of rough edges and I suspect they have a debug build released at this point. I think the final build will be really good.
There’s probably a decent number of active iPads that can’t run this iOS version but that’s probably for the better since the older ones would probably be too slow.
SE is a good form factor. Do customers need to buy a 5S on eBay instead of SE from Apple Store, to get Apple support for a small phone with iOS12?