Yes, but it does function as an app switcher since you are not supposed to really "know" that an app is running or not. (There is not an official way for an app to quit, for example -- it is always supposed to be running and if it has to restart due to being force quit by the OS, or a crash, most apps should try and restore their state to where they were at, for example). So the illusion is meant to be maintained that apps are always active and available so in effect it is an app switcher. It just launches an app if it is not already running to maintain the illusion. The user is not supposed to know or care if an app is actually running or not (in terms of UX). (And Mac OS X "Recent Items" will switch to a running app as well and they do behave the same or very similarly, the iOS and Mac OS X versions).
I'd say it mostly functions as a Recent list of apps, and has a secondary feature of being able to kill an app that is not responding and therefore stuck. I rarely use FAS, but instead access my apps from the Home Screens. I only have two and don't use the 2nd page much. I go into those apps constantly, and because of the speed of the system I expect them to open up right away. If, for example, I jump into Facebook, and it takes an extra second to load it's probably because it wasn't loaded in RAM at the time.
Pretty much any app that has a notification that can occur when the app is not in the foreground is going to be running SOMETHING in the background. Now - go check all the apps that have notification settings and tell us again about apps not needing to be closed.
Every majors news app does this, every major weather app does this, your bank app does this, etc.
The article is inaccurate. Move on.
They are not polling and running continuously in the background.
You can ask to be woken up periodically and can suggest a time frame for that but the system does not guaranty that it will do it according to the requested schedule. The app can then refresh itself. Or the server can push a silent push notification that will wake up the app and allow it to refresh itself. That is much different that running in the background as you claim happens. And in addition, killing the app, I don't think, at least if using a silent push notification, matters, as the app will be relaunched to handle the notification so "killing" it doesn't make a difference. Don't remember how the periodic wake up to refresh works -- if that will relaunch the app if killed -- but I think it does since the app itself will be killed off to free up resources anyway.
(just about) Any app that provides your status/location to other users or other backend systems is polling in the background. Lync/Skype and Cisco Jabber to name two -- even when they are not being used for VoIP (not configured to use VoIP).
I'd say it mostly functions as a Recent list of apps, and has a secondary feature of being able to kill an app that is not responding and therefore stuck. I rarely use FAS, but instead access my apps from the Home Screens. I only have two and don't use the 2nd page much. I go into those apps constantly, and because of the speed of the system I expect them to open up right away. If, for example, I jump into Facebook, and it takes an extra second to load it's probably because it wasn't loaded in RAM at the time.
Correct. I rarely use the "FAS" on iOS unless I am trying to force an app to restart in order to start in a known state - mostly when debugging apps or whatever...
The article is accurate, although they could have made the solution for the Chicken Littles who still think it's in the 20th century more prominent instead of sticking it in the last sentence of the last paragraph.
Any app that provides your status/location to other users or other backend systems is polling in the background.
I think you screwed up your quote as I never said that.
If you meant to say it, you are wrong. Apps don't sit in the background polling. iOS is not really set up to allow them to unless they cheat by claiming to be an audio or VOIP app or something and are hence allowed to really run in the background indefinitely.
How it works is that you (meaning the app) request periodic updates from the system. You can suggest a timeframe (such as every minute or every 5 minutes or whatever) but you are not guaranteed to be woken up and given some background time on the schedule you requested. You may be but may not be. In my experience debugging some apps, it sometimes gave us the schedule we wanted and sometimes not -- depending on system usage and also our app usage. The more we used our app in the foreground, the more it seemed to be woken up according to our requested schedule in the background (when not in the foreground). However, those are just my observations.
Anyway, the system periodically wakes up the app and gives it a small amount of background processing time so it can refresh itself from its server somewhere. The app is not running continuously in the background and polling. iOS does not work that way. When you hit the home button to switch your app into the background you get a second or three and your app is suspended and eventually terminated if memory gets tight. Certain classes of apps can get more time or run indefinitely [not chat or weather apps, but audio, VOP, etc. and only for the purpose of doing active audio or whatever, not for polling a server] or you can request more time if you have a download currently underway or some other long calculation underway but when your time is up it is up and you are gone. If you have requested to be woken up periodically that will happen but you are not polling in the background. You have a targeted window of being woken up to query your server and refresh yourself, and then you suspend again.
(just about) Any app that provides your status/location to other users or other backend systems is polling in the background. Lync/Skype and Cisco Jabber to name two -- even when they are not being used for VoIP (not configured to use VoIP).
NO, they are not running in the background (continuously) polling. They are either getting a silent push, which wakes them up and allows them to do what they need to do, or they are requesting periodic background time and being woken up periodically to refresh themselves. Or something along those lines. Your battery would be dead in an hour if they were continuously background polling.
NO, they are not running in the background (continuously) polling. They are either getting a silent push, which wakes them up and allows them to do what they need to do, or they are requesting periodic background time and being woken up periodically to refresh themselves. Or something along those lines. Your battery would be dead in an hour if they were continuously background polling.
We may be saying the same thing in different ways. To me, any app that periodically wakes up do so something is "polling" IMHO. A poll is:
- do nothing/sleep
-wake up or be awakened to look for things needing to be done
-do stuff
-go back to sleep/doing nothing
Example: Cisco Jabber (depending on the version) gets regular push notifications from the server to wake up and do stuff. I call that polling.
We may be saying the same thing in different ways. To me, any app that periodically wakes up do so something is "polling" IMHO. A poll is:
- do nothing/sleep
-wake up or be awakened to look for things needing to be done
-do stuff
-go back to sleep/doing nothing
Example: Cisco Jabber (depending on the version) gets regular push notifications from the server to wake up and do stuff. I call that polling.
That would not be considered polling in the traditional SW sense of No-Nos and 1990s programming. And note I said "continuously polling". What would be considered polling is a process keeping an active connection to the backend and querying the backend periodically (every x seconds or maybe minutes) if there was data for it.
This does not happen on iOS normally. Your process is suspended and you are periodically woken up to allow you to make a query to you backend to update yourself. There is no constant connection. It is in a sense "polling" as you don't know there is data to be got, but you have no constant connection and you are asking "infrequently" and is in no way continuous polling and is not a resource drain as you are not running except when woken up to make your periodic update request of the backend.
You are not running continuously using battery or resources. A silent push to be told to wake up and retrieve data is not polling in any sense. It is a sort of push, where you specifically are told there is data for you to retrieve.
That would not be considered polling in the traditional SW sense of No-Nos and 1990s programming.
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
Does not really contribute to increased power consumption in a meaningful way (meaning greatly accelerating rundown) unless they do it wrong. The system tends to wake you up when it already has network communications going so you don't have to restart the network stack back up, and your small amount of CPU is at the expense of something else.
It will use CPU. A very small amount for a small amount of time. It is not running continuously in the background. And you can control it somewhat by settings for that app in the iOS "Settings" app. If you tell iOS to not give that app any background time, it won't get it.
If we don't run any apps, our batteries will last a long time. Presumably a moderate amount of resource use is OK with us or we would not have installed and run the app in the first place.
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
You mean even after disabling Background App Refresh, Cellular Data, Location, Notifications in every app that is using a great deal of power per the list in Battery? No, not in any harmful way if the app is running properly. As [@]chadbag[/@] mentioned, there are apps that can run for a short time after switching depending on the APIs they are using.
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
Yes, apps can do background processing. However, the system allows it only in a controlled, and least abusive way possible, so that system impacted is greatly limited. And you have control over it to a great extent through settings that control location services, background updates, etc.
Absent OS bugs, or devious apps that cheat and claim to be one of a special set of classes that gets a little more leeway (and will get caught and corrected or removed from the App Store), apps can't hog resources in the background and run your battery down in a jiffy. They can use background resources moderately which will of course consume those resources and provide the service they are supposed to provide.
How is that proof? The whole article is based on this as the proof? On Mac OS X, that is a feature. How do they not know that iOS is just not relaunching all of those apps into the background after reboot? We know they are not "running" like a foreground app, but background processing can be occurring in those apps.
Of course it's not relaunching all those apps on an iPhone. We have 1G of memory, most of us.
They are not polling and running continuously in the background.
You can ask to be woken up periodically and can suggest a time frame for that but the system does not guaranty that it will do it according to the requested schedule. The app can then refresh itself. Or the server can push a silent push notification that will wake up the app and allow it to refresh itself. That is much different that running in the background as you claim happens. And in addition, killing the app, I don't think, at least if using a silent push notification, matters, as the app will be relaunched to handle the notification so "killing" it doesn't make a difference. Don't remember how the periodic wake up to refresh works -- if that will relaunch the app if killed -- but I think it does since the app itself will be killed off to free up resources anyway.
Yet. FB was always on even when background app refreshing was off. The OS kills apps that are in the background and consuming too much memory, they get a few warnings until they are kicked out. All you are seeing in that list is the order apps were launched or switched too.
However there are ways to consume background services and never die. People are right about GPS services. They don't die. If the app is continually updating its location and getting GPS it's likely to be kept alive and using battery. The reason for this is so that turn by turn navigation services can tell you where you are while you are doing something else, like playing Apple Music.
Audio apps have to be able to stay awake too. If a radio app is backgrounded its audio still plays. This is battery intensive. In both cases swiping up helps quit them. These apps will stay alive (regardless of the position in the list or even memory pressure unless it's really extreme I think. )
So for simplicity sake you could say swiping up helps.
It must be a slow news day. Aside from presenting opinion as fact, Mr. Hughes warns readers they "shouldn't" make a habit of closing apps. With no compelling evidence that doing so causes any harm, the correct wording would be "needn't." Poor writing all around.
Yes, apps can do background processing. However, the system allows it only in a controlled, and least abusive way possible, so that system impacted is greatly limited. And you have control over it to a great extent through settings that control location services, background updates, etc.
Absent OS bugs, or devious apps that cheat and claim to be one of a special set of classes that gets a little more leeway (and will get caught and corrected or removed from the App Store), apps can't hog resources in the background and run your battery down in a jiffy. They can use background resources moderately which will of course consume those resources and provide the service they are supposed to provide.
FB was abusing the system to stay awake. It's worth looking at the battery usage stats.
Comments
I'd say it mostly functions as a Recent list of apps, and has a secondary feature of being able to kill an app that is not responding and therefore stuck. I rarely use FAS, but instead access my apps from the Home Screens. I only have two and don't use the 2nd page much. I go into those apps constantly, and because of the speed of the system I expect them to open up right away. If, for example, I jump into Facebook, and it takes an extra second to load it's probably because it wasn't loaded in RAM at the time.
Pretty much any app that has a notification that can occur when the app is not in the foreground is going to be running SOMETHING in the background. Now - go check all the apps that have notification settings and tell us again about apps not needing to be closed.
Every majors news app does this, every major weather app does this, your bank app does this, etc.
The article is inaccurate. Move on.
They are not polling and running continuously in the background.
You can ask to be woken up periodically and can suggest a time frame for that but the system does not guaranty that it will do it according to the requested schedule. The app can then refresh itself. Or the server can push a silent push notification that will wake up the app and allow it to refresh itself. That is much different that running in the background as you claim happens. And in addition, killing the app, I don't think, at least if using a silent push notification, matters, as the app will be relaunched to handle the notification so "killing" it doesn't make a difference. Don't remember how the periodic wake up to refresh works -- if that will relaunch the app if killed -- but I think it does since the app itself will be killed off to free up resources anyway.
(just about) Any app that provides your status/location to other users or other backend systems is polling in the background. Lync/Skype and Cisco Jabber to name two -- even when they are not being used for VoIP (not configured to use VoIP).
I'd say it mostly functions as a Recent list of apps, and has a secondary feature of being able to kill an app that is not responding and therefore stuck. I rarely use FAS, but instead access my apps from the Home Screens. I only have two and don't use the 2nd page much. I go into those apps constantly, and because of the speed of the system I expect them to open up right away. If, for example, I jump into Facebook, and it takes an extra second to load it's probably because it wasn't loaded in RAM at the time.
Correct. I rarely use the "FAS" on iOS unless I am trying to force an app to restart in order to start in a known state - mostly when debugging apps or whatever...
The article is accurate, although they could have made the solution for the Chicken Littles who still think it's in the 20th century more prominent instead of sticking it in the last sentence of the last paragraph.
Any app that provides your status/location to other users or other backend systems is polling in the background.
I think you screwed up your quote as I never said that.
If you meant to say it, you are wrong. Apps don't sit in the background polling. iOS is not really set up to allow them to unless they cheat by claiming to be an audio or VOIP app or something and are hence allowed to really run in the background indefinitely.
How it works is that you (meaning the app) request periodic updates from the system. You can suggest a timeframe (such as every minute or every 5 minutes or whatever) but you are not guaranteed to be woken up and given some background time on the schedule you requested. You may be but may not be. In my experience debugging some apps, it sometimes gave us the schedule we wanted and sometimes not -- depending on system usage and also our app usage. The more we used our app in the foreground, the more it seemed to be woken up according to our requested schedule in the background (when not in the foreground). However, those are just my observations.
Anyway, the system periodically wakes up the app and gives it a small amount of background processing time so it can refresh itself from its server somewhere. The app is not running continuously in the background and polling. iOS does not work that way. When you hit the home button to switch your app into the background you get a second or three and your app is suspended and eventually terminated if memory gets tight. Certain classes of apps can get more time or run indefinitely [not chat or weather apps, but audio, VOP, etc. and only for the purpose of doing active audio or whatever, not for polling a server] or you can request more time if you have a download currently underway or some other long calculation underway but when your time is up it is up and you are gone. If you have requested to be woken up periodically that will happen but you are not polling in the background. You have a targeted window of being woken up to query your server and refresh yourself, and then you suspend again.
Sorry about my other post - fixed that.
Developers have options - well-behaved apps can, and do, run in the background.
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1
(just about) Any app that provides your status/location to other users or other backend systems is polling in the background. Lync/Skype and Cisco Jabber to name two -- even when they are not being used for VoIP (not configured to use VoIP).
NO, they are not running in the background (continuously) polling. They are either getting a silent push, which wakes them up and allows them to do what they need to do, or they are requesting periodic background time and being woken up periodically to refresh themselves. Or something along those lines. Your battery would be dead in an hour if they were continuously background polling.
Sorry about my other post - fixed that.
Developers have options - well-behaved apps can, and do, run in the background.
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1
Did you actually read that? That is basically what I have explained several times already in this thread.
- do nothing/sleep
-wake up or be awakened to look for things needing to be done
-do stuff
-go back to sleep/doing nothing
Example: Cisco Jabber (depending on the version) gets regular push notifications from the server to wake up and do stuff. I call that polling.
It's just friggin' basic good house keeping.
no, it's not. no more than taking out all the furniture in a room every time you leave the room is.
faulty apps side, you DONT NEED to manage apps on ios.
You'r not very good at analogies.
We may be saying the same thing in different ways. To me, any app that periodically wakes up do so something is "polling" IMHO. A poll is:
- do nothing/sleep
-wake up or be awakened to look for things needing to be done
-do stuff
-go back to sleep/doing nothing
Example: Cisco Jabber (depending on the version) gets regular push notifications from the server to wake up and do stuff. I call that polling.
That would not be considered polling in the traditional SW sense of No-Nos and 1990s programming. And note I said "continuously polling". What would be considered polling is a process keeping an active connection to the backend and querying the backend periodically (every x seconds or maybe minutes) if there was data for it.
This does not happen on iOS normally. Your process is suspended and you are periodically woken up to allow you to make a query to you backend to update yourself. There is no constant connection. It is in a sense "polling" as you don't know there is data to be got, but you have no constant connection and you are asking "infrequently" and is in no way continuous polling and is not a resource drain as you are not running except when woken up to make your periodic update request of the backend.
You are not running continuously using battery or resources. A silent push to be told to wake up and retrieve data is not polling in any sense. It is a sort of push, where you specifically are told there is data for you to retrieve.
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
Does not really contribute to increased power consumption in a meaningful way (meaning greatly accelerating rundown) unless they do it wrong. The system tends to wake you up when it already has network communications going so you don't have to restart the network stack back up, and your small amount of CPU is at the expense of something else.
It will use CPU. A very small amount for a small amount of time. It is not running continuously in the background. And you can control it somewhat by settings for that app in the iOS "Settings" app. If you tell iOS to not give that app any background time, it won't get it.
If we don't run any apps, our batteries will last a long time. Presumably a moderate amount of resource use is OK with us or we would not have installed and run the app in the first place.
You mean even after disabling Background App Refresh, Cellular Data, Location, Notifications in every app that is using a great deal of power per the list in Battery? No, not in any harmful way if the app is running properly. As [@]chadbag[/@] mentioned, there are apps that can run for a short time after switching depending on the APIs they are using.
I admit my ignorance, but can we agree that things are still happening in the background with well-behaved apps that cause on-going communications and contribute to increased power consumption?
Yes, apps can do background processing. However, the system allows it only in a controlled, and least abusive way possible, so that system impacted is greatly limited. And you have control over it to a great extent through settings that control location services, background updates, etc.
Absent OS bugs, or devious apps that cheat and claim to be one of a special set of classes that gets a little more leeway (and will get caught and corrected or removed from the App Store), apps can't hog resources in the background and run your battery down in a jiffy. They can use background resources moderately which will of course consume those resources and provide the service they are supposed to provide.
Of course it's not relaunching all those apps on an iPhone. We have 1G of memory, most of us.
Yet. FB was always on even when background app refreshing was off. The OS kills apps that are in the background and consuming too much memory, they get a few warnings until they are kicked out. All you are seeing in that list is the order apps were launched or switched too.
However there are ways to consume background services and never die. People are right about GPS services. They don't die. If the app is continually updating its location and getting GPS it's likely to be kept alive and using battery. The reason for this is so that turn by turn navigation services can tell you where you are while you are doing something else, like playing Apple Music.
Audio apps have to be able to stay awake too. If a radio app is backgrounded its audio still plays. This is battery intensive. In both cases swiping up helps quit them. These apps will stay alive (regardless of the position in the list or even memory pressure unless it's really extreme I think. )
So for simplicity sake you could say swiping up helps.
FB was abusing the system to stay awake. It's worth looking at the battery usage stats.