iOS 12 is all about making your iPhone work better | Hacker News Reader

iOS 12 is all about making your iPhone work better

techcrunch.com

26 pointscasabarata33 comments

Can we have a VPN button in Control Center?

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.

Who knows? Try asking Apple directly.

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.

Well I'd hope it wouldn't make it work worse.

Have they added IMAP Idle support yet?

Not having imap mail push on iOS is annoying to say the least.

That would require keeping a connection open to the mail server 24/7 which is a bad idea.

Why a constant one? Why not on WiFi only? Push notifications also require a constant connection as well, I think?

Push notifications are more efficient, as iOS manages the persistent connection to receive push notifications versus your application long polling.

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?)

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.

Way better by what metric? Periodic polling is going to be better for battery than keeping a connection open 24/7.

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?

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.

iOS 11 is still better than Android

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.

You must mean better in that Apple is still locking you out of hardware you own (e.g. NFC).

This reads like an apple press release, with no critical thought whatsoever.

Well a lot of journalism recently is like that.

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.

"Newer" iPhone because your older iPhone will be screwed.

Aren’t they supporting iPhones all the way back to the 5s with iOS 12? That’s way better than any competitor can claim.

Have you tried to use one of these old devices they claim to support?

Apple journalists don't and happily chime on about how great it is without understanding the realities.

I'm running 12Beta2 on my 5S.

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.

This is a beta release, so I'd expect some bugs at this point.

iPhone SE has so many bugs with iOS11, compared to iOS10, I was hoping this would be fixed in iOS12.

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?

I thought Apple was still committed to the SE series. Just not updating it as often as the main line.

Reply on news.ycombinator.com