It's more of an OCD thing for me, seeing that many apps on the switcher drives me nuts. Plus I know that while they aren't all running background processes SOME are, and closing the app will in fact stop that. It's easier for me to just close everything every now and again than to be bothered digging in to settings. I'm certainly not hurting anything.
Sometimes a forger to stop a radio app. That thing nerver stops, even in the backgroud, consuming both batterie and bandwight
Yeah that's true actually. I mean Spotify doesn't stop playing just because you go into another app. So then it might be the same with other apps too, they could keep running.
This article is very false. You can run a true test by watching those apps even after a reboot with them in the background. Use iTools and watch the memory usage when they are running vs not running. They use RAM and RAM equals speed. Maybe when we close our background processes it stops them from spying or collecting data.
This is probably the wrongest bit of "information" in this thread.
Except it's true: RAM equals speed. But that's because something that's using RAM is MUCH FASTER than if it had to be loaded into RAM because some idiot decided he knew better and killed it to free up RAM.
FREE RAM indicates inefficient performance, because something could be using that RAM to make the machine faster, rather than waiting for it to have to be loaded.
What good is that free RAM doing for your device? Unused RAM is wasted RAM. It's not making your device any faster or prolonging the battery life.
The important detail is that iOS will automatically free up old in-use RAM for newly opened programs as needed. So, if you only have 50MB of free RAM and you open up a game that requires 500MB, it will free up the necessary RAM automatically while the game loads so it can have it.
Your action is unnecessary in this regard.
I never mentioned battery life.
What you said is not universally valid.
If you are using Safari and a couple of apps (Mail and iTranslate, for example) having free RAM available means you can keep several (not many) tabs opened without having the older reloaded at every switch, going from Mail to Safari or even from tab to tab.
If you are using Safari and a couple of apps (Mail and iTranslate, for example) having free RAM available means you can keep several (not many) tabs opened without having the older reloaded at every switch, going from Mail to Safari or even from tab to tab.
No, that is completely incorrect.
Having MORE RAM available means those things. iOS will kick other things out of RAM immediately when whatever you're doing asks for more. Having FREE RAM available just means that whatever else you want to do needs to get loaded into RAM, first — which actually costs time and battery life.
It doesn't help your system, at all; on the contrary.
Free RAM literally means that your system is not running as efficiently as it could be.
Having MORE RAM available means those things. iOS will kick other things out of RAM immediately when whatever you're doing asks for more. Having FREE RAM available just means that whatever else you want to do needs to get loaded into RAM, first — which actually costs time and battery life.
It doesn't help your system, at all; on the contrary.
Free RAM literally means that your system is not running as efficiently as it could be.
that's not what iOS is doing, now or never, on any of my iDevices, no matter what Mr "I-Know-Everything-You-Ignorant-Newbie" says .....
If I keep free RAM available my browsing/partial multitasking experience is substantially better.
So what it used to do is exactly what I describe, regardless of whatever you may choose to believe or imagine to have seen.
My understanding is that Background app refresh was added recently (and can be turned off), which allows suspended apps to jump on the periodic network checks to update their content, but that the multitasking is still the same, limited multitasking as Fraser Speirs describes above in 2012.
So what it used to do is exactly what I describe, regardless of whatever you may choose to believe or imagine to have seen.
My understanding is that Background app refresh was added recently (and can be turned off), which allows suspended apps to jump on the periodic network checks to update their content, but that the multitasking is still the same, limited multitasking as Fraser Speirs describes above in 2012.
And again your link or BAR has nothing to do with the behavior I'm describing.
You have not enough free ram, tabs reloads. It is quite easy to understand.
If i close unused app that still have allocated resources, I free more ram, tabs stayed in the RAM.
Neil's big reveal that killing background apps is never a good idea proves to me he is not a developer. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is the second article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
Neil's big reveal that somehow killing background apps is never a good idea proves to me he is CLEARLY NOT A DEVELOPER. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
Neil's big reveal that somehow killing background apps is never a good idea proves to me he is CLEARLY NOT A DEVELOPER. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
And again your link or BAR has nothing to do with the behavior I'm describing.
You have not enough free ram, tabs reloads. It is quite easy to understand.
If i close unused app that still have allocated resources, I free more ram, tabs stayed in the RAM.
No, that is, quite simply, wrong.
If you do not have enough free RAM, iOS will THROW EVERYTHING ELSE OUT OF MEMORY the microsecond your app asks for more.
It's right there in the link you didn't read:
Quote:
The first technical caveat is that Suspended apps remain in the device's memory. This is so they can resume more quickly when you go back to them. They're not using processor time and they're not sucking battery power.
You may think that, if an app is resident in memory, you have to somehow remove it to conserve memory. You don't because iOS does it for you. If there are Suspended apps lying around and you launch a memory-intensive app such as a big game, iOS will start to purge Suspended apps and move them to the Not Running state. That is, they will be completely removed from memory and will launch afresh the next time you tap their icon.
Quitting apps does absolutely nothing the OS wouldn't do by itself. If you're seeing an improvement in tab reloading, that's due to improvements Apple has made to Safari — in fact, everybody has been seeing that.
That does not mean that apps themselves were or are fully multi tasking. The OS may limit what processes can run under what circumstances. But the OS itself is fully multi tasking. It is a full mach kernel "unix" type system.
This is unlike the old Mac OS system prior to OS X that had a cooperative multi tasking system.
Dude stop lecturing me, Im an apple user since you was in the kindergarten ....
I'm speaking about THE SAME app (safari) with multiple tabs.
iOS can't purge anything, it just reloads tabs when switching between them.
I don't need any link to know how it works.
Sorry, I expanded the post slightly before you replied.
It really doesn't matter what you think. That's just not how it works.
I also appreciate the weird authority argument. I really don't see how relevant it is that you may or may not have been using a first-generation Apple II that was current when I was in kindergarten back i n 1978. It has absolutely nothing at all to do with how iOS manages memory, nor the fact that you seem insistent upon reliving OS 9-induced habits some 18 years later.
Neil's big reveal that somehow killing background apps is never a good idea proves to me he is CLEARLY NOT A DEVELOPER. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
You forgot to mention that this is even counter-productive, as all those apps you want to use again will have to launch a new and thus consume more battery power as if you had just let them sleep on the background.
And another sad fact: I have repeatedly seen "tech news articles" in local (German) news magazines where the authors advise you to do that stupid swiping work regularly. Sad. Really sad. They have no knowledge, but they try to teach people.
If you do not have enough free RAM, iOS will THROW EVERYTHING ELSE OUT OF MEMORY the microsecond your app asks for more.
It's right there in the link you didn't read:
Quitting apps does absolutely nothing the OS wouldn't do by itself. If you're seeing an improvement in tab reloading, that's due to improvements Apple has made to Safari — in fact, everybody has been seeing that.
So what it used to do is exactly what I describe, regardless of whatever you may choose to believe or imagine to have seen.
My understanding is that Background app refresh was added recently (and can be turned off), which allows suspended apps to jump on the periodic network checks to update their content, but that the multitasking is still the same, limited multitasking as Fraser Speirs describes above in 2012.
Background refresh is garbage. iOS checks for too many things all the time. iOS is 4 steps behind the competition. RAM=random access memory. iOS doesn't use RAM properly and neither does OSX or any of the Apple OS's.
Comments
Sometimes a forger to stop a radio app. That thing nerver stops, even in the backgroud, consuming both batterie and bandwight
Yeah that's true actually. I mean Spotify doesn't stop playing just because you go into another app. So then it might be the same with other apps too, they could keep running.
This article is very false. You can run a true test by watching those apps even after a reboot with them in the background. Use iTools and watch the memory usage when they are running vs not running. They use RAM and RAM equals speed. Maybe when we close our background processes it stops them from spying or collecting data.
This is probably the wrongest bit of "information" in this thread.
Except it's true: RAM equals speed. But that's because something that's using RAM is MUCH FASTER than if it had to be loaded into RAM because some idiot decided he knew better and killed it to free up RAM.
FREE RAM indicates inefficient performance, because something could be using that RAM to make the machine faster, rather than waiting for it to have to be loaded.
No, I went from 50 Mb of available resource to 300 Mb of available resources.... And I'm not whining about "tabs reload" or app crashing in my iPhone
I'm not doing any of those things, and as of 9.1, hardly anybody is whining about "tabs reload" or crashes.
If your placebo killing of apps has resulted in fewer tabs reloading or fewer crashes, then your system is completely FUBAR.
What good is that free RAM doing for your device? Unused RAM is wasted RAM. It's not making your device any faster or prolonging the battery life.
The important detail is that iOS will automatically free up old in-use RAM for newly opened programs as needed. So, if you only have 50MB of free RAM and you open up a game that requires 500MB, it will free up the necessary RAM automatically while the game loads so it can have it.
Your action is unnecessary in this regard.
I never mentioned battery life.
What you said is not universally valid.
If you are using Safari and a couple of apps (Mail and iTranslate, for example) having free RAM available means you can keep several (not many) tabs opened without having the older reloaded at every switch, going from Mail to Safari or even from tab to tab.
I never mentioned battery life.
What you said is not universally valid.
If you are using Safari and a couple of apps (Mail and iTranslate, for example) having free RAM available means you can keep several (not many) tabs opened without having the older reloaded at every switch, going from Mail to Safari or even from tab to tab.
No, that is completely incorrect.
Having MORE RAM available means those things. iOS will kick other things out of RAM immediately when whatever you're doing asks for more. Having FREE RAM available just means that whatever else you want to do needs to get loaded into RAM, first — which actually costs time and battery life.
It doesn't help your system, at all; on the contrary.
Free RAM literally means that your system is not running as efficiently as it could be.
No, that is completely incorrect.
Having MORE RAM available means those things. iOS will kick other things out of RAM immediately when whatever you're doing asks for more. Having FREE RAM available just means that whatever else you want to do needs to get loaded into RAM, first — which actually costs time and battery life.
It doesn't help your system, at all; on the contrary.
Free RAM literally means that your system is not running as efficiently as it could be.
that's not what iOS is doing, now or never, on any of my iDevices, no matter what Mr "I-Know-Everything-You-Ignorant-Newbie" says .....
If I keep free RAM available my browsing/partial multitasking experience is substantially better.
that's not what iOS is doing, now or never, on any of my iDevices, no matter what Mr "I-Know-Everything-You-Ignorant-Newbie" says .....
If I keep free RAM available my browsing/partial multitasking experience is substantially better.
This is how it used to work:
http://www.speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html
So what it used to do is exactly what I describe, regardless of whatever you may choose to believe or imagine to have seen.
My understanding is that Background app refresh was added recently (and can be turned off), which allows suspended apps to jump on the periodic network checks to update their content, but that the multitasking is still the same, limited multitasking as Fraser Speirs describes above in 2012.
This is how it used to work:
http://www.speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html
So what it used to do is exactly what I describe, regardless of whatever you may choose to believe or imagine to have seen.
My understanding is that Background app refresh was added recently (and can be turned off), which allows suspended apps to jump on the periodic network checks to update their content, but that the multitasking is still the same, limited multitasking as Fraser Speirs describes above in 2012.
And again your link or BAR has nothing to do with the behavior I'm describing.
You have not enough free ram, tabs reloads. It is quite easy to understand.
If i close unused app that still have allocated resources, I free more ram, tabs stayed in the RAM.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is the second article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
Neil's big reveal that somehow killing background apps is never a good idea proves to me he is CLEARLY NOT A DEVELOPER. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
And again your link or BAR has nothing to do with the behavior I'm describing.
You have not enough free ram, tabs reloads. It is quite easy to understand.
If i close unused app that still have allocated resources, I free more ram, tabs stayed in the RAM.
No, that is, quite simply, wrong.
If you do not have enough free RAM, iOS will THROW EVERYTHING ELSE OUT OF MEMORY the microsecond your app asks for more.
It's right there in the link you didn't read:
The first technical caveat is that Suspended apps remain in the device's memory. This is so they can resume more quickly when you go back to them. They're not using processor time and they're not sucking battery power.
You may think that, if an app is resident in memory, you have to somehow remove it to conserve memory. You don't because iOS does it for you. If there are Suspended apps lying around and you launch a memory-intensive app such as a big game, iOS will start to purge Suspended apps and move them to the Not Running state. That is, they will be completely removed from memory and will launch afresh the next time you tap their icon.
Quitting apps does absolutely nothing the OS wouldn't do by itself. If you're seeing an improvement in tab reloading, that's due to improvements Apple has made to Safari — in fact, everybody has been seeing that.
No, that is, quite simply, wrong.
If you do not have enough free RAM, iOS will THROW EVERYTHING ELSE OUT OF MEMORY the microsecond your app asks for more.
It's right there in the link you didn't read:
Dude stop lecturing me, Im an apple user since you was in the kindergarten ....
I'm speaking about THE SAME app (safari) with multiple tabs.
iOS can't purge anything, it just reloads tabs when switching between them.
I don't need any link to know how it works.
iOS is FULLY multitasking and always has been.
That does not mean that apps themselves were or are fully multi tasking. The OS may limit what processes can run under what circumstances. But the OS itself is fully multi tasking. It is a full mach kernel "unix" type system.
This is unlike the old Mac OS system prior to OS X that had a cooperative multi tasking system.
Dude stop lecturing me, Im an apple user since you was in the kindergarten ....
I'm speaking about THE SAME app (safari) with multiple tabs.
iOS can't purge anything, it just reloads tabs when switching between them.
I don't need any link to know how it works.
Sorry, I expanded the post slightly before you replied.
It really doesn't matter what you think. That's just not how it works.
I also appreciate the weird authority argument. I really don't see how relevant it is that you may or may not have been using a first-generation Apple II that was current when I was in kindergarten back i n 1978. It has absolutely nothing at all to do with how iOS manages memory, nor the fact that you seem insistent upon reliving OS 9-induced habits some 18 years later.
Neil's big reveal that somehow killing background apps is never a good idea proves to me he is CLEARLY NOT A DEVELOPER. I am. If you have "background refresh" enabled I can write an app that will suck down your battery all day long. It can't if it isn't running in the background - period.
Also, let's face it IOS is UNIX which has been around for almost half a CENTURY....and in that OS, there IS also a valid reason to kill off misbehaving or RAM-hogging background apps occasionally, so why would you think that IOS is somehow immune, because Apple re-branded it?
Almost 30 yrs as a DEV, and an IOS user since apple introduced multitasking and periodically killing off all my unused background apps, I'll keep my KillBackground tweak, please, and thank you. (Now, we just need to pray the DEV with that code updates with new SDK for ios9 soon)
This is now the second totally idiotic article recently claiming that a BSD-based UNIX OS cannot possibly suffer from poorly written applications on devices with limited RAM connected to an app store offering the device user access to literally MILLIONS of applications. As a jailbreaker, I'll ask Neil, have you ever even loaded your IOS device with over say, about 490 applications? Do it on a 3gs and try to boot - JUST BOOT before launching a single app! Same BSD-based OS, and boy, according to Apple there is no hard "limit". Try it. Last I tried I got about to 490 before the OS itself just from simply LOADING THE LIST of app info crashes and in the following years was proven by others.
I digress. Back to your points. Yep, you got the basic Wikipedia info right on the possible app states for backgrounding, etc. So tell me, what state is any app automatically in by the time you hit the skull icon in KILLBACKGROUND to kill it? Here's the real epiphany, by the time you double-press home and tap kill, EVERY APP except the foreground app is already in a suspended state and ONE HUNDRED PERCENT SAFE TO KILL - why wouldn't it be? Even by your own logic, it's inactive and saved it's state, right? Whew - super - that's what I wanted - an app that saved it's state and CLOSED COMPLETELY WITH ZERO CHANCE OF BACKGROUND ACTIVITY OR RAM USAGE. To me, using your argument it sounds like everyone should kill off the already suspended apps!
I challenge anyone to show any evidence that killing off already suspended apps from the task-switcher (and the underlying UNIX OS) is harmful in ANY way or uses any more battery in fact does not save battery in the long run. This and other recent articles are nothing more than a non-Developer's opinion with zero actual metrics to back them up.
So please, before writing another BS story like this that the masses may actually live their life by, do some research or be prepared to provide evidence!
And another sad fact: I have repeatedly seen "tech news articles" in local (German) news magazines where the authors advise you to do that stupid swiping work regularly. Sad. Really sad. They have no knowledge, but they try to teach people.
Background refresh is garbage. iOS checks for too many things all the time. iOS is 4 steps behind the competition. RAM=random access memory. iOS doesn't use RAM properly and neither does OSX or any of the Apple OS's.