10 ms·

iOS7 is not about flat

90 points by davidbrai 13y ago

techtalsky 13y ago
Sounds like another way for apps to drain my precious battery life.
- draugadrotten 13y ago
  ...and prefetch will drain the data plan by downloading information that may never be needed.
  - r00fus 13y ago
    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.
  - mitchty 13y ago
    The app autoupdate will do that on its own if you're not careful about disabling using 3g for downloads. That said I also played a ton of the radio last month too but I wish I could turn 3g for the radio stuff and not the rest instead of toggling it all the time.
- deleted 13y ago
  [deleted]
- iwasakabukiman 13y ago
  It's based on usage. For example, if I use an HN reader a lot, that will get frequent updates in the background. But the RSS reader I haven't opened in a week will get less/no background updates since the OS knows I'm not using it too much.
- iMark 13y ago
  I can imagine scenarios where it might increase battery life - prefetching means that you won't be staring at the battery hungry screen while waiting on data to load, for example.
- eddieroger 13y ago
  It will not. First, it doesn't do this by default. Second, it does it based on your patterns, and even then it will pool connectivity to that apps aren't just firing off requests whenever they see fit (in other words, keeping the radio spun down as much as possible). Lastly, you can disable it. Battery saved.
- cheald 13y ago
  This sort of behavior is one of the primary causes of battery drain on Android systems, so yeah, it won't at all surprise me when certain apps start getting fingered as battery hogs.
- deleted 13y ago
  [deleted]
- runjake 13y ago
  You'll be able to configure it both globally or by individual app. The settings are in Settings->General->Background App Refresh on iOS 7.
- DannyBee 13y ago
  Don't worry, HN is about to tell you how apple has magically solved this problem in exactly the same way android did, but how it's different because apple did it!
MProgrammer 13y ago
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.
- raphael_o 13y ago
  Right, not new to iOS 7 but this time Apple took the time to make a nice mock of what we shouldn't do!
  - fredoliveira 13y ago
    Developing for iOS without going through the UX guidelines is a pretty good way to make an app that will not endure the recklessness of the App Store business.
- potatolicious 13y ago
  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 13y ago
    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.
grimtrigger 13y ago
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 13y ago
  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).
- raphael_o 13y ago
  There is a new settings screen in iOS7 called "Background App Refresh" (under General) which allows users to disable app refreshes altogether or to turn off the ability for specific apps
- jasonlotito 13y ago
  It's mentioned elsewhere in this thread, but I believe after you posted. Basically, the apps don't control when they can do their background fetching. It's up to the OS, which uses your usage patterns to determine how often backgrounding can occur. So, beyond the setting where you can disable this functionality, the intent is you use your apps like normal and it adjusts itself to your patterns.
- blueski 13y ago
  I understand iOS7 will govern abuse/excessive background fetching. But seems unfortunate it can't cater for legitimate scheduled background fetching - e.g. updating all my podcasts every day at 8am. In this case my phone would be plugged in anyway, so the battery concern is moot - there are other cases where I'd accept a substantial battery drain to run a process I've approved. From other comments it sounds like iOS might figure out I like to listen to podcasts en route to work and learn to pre-fetch. But I don't want to rely on it noticing this or wait for it to learn. I have a mix of Android and iOS and it's for this use case that Android handles all my podcasts.
janjongboom 13y ago
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 13y ago
  The model is fairly similiar on Android too, for what it's worth.
  - 013 13y ago
    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 13y ago
      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 13y ago
        SyncAdapters were added in Android 2.x
    - pkaler 13y ago
      Already patented. You even have the choice of which patent you would like to infringe: - Apple: http://www.faqs.org/patents/app/20100227632 - RIM: http://www.uberphones.com/2010/12/rim-sues-kik-patent-infringement/ - MS: http://www.microsoft.com/en-us/news/press/2009/mar09/03-25AXIGENPR.aspx
jliptzin 13y ago
IMO iOS 7 is a textbook case of fixing something that's not broken.
- joshdance 13y ago
  Follow that logic and we would never put out new features on anything. Not broken, don't improve.
- logicallee 13y ago
  The transitions to mainframes, Personal Computers, laptops, mobile phones, smartphones, are textbook cases of fixing something that wasn't 'broken'. I think if you're not careful the future will creep up on you without fixing anything.
