Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Zxxv

macrumors 68040
Original poster
Nov 13, 2011
3,558
1,104
UK
Improve and make up for the lack of ram? Less reboots etc? When it's switched on?
 
Improve and make up for the lack of ram? Less reboots etc? When it's switched on?

No. background app refresh just refreshes the data in apps so when you open them you are seeing the latest information and do not need to press the refresh button.

This has nothing to with Ram or Reboots.
 
No. background app refresh just refreshes the data in apps so when you open them you are seeing the latest information and do not need to press the refresh button.

This has nothing to with Ram or Reboots.

so if an app is refreshed in the background when you open it it won't reboot?

hence giving the impression of better performance?

do people who complain of low ram and reboots etc have background app refresh off?

and does having it on improve the low ram situation?
 
so if an app is refreshed in the background when you open it it won't reboot?

hence giving the impression of better performance?

do people who complain of low ram and reboots etc have background app refresh off?

and does having it on improve the low ram situation?

No, it just periodically updates itself in the background.

Take for instance an app like tweetbot. Normally, you open the app, then it checks for any new tweets and downloads them accordingly. With background refresh, you open the app and may find several tweets already downloaded and waiting for you to read.

Usually, it's just a savings of anywhere from a split-seconds to a few seconds, but it can give the impression of the OS feeling more snappy and responsive, since the info you want is already there and waiting for you.

It has no link with ram at all.
 
The OP does have a point.

Yes, Background App Refresh is a method by which a phone with less RAM could mimic some behaviors of a phone with more RAM.

This does not saying that the two hypothetical phones are the same, just that BAR lessons the distance between them. The OP didn't really explain it well, but the general concept behind the question is solid.
 
The OP does have a point.

Yes, Background App Refresh is a method by which a phone with less RAM could mimic some behaviors of a phone with more RAM.

This does not saying that the two hypothetical phones are the same, just that BAR lessons the distance between them. The OP didn't really explain it well, but the general concept behind the question is solid.

Thanks for understanding what I tried to write #

----------


Screw Google. I came to macrumors. And the other poster 'small white car' answered what I was asking thanks.
 
The OP does have a point.

Yes, Background App Refresh is a method by which a phone with less RAM could mimic some behaviors of a phone with more RAM.

This does not saying that the two hypothetical phones are the same, just that BAR lessons the distance between them. The OP didn't really explain it well, but the general concept behind the question is solid.

Actually, I see it as a way of mimicking a similar process (leaving apps open in the background) but with lesser battery drain, not so much to conserve ram usage. iOS has never allowed apps to stay open in the background, so even if you argue that 1gb of ram forces more frequent app closures, that still doesn't seem relevant here.
 
Thanks for understanding what I tried to write #

----------



Screw Google. I came to macrumors. And the other poster 'small white car' answered what I was asking thanks.

Actually that link was very useful to understand iOS multitasking model.......
 
Actually his answer wasn't completely correct.
BAR has very little to do with mimic a device with more ram.....

His answer was exactly what I was looking for because he understood fully what I was asking and he replied with what I wanted.
 
His answer was exactly what I was looking for because he understood fully what I was asking and he replied with what I wanted.

The fact he replied with an answer you liked doesn't make it a correct answer.
 
The fact he replied with an answer you liked doesn't make it a correct answer.

Are you ****ing serious? He understood my question. Keep arguing all you want it won't make a blind bit of difference.
 
Actually his answer wasn't completely correct.
BAR has very little to do with mimic a device with more ram.....

How does it not?

A device without BAR that wanted to get the same results as BAR would have to fully run those programs in the background. And doing that would require more RAM.

Thus, if a BAR-less phone needs more RAM to do the same thing you could conversely say that a BAR-equiped phone could get by with less RAM to do the same thing.
 
You're reaching. Apple's decision to not allow true multitasking is not due to the amount of RAM in current iPhones. Yes, BAR is a substitute for not having true multitasking, but not as a substitute for RAM.

How does it not?



A device without BAR that wanted to get the same results as BAR would have to fully run those programs in the background. And doing that would require more RAM.



Thus, if a BAR-less phone needs more RAM to do the same thing you could conversely say that a BAR-equiped phone could get by with less RAM to do the same thing.
 
You're reaching. Apple's decision to not allow true multitasking is not due to the amount of RAM in current iPhones. Yes, BAR is a substitute for not having true multitasking, but not as a substitute for RAM.

If an app background refreshed and you then opened the app it wouldn't need to reload because it's already loaded the new up todate info.
See my Original question was based on this and flushing ram which users complain about seeing when apps are opened.
 
The point of my reply is that BAR is a multitasking alternative, not a RAM one.


If an app background refreshed and you then opened the app it wouldn't need to reload because it's already loaded the new up todate info.

See my Original question was based on this and flushing ram which users complain about seeing when apps are opened.
 
How Background Refresh Works

Improve and make up for the lack of ram? Less reboots etc? When it's switched on?

I did a post a while back that explains how this works in detail:

"This is how background refresh works based on the session they had at WWDC you can view it at:https://developer.apple.com/wwdc/videos/ I know this reply is going to be long so here goes.

