
iOS7 is not about flat - davidbrai
https://medium.com/p/2aa9dba0d202
======
leokun
It's funny how all these things that have been in Android forever and were
criticized for their battery draining powers are suddenly the latest and
greatest reason why Apple phones are the best. It's just the way it goes,
remember 7 inch tablets? Worst thing ever and everyone lists reasons why.
Until Apple made one. Marketshare means everything! Until Android stole that,
now market share is a false signal. King of profits! Until Samsung took that
too. Keep moving that goal post.

~~~
xutopia
You forget a few things. On Android can't the app just run forever and decide
on its own how often to poll the servers? This is a different thing. The OS
decides when to schedule things if the app supports it.

Also battery life has improved a great deal since the first Android or iPhone
device came out. What may have been true years ago isn't necessarily an issue
anymore.

~~~
arron61
You mean like using Android's SyncAdapter and setting inInexactRepeating()?
Android has supported this basic type of background scheduling since the start
of time. The main difference is that Android you can do more - which can be
abused. And their solution for abuse is a battery monitor that allows you to
see which app is using the most battery. In a way you can say Android is more
superior/powerful or you can say that the iOS is more limiting and thus
potentially more user friendly.

~~~
cpeterso
Unfortunately, I think many Android app developers either don't know or care
about "API abuse". When my Android phone is sitting "idle" with the display
off, adb logcat still shows _tons_ of debug logging from apps doing more work
than they should. I like the freedom that Android gives developers, but, as
you suggest, I think iOS provides a better user experience.

I can think of many ways Google could fix some of this bad behavior by
throttling apps running in the background.

~~~
jordanthoms
Yeah, some apps suck on Android, leave unnecessary services running etc. I
uninstall them, and leave a review stating why.

------
janjongboom
Firefox OS already uses the same model, push notifications will fire up the
application, the application can then decide to create a notification, to
update the internal cache to reflect the latest changes; it's called the
Simple Push API[1]. It can also wake up the application every X minutes to
pull the data (Alarms API[2]) and do the same thing.

[1] [https://developer.mozilla.org/en-
US/docs/WebAPI/Simple_Push](https://developer.mozilla.org/en-
US/docs/WebAPI/Simple_Push)