- eddieroger 13y ago
  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.
  - HNLogInShit 13y ago
    Like what? Background fetching is great. What else? For the end user, iOS 7 is a UI fiasco and a massive regression. Spindly, illegible text. A ridiculously degraded calendar, which no longer shows a concise list of a day's appointments but instead forces you to scroll through every hour of the day, hunting for whatever it is you have scheduled. "Transparency", a stupid UI idea that came and went a decade ago because it SUCKED. Why do I want to see the crap BEHIND the UI I'm trying to use? Oh, but I don't really see it; I see a mottled mess of a background, because it's "blurred." This of course renders text illegible in many cases, because the background may be any combination of colors. There are the tiny, undefined control areas. The invisible controls. The unresponsive controls. The camera icon on the lock screen is a great example of Apple's UI stupidity (which predates iOS 7). People are still trying to tap this thing, because Apple inexplicably doesn't put an ARROW above it to show you WTF you're supposed to do. Why? There's no excuse for it.
calinet6 13y ago
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.
- deleted 13y ago
  [deleted]
- plorkyeran 13y ago
  Apps don't actually have any control over when they get woken up for background fetch (you can set a minimum interval, but it's very much a minimum), and the more work you do when you get woken up the less often it happens. In practice for occasionally used apps it seems to happen once a day, and while you're on wifi and charging if possible.
- joshdance 13y ago
  That's the thing. It will be in the background. You won't even notice.
  - untog 13y ago
    But we've been told for years that Android is fundamentally broken because it allows this. I guess everyone changed their mind?
    - uptown 13y ago
      Maybe stop worrying what "everyone" is saying, and form your own thoughts about things?
      - untog 13y ago
        I wasn't particularly worried about it. More noting the usual pattern of "<x> is wrong until Apple does it". Background apps, flat design...
MichaelGG 13y ago
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.
- axxl 13y ago
  Unfortunately not, Apple's push API supports a max notification payload size of 256 bytes.
- potatolicious 13y ago
  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 13y ago
    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?
- raphael_o 13y ago
  Although you're right that iOS7 also introduces silent push notifications to wake up the app in the background to let it fetch what's needed.
blago 13y ago
"Even a five second delay" Optimizing response times seems like a better, more universal approach.
- raphael_o 13y ago
  Agreed, especially loading time to encourage repeat use.
kunle 13y ago
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 13y ago
  Yeah, but let's be honest. It's not real productive time. It's Facebook, Twitter, and Candy Crush.
  - kunle 13y ago
    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).
- Angostura 13y ago
  People hate waiting for software, but they hate unexpectedly running out of data-plan capacity even more. Until now I've known that pretty much* the only time an app will be using data is when I'm looking at it. *There are a few exceptions, such as Mail which the average user understands.
leokun 13y ago
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 13y ago
  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.
  - pat2man 13y ago
    iOS will actually disable these features if the battery is getting low. It will also group them together so that the wireless chips are on as briefly as possible.
    - danieldk 13y ago
      iOS will actually disable these features if the battery is getting low. Like Battery Saver? http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-making-it-last http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-...
      - r00fus 13y ago
        Great - another option. I prefer my phone deciding when to do this automatically (and maybe an option to disable it so I can run it into the ground if absolutely necessary).
        13y ago
arpit 13y ago
"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.
greenlakejake 13y ago
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 13y ago
  Wait... there is still a developer NDA?
HNLogInShit 13y ago
Uninformative and inappropriate title. The entire article is about "background fetching", and the title should reflect that. Also, Apple has always advised against "splash screens", and instead recommended that you make a fake-screen bitmap so it looks like your app has already launched. This is stupid for two major and related reasons: 1. When the user starts tapping on controls on your fake screen and they don't work, it looks like your app is defective and locked up. 2. The screen will show outdated and inaccurate information until the app is actually running and replaces the fake screen with the real one. iOS 7 is rife with examples of this screen-shot problem. iOS has always (as far as I know) taken a snapshot of the app's screen before it goes into the background, which it then displays when the app returns. This often shows wrong information or even the wrong orientation, long enough to perplex the user.
cromwellian 13y ago
IIRC, even J2ME MIDP had this feature on feature phones, see http://www.oracle.com/technetwork/systems/pushreg-156557.html http://www.oracle.com/technetwork/systems/pushreg-156557.htm... Circa 2002. Everything old is new and magic and amazing now folks!
- threeseed 13y ago
  And I could have implemented this on any computer going back 30 years. What exactly is your point ?
  - cromwellian 13y ago
    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.