In iOS 6 only a selected few type of applications can run in the background or program tasks in the background:
Background Audio (Music apps like, Spotify can run in the background)
VoIP (Like Skype)
Newsstand Apps
Location Services which includes: Region Monitoring, Significant Location Changes, and Continuous Location Monitoring. I think Reminders use this when using GeoFencing.

In iOS 7 apps can continue to update there content in the background without sacrificing much battery life. Apps can take advantage of a new API called, 'Background Fetch'. For example let's say you social networking app you may notice that when your app becomes frontmost, you refresh your feed. And the user has to wait for that feed to be updated which is not the best user experience. Now with Background Fetch your social media app can update it's content before the user returns to your app, in this case the feed.

Some key points about Background fetch:
System-scheduled fetch
Coalesced across applications (Saving a lot of battery life)
Adapts to actual usage patterns on device
Sensitive to energy and data usage
Indifferent to actual app running state
Background fetch adapts to how you use your device. So say for instance you check Facebook every morning at 7:00 AM iOS will notice this and will try to give the app an opportunity to fetch content before 7:00 AM. It also coalesces fetches across apps so it doesn't drain to much power it even, avoids frequent fetching during periods of inactivity and when you have a low signal on your phone.

Remote Notifications

You may have noticed in the previous versions of iOS say, you got a message on Facebook and a notification pops up on your lock screen, and you swipe to you it there is a delay before the app downloads the message. Well in iOS 7 in Remote Notifications simply put is downloaded before you even receive the notification.
I have noticed in iMessage on iOS 7 the app is in the background, and I receive a message the app snapshot is updated, this also happens when the user is composing a message. I think that covers most of it, and I hoped I help in some way. Looking forward to your reply."

Also, there is a awesome post on: http://www.scottyloveless.com/blog/2014/background-app-refresh-explained
That explains everything in Laymen's terms.
 
I did a post a while back that explains how this works in detail:

"This is how background refresh works based on the session they had at WWDC you can view it at:https://developer.apple.com/wwdc/videos/ I know this reply is going to be long so here goes.

In iOS 6 only a selected few type of applications can run in the background or program tasks in the background:
Background Audio (Music apps like, Spotify can run in the background)
VoIP (Like Skype)
Newsstand Apps
Location Services which includes: Region Monitoring, Significant Location Changes, and Continuous Location Monitoring. I think Reminders use this when using GeoFencing.

In iOS 7 apps can continue to update there content in the background without sacrificing much battery life. Apps can take advantage of a new API called, 'Background Fetch'. For example let's say you social networking app you may notice that when your app becomes frontmost, you refresh your feed. And the user has to wait for that feed to be updated which is not the best user experience. Now with Background Fetch your social media app can update it's content before the user returns to your app, in this case the feed.

Some key points about Background fetch:
System-scheduled fetch
Coalesced across applications (Saving a lot of battery life)
Adapts to actual usage patterns on device
Sensitive to energy and data usage
Indifferent to actual app running state
Background fetch adapts to how you use your device. So say for instance you check Facebook every morning at 7:00 AM iOS will notice this and will try to give the app an opportunity to fetch content before 7:00 AM. It also coalesces fetches across apps so it doesn't drain to much power it even, avoids frequent fetching during periods of inactivity and when you have a low signal on your phone.

Remote Notifications

You may have noticed in the previous versions of iOS say, you got a message on Facebook and a notification pops up on your lock screen, and you swipe to you it there is a delay before the app downloads the message. Well in iOS 7 in Remote Notifications simply put is downloaded before you even receive the notification.
I have noticed in iMessage on iOS 7 the app is in the background, and I receive a message the app snapshot is updated, this also happens when the user is composing a message. I think that covers most of it, and I hoped I help in some way. Looking forward to your reply."

Also, there is a awesome post on: http://www.scottyloveless.com/blog/2014/background-app-refresh-explained
That explains everything in Laymen's terms.

Nice post, but it didn't answer my question.
 
How does it not?

A device without BAR that wanted to get the same results as BAR would have to fully run those programs in the background. And doing that would require more RAM.

Thus, if a BAR-less phone needs more RAM to do the same thing you could conversely say that a BAR-equiped phone could get by with less RAM to do the same thing.

BAR is limited to some operations. It's a choice about multitasking, not about ram consumption.

----------

But in the context of the topic (mine) I asked about. ?
Your question was just wrong.
BAR has nothing to do with "less reboots" as you asked.
Apple choice about multitasking is more complex than substitute it with an app refresh for some contents.

----------

Nice post, but it didn't answer my question.

Actually his post, and the link he provided, are the best answer to your question, but you either:
A) didn't read it
B) didn't understand it
 
You're reaching. Apple's decision to not allow true multitasking is not due to the amount of RAM in current iPhones.

Since that's not at all what I said I don't see how I'm reaching.

My post was about comparing different types of hardware and had nothing to do with Apple's thought process.
 
You said: "A device without BAR that wanted to get the same results as BAR would have to fully run those programs in the background. And doing that would require more RAM."

My reply stands. You're reaching.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.