
iOS 12 is all about making your iPhone work better - casabarata
https://techcrunch.com/2018/06/25/ios-12-is-all-about-making-your-phone-work-better/
======
some_account
This reads like an apple press release, with no critical thought whatsoever.

~~~
nojvek
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.

------
walterbell
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.

~~~
jjcm
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.

~~~
walterbell
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.

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

------
tmikaeld
Have they added IMAP Idle support yet?

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

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

~~~
seba_dos1
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.

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

~~~
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.

------
arrty88
iOS 11 is still better than Android

~~~
seba_dos1
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.

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

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

~~~
joezydeco
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.

------
aphextron
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.

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