90 points by davidbrai 13y ago

techtalsky 13y ago

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

draugadrotten 13y ago
...and prefetch will drain the data plan by downloading information that may never be needed.
- r00fus 13y ago
  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.
- mitchty 13y ago
  The app autoupdate will do that on its own if you're not careful about disabling using 3g for downloads. That said I also played a ton of the radio last month too but I wish I could turn 3g for the radio stuff and not the rest instead of toggling it all the time.
deleted 13y ago
[deleted]
iwasakabukiman 13y ago
It's based on usage. For example, if I use an HN reader a lot, that will get frequent updates in the background. But the RSS reader I haven't opened in a week will get less/no background updates since the OS knows I'm not using it too much.
iMark 13y ago
I can imagine scenarios where it might increase battery life - prefetching means that you won't be staring at the battery hungry screen while waiting on data to load, for example.
eddieroger 13y ago
It will not. First, it doesn't do this by default. Second, it does it based on your patterns, and even then it will pool connectivity to that apps aren't just firing off requests whenever they see fit (in other words, keeping the radio spun down as much as possible). Lastly, you can disable it. Battery saved.
cheald 13y ago
This sort of behavior is one of the primary causes of battery drain on Android systems, so yeah, it won't at all surprise me when certain apps start getting fingered as battery hogs.
deleted 13y ago
[deleted]
runjake 13y ago
You'll be able to configure it both globally or by individual app. The settings are in Settings->General->Background App Refresh on iOS 7.
DannyBee 13y ago
Don't worry, HN is about to tell you how apple has magically solved this problem in exactly the same way android did, but how it's different because apple did it!

MProgrammer 13y ago

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.

raphael_o 13y ago
Right, not new to iOS 7 but this time Apple took the time to make a nice mock of what we shouldn't do!
- fredoliveira 13y ago
  Developing for iOS without going through the UX guidelines is a pretty good way to make an app that will not endure the recklessness of the App Store business.
potatolicious 13y ago
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 13y ago
  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.

grimtrigger 13y ago

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 13y ago
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).
raphael_o 13y ago
There is a new settings screen in iOS7 called "Background App Refresh" (under General) which allows users to disable app refreshes altogether or to turn off the ability for specific apps
jasonlotito 13y ago
It's mentioned elsewhere in this thread, but I believe after you posted. Basically, the apps don't control when they can do their background fetching. It's up to the OS, which uses your usage patterns to determine how often backgrounding can occur. So, beyond the setting where you can disable this functionality, the intent is you use your apps like normal and it adjusts itself to your patterns.
blueski 13y ago
I understand iOS7 will govern abuse/excessive background fetching. But seems unfortunate it can't cater for legitimate scheduled background fetching - e.g. updating all my podcasts every day at 8am. In this case my phone would be plugged in anyway, so the battery concern is moot - there are other cases where I'd accept a substantial battery drain to run a process I've approved. From other comments it sounds like iOS might figure out I like to listen to podcasts en route to work and learn to pre-fetch. But I don't want to rely on it noticing this or wait for it to learn. I have a mix of Android and iOS and it's for this use case that Android handles all my podcasts.

janjongboom 13y ago

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 13y ago
The model is fairly similiar on Android too, for what it's worth.
- 013 13y ago
  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 13y ago
    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 13y ago
      SyncAdapters were added in Android 2.x
  - pkaler 13y ago
    Already patented. You even have the choice of which patent you would like to infringe: - Apple: http://www.faqs.org/patents/app/20100227632 - RIM: http://www.uberphones.com/2010/12/rim-sues-kik-patent-infringement/ - MS: http://www.microsoft.com/en-us/news/press/2009/mar09/03-25AXIGENPR.aspx

jliptzin 13y ago

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