[2] [https://developer.mozilla.org/en-
US/docs/WebAPI/Alarm](https://developer.mozilla.org/en-US/docs/WebAPI/Alarm)

~~~
njs12345
The model is fairly similiar on Android too, for what it's worth.

~~~
013
This seems like something Apple would want to patent. I wouldn't be surprised
if we saw some new Apple Vs. Android, Apple Vs. Mozilla lawsuit about
"background fetching".

~~~
bobz
Android has had "Sync Adapters" since the beginning, a very cool and powerful
framework that allows apps to piggy back off each other's data connections,
reducing the number of times the cell modem needs to be fired up for
background fetches.

Not a new concept, I'm sure the patent battle lines are already well drawn.

~~~
guelo
SyncAdapters were added in Android 2.x

------
calinet6
Just what I want: every developer of the 200 apps I have on my phone thinking
theirs is the most important one and trying to take over my entire phone every
20 minutes to background process.

The self-centered perspective of the article is even slightly disturbing,
basically implying that their app needs to pre-load data because it's so
important and can't make the user wait. A common perspective, sure, but this
is the tragedy of the commons in app form.

This will require some careful government.

~~~
joshdance
That's the thing. It will be in the background. You won't even notice.

~~~
untog
But we've been told for years that Android is fundamentally broken because it
allows this. I guess everyone changed their mind?

~~~
glhaynes
As has been pointed out elsewhere in this thread, it's not exactly the same:
iOS is still much more strict about what runs and when. Apps get woken up only
when the system decides to wake them up, and it decides based on current
battery life/power state, other system activity level, and the user's usage
patterns of the app. Then, once woken up, apps get a limited time to run.

~~~
DannyBee
Android does this as well, so I guess like the guy you are responding to, i
don't see a real difference.

~~~
glhaynes
To my understanding, Android offers something similar _and_ also allows apps
to wake up arbitrarily in the background. Reasonable people can disagree on
whether the latter ought to be an option or not (or, perhaps even more
reasonably, can be happy that both types of devices exist so people can choose
which they'd prefer). But the complaint regarding Android was that it let
poorly-behaved apps drain significant amounts of battery in the background and
it's not true that Apple has now added that possibility.

~~~
DannyBee
So you know all the technical implementation details of both?

Or are you comparing random API doc material and actual technical details?

Apple says a lot of things, not all of them turn out to be technically
accurate.

For example, do you _know_ it actually will not allow poorly behaved apps to
drain battery, or is this just an assumption based on what apple says will
happen?

What always happens in these discussions is people say "apple's docs say x, so
it must be like x". Quite often, when people actually go and look at how it
operates, it isn't like x at all.

~~~
glhaynes
The discussion was around architecture. Of course it may not behave as
intended when actually implemented because of bugs. Or because of Apple
outright lying in their communications. Sure, those are possibilities, but
they're irrelevant to architectural criticism.

~~~
DannyBee
But you have no real architecture details, only a small number of bullet
points on how it's supposed to behave and a simple but not horribly
descriptive API. That isn't an architecture, that's just marketing materials.
They are completely irrelevant to anything.

Given only that, you cannot possibly make informed commentary on how it will
behave in practice, you are just parroting a story.

In particular, you said "it let poorly-behaved apps drain significant amounts
of battery in the background and it's not true that Apple has now added that
possibility."

You cannot possibly assert this with any real details to back it up, because
you do not know how this architecture operates past "apple says they won't be
woken up enough or run long enough to drain battery". If you have the actual
details necessary to back this statement up, please add them.

Unless you are talking at such an abstract level where everything that matters
is an implementation detail, in which case it's very easy to design perfect
architectures that have no problems!

We don't believe people when they make crazy claims about crypto, without
seeing the actual details and implementations. We should not trust Apple _or_
Google's marketing points about their architectures when trying to make
"architectural criticism".

In the end, if you really believe "architectural criticism" is possible
without actual detailed design info, carry on.

But to me, that's a worthless discussion based on what are essentially talking
points.

In any case, all that matters in the end is performance in the field, so this
entire discussion is mostly technical masturbation until real users have
phones in hands.

~~~
glhaynes
I'm not sure why you think I have no real architectural details. What do you
know about what I know?

Regardless, I think your pedantry is based on a statement I intended to be
read in a less formal fashion than you're choosing to read it. When I said
that it was not a possibility for poorly-behaved apps to drain significant
amounts of battery under iOS 7, I didn't mean that it was absolutely
impossible _under any and all circumstances including system bugs, unforeseen
architectural weaknesses, or gamma ray induced bitflips_. People say "Linux
uses memory protection to keep processes from corrupting the memory of other
processes" and we all understand that they don't mean that it's _literally
impossible_ for memory problems to ever happen.

Likewise, my point was that it is generally true that iOS 7 doesn't allow apps
to wake up as often as they want. That is a design goal behind its
architecture. Doubtlessly, neither its architecture nor its implementation are
perfect — I'd be surprised if it were utterly _impossible_ for an app to end
up running whenever it wants in the background. But it'd be boorish to belabor
that point.

The original post that has led to this discussion was saying that Android has
been criticized for being designed to allow apps to run in the background
arbitrarily and now iOS has been redesigned to allow that too. That's not
true. And the conclusion of hypocriticalness that was drawn from this faulty
premise was untrue.

~~~
DannyBee
"I'm not sure why you think I have no real architectural details. What do you
know about what I know? "

They do not appear as supporting details of your argument, so ...

Again, you are trying to make it seem like pedantry and that i am addressing
only extreme cases or bugs , and my point is you have offered no details to
support any part of your argument.

"Likewise, my point was that it is generally true that iOS 7 doesn't allow
apps to wake up as often as they want. "

I quoted your statement about battery life, and said you have offered no
details to show this to be the case. Rather than offer details to refute that,
you have now instead said "I said something different".

I'd appreciate it if you would stick on point and address my contention that
you have not offered details about this statement:"it let poorly-behaved apps
drain significant amounts of battery in the background and it's not true that
Apple has now added that possibility."

Please offer details to back this up. IE what architectural details you know
that you believe make it the case that apple has not added the possibility of
apps using large amounts of battery in the background.

If the details are "apps can't arbitrarily wake themselves up", then your
statement about the possibility of background apps draining battery life is
easily shown to be wrong, and i'll be happy to refute it for you. If it is
something else, i'd love to hear it, so i know exactly what argument i am
addressing.

Let's stay with this one part of the argument, please.

------
kunle
I think this speaks to something really important that's rarely touched on
directly; people hate waiting for software. I despise it. Many ordinary
consumers use their phones as a way to solve "waiting" in general (just look
what happens when you have a bunch of people in line: they take out their
phones to pass the time).

To date, the way most developers solve this (Aside from optimizing for
performance where possible) is to use loading indicators of some kind, but
that's a bandaid at best. Some work will definitely have to be done to manage
the battery drain concerns that can arise from this, but more time spent in
your app actually doing stuff, and less time waiting for the app to update
will be a huge gift of time back to users (basically 2 - 5 seconds every time
you open an app is about to be given back to you). Add that up over many app
opens every day over many days every year; its substantial.

~~~
consultant23522
Yeah, but let's be honest. It's not real productive time. It's Facebook,
Twitter, and Candy Crush.

~~~
kunle
Agreed - definitely not real productive time. Most of the time it's just
entertainment (which makes sense if you consider that no one ever has any idea
how long they'll be waiting for whatever it is they're waiting for).

------
MProgrammer
Apple’s guidelines have _always_ said that developers should avoid splash
screens ‘or other startup experience.’ That's nothing new, but many developers
ignore it anyway.

~~~
potatolicious
Easier said than done. This is trivial for single-purpose apps like Calculator
or Weather, where it's easy to predict what the post-launch UI will look like
(hint: there's only one screen...)

For much larger apps the "fake screenshot" is harmful. Take the Facebook app
for example - what should the "fake screenshot" be? iOS does not differentiate
between a completely fresh launch vs. a simple restore from background, and
will show the same image no matter what.

So now you're in a situation where you've presented your users with a
fake/blank Facebook stream, but really they were restoring to a photo they
were looking at. Oops.

Or hell, do you even know if your user's logged in? Would be a shitty
experience to show them the fake/blank stream but suddenly pop them back to
the signup/login page no? What if they _are_ logged in? Would be a shitty
experience to show them the signup/login page and suddenly yank _that_ out
from under them.

This whole business is a shitty solution to a shitty problem: apps take
forever and a day to launch.

~~~
raphael_o
Background fetch actually provides a solution this exact use case. If the user
uses your app enough for iOS to let you run in time, the app should be able to
"get ready" before the user opens it.

~~~
potatolicious
How so? You can know all the state you want, but iOS is still going to display
that one static image. If the user is returning from background into a photo
gallery, it's still going to show your default image. If the user is opening
the app directly into a conversation, it's still going to show your default
image.

I don't see how backgrounding solves any of this.

------
techtalsky
Sounds like another way for apps to drain my precious battery life.

~~~
draugadrotten
...and prefetch will drain the data plan by downloading information that may
never be needed.

~~~
r00fus
I'm sure data-sippers and battery-hawks can configure settings it so it's only
when on wifi, or when-charging (or both).

Given about 90%+ of mobile users have access to a wifi point + charger on a
nightly basis, this seems reasonable.

I'd mainly use it for podcasts and Audible - keep my casts and books updated
so I don't have to sit in the car for 5min downloading the daily selections.

------
greenlakejake
The background behavior in iOS 7 is a great improvement but can't really be
described by those of us who are still under non disclosure agreement. Beyond
that there are lots of goodies for developers that have been added to iOS
APIs.

~~~
xutopia
Wait... there is still a developer NDA?

------
MichaelGG
Forgive my complete ignorance on the topic: Can't you just push down the
information the customer needs? I get that it might be more difficult to use
the push API but could an app theoretically have achieved the same experience
via push?

Also, I'm not quite sure API enhancements are what a release is "about".
Admitting that the crazy 3D designs were over the top and adopting a design
_similar_ to Metro and Android Holo seems like a rather large shift for Apple.

~~~
potatolicious
Sort of. Yes and no. You can bundle whatever data you want on a push
notification, but there are some restrictions:

\- Size limits. It's a push notification, so the amount of payload you can
attach is pretty limited. Not the whole conversation history of a chat, for
example.

\- Lack of guarantees or SLA means using it this for time-ordered information
is a bad idea. For example, assembling a chat history from a series of pushes
is generally a recipe for awfulness. Pushes are not guaranteed to arrive at
all, nor arrive in a certain order.

\- No sensitive information in pushes, since it's (mostly) transmitted in the
clear. Apple recommends payloads be IDs and such and the human-readable
component be general. "You have a new message!" rather than "You have a new
naughty pic from Jane!".

Long story short, when your app wakes due to a push notification it's almost
always smarter to fetch the canonical state over the networking than try to
piece it together from the push payload. This incurs a pretty hefty user-
visible delay and results in a shitty experience.

~~~
MichaelGG
Thanks for the excellent details. I thought that email also used push (on all
platforms). Is that special cased? Or a different type of push?

------
arpit
"Apple’s guidelines for iOS7 developers actually demand we avoid splash
screens ‘or other startup experience.’"

This was an interesting line. I had a debate with my designer friend about
this who pointed out that this wasn't new. Turns out, the line about no splash
screens is part of the Human Interface Guidelines today. The splash screens
seems to have been a community driven interface decision rather than an Apple
one.

------
cromwellian
IIRC, even J2ME MIDP had this feature on feature phones, see
[http://www.oracle.com/technetwork/systems/pushreg-156557.htm...](http://www.oracle.com/technetwork/systems/pushreg-156557.html)

Circa 2002.

Everything old is new and magic and amazing now folks!

~~~
threeseed
And I could have implemented this on any computer going back 30 years.

What exactly is your point ?

~~~
cromwellian
What you "could" have done, and what was actually done are two different
things. Both J2ME and Android had this facility for a long time. Apple, like
Microsoft, dragged their feet and badmouthed this feature, then finally ended
up implementing it. Now we will be told it is amazing and magical. And of
course, the usual excuse will be proffered "Apple held back on it until _it
could be done right_".

Remember 7inch tablets would need you to file down your fingers to use? Or
that "if you see a task manager, they blew it" and low and behold, a task
manager appeared on iOS.

I'm all for Apple implementing these features, but I'm tired of them
badmouthing things they don't have, only to trot them out as amazing once they
do have them.

Microsoft used to badmouth HTML5 Canvas, then when they finally got a great
implementation in IE9, all of a sudden, its WebGL that sucks.

Don't badmouth features just because a competitor has them and you don't,
badmouth them if they are indeed, bad features.

------
grimtrigger
TLDR: iOS7 allows for background fetching when the app is closed. Allowing for
smaller wait times when users open up an app.

Is there any way for users to manage this behavior? If not it seems ripe for
abuse or just plain laziness.

~~~
tinylittlefish
A developer can't just set a background fetch interval in iOS7 and have the
app fetch at that interval (i.e. fetch every hour). Rather you can set your
app to background fetch, and when it fetches is at the mercy of the OS.

The OS tries to be smart about it, lumping fetches together when it can, and
noticing things like when the user opens the app typically.

So say the user launches GREAT WEATHER app app normally at 8 am, the OS
notices and performs a background fetch a few minutes before (for example).

------
blago
"Even a five second delay"

Optimizing response times seems like a better, more universal approach.

~~~
raphael_o
Agreed, especially loading time to encourage repeat use.

------
jliptzin
IMO iOS 7 is a textbook case of fixing something that's not broken.

~~~
eddieroger
Have you used it? Are you familiar with what it's doing or how it's doing it?
Or just immediately dismissing it for no reason? For me, as a developer, it's
fixing tons of things that were broken and allowing me to do lots of amazing
new things with my apps that I haven't yet - while still letting the user
dictate behavior and usage.