joshdance 13y ago
Follow that logic and we would never put out new features on anything. Not broken, don't improve.
logicallee 13y ago
The transitions to mainframes, Personal Computers, laptops, mobile phones, smartphones, are textbook cases of fixing something that wasn't 'broken'. I think if you're not careful the future will creep up on you without fixing anything.
eddieroger 13y ago
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.
- HNLogInShit 13y ago
  Like what? Background fetching is great. What else? For the end user, iOS 7 is a UI fiasco and a massive regression. Spindly, illegible text. A ridiculously degraded calendar, which no longer shows a concise list of a day's appointments but instead forces you to scroll through every hour of the day, hunting for whatever it is you have scheduled. "Transparency", a stupid UI idea that came and went a decade ago because it SUCKED. Why do I want to see the crap BEHIND the UI I'm trying to use? Oh, but I don't really see it; I see a mottled mess of a background, because it's "blurred." This of course renders text illegible in many cases, because the background may be any combination of colors. There are the tiny, undefined control areas. The invisible controls. The unresponsive controls. The camera icon on the lock screen is a great example of Apple's UI stupidity (which predates iOS 7). People are still trying to tap this thing, because Apple inexplicably doesn't put an ARROW above it to show you WTF you're supposed to do. Why? There's no excuse for it.

calinet6 13y ago

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.

deleted 13y ago
[deleted]
plorkyeran 13y ago
Apps don't actually have any control over when they get woken up for background fetch (you can set a minimum interval, but it's very much a minimum), and the more work you do when you get woken up the less often it happens. In practice for occasionally used apps it seems to happen once a day, and while you're on wifi and charging if possible.
joshdance 13y ago
That's the thing. It will be in the background. You won't even notice.
- untog 13y ago
  But we've been told for years that Android is fundamentally broken because it allows this. I guess everyone changed their mind?
  - uptown 13y ago
    Maybe stop worrying what "everyone" is saying, and form your own thoughts about things?
    - untog 13y ago
      I wasn't particularly worried about it. More noting the usual pattern of "<x> is wrong until Apple does it". Background apps, flat design...

MichaelGG 13y ago

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.

axxl 13y ago
Unfortunately not, Apple's push API supports a max notification payload size of 256 bytes.
potatolicious 13y ago
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 13y ago
  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?
raphael_o 13y ago
Although you're right that iOS7 also introduces silent push notifications to wake up the app in the background to let it fetch what's needed.

blago 13y ago

"Even a five second delay" Optimizing response times seems like a better, more universal approach.

raphael_o 13y ago
Agreed, especially loading time to encourage repeat use.

kunle 13y ago

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 13y ago
Yeah, but let's be honest. It's not real productive time. It's Facebook, Twitter, and Candy Crush.
- kunle 13y ago
  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).
Angostura 13y ago
People hate waiting for software, but they hate unexpectedly running out of data-plan capacity even more. Until now I've known that pretty much* the only time an app will be using data is when I'm looking at it. *There are a few exceptions, such as Mail which the average user understands.

leokun 13y ago

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 13y ago
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.
- pat2man 13y ago
  iOS will actually disable these features if the battery is getting low. It will also group them together so that the wireless chips are on as briefly as possible.
  - danieldk 13y ago
    iOS will actually disable these features if the battery is getting low. Like Battery Saver? http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-making-it-last http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-...
    - r00fus 13y ago
      Great - another option. I prefer my phone deciding when to do this automatically (and maybe an option to disable it so I can run it into the ground if absolutely necessary).
      - 13y ago

arpit 13y ago

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

greenlakejake 13y ago

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 13y ago
Wait... there is still a developer NDA?

HNLogInShit 13y ago

Uninformative and inappropriate title. The entire article is about "background fetching", and the title should reflect that. Also, Apple has always advised against "splash screens", and instead recommended that you make a fake-screen bitmap so it looks like your app has already launched. This is stupid for two major and related reasons: 1. When the user starts tapping on controls on your fake screen and they don't work, it looks like your app is defective and locked up. 2. The screen will show outdated and inaccurate information until the app is actually running and replaces the fake screen with the real one. iOS 7 is rife with examples of this screen-shot problem. iOS has always (as far as I know) taken a snapshot of the app's screen before it goes into the background, which it then displays when the app returns. This often shows wrong information or even the wrong orientation, long enough to perplex the user.

cromwellian 13y ago

IIRC, even J2ME MIDP had this feature on feature phones, see http://www.oracle.com/technetwork/systems/pushreg-156557.html http://www.oracle.com/technetwork/systems/pushreg-156557.htm... Circa 2002. Everything old is new and magic and amazing now folks!

threeseed 13y ago
And I could have implemented this on any computer going back 30 years. What exactly is your point ?
- cromwellian 13y ago
  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.