Why do Apple Geniuses recommend killing apps manually?

[Brian Y]

I have mentioned several times that this isn't a problem if you are completely aware of the apps you're downloading and the quality of apps you're using.

But the developers skill in memory management has such a huge role in this all that it would be stupid to assume that because you're not experiencing the problem it's not happening to others.

BECAUSE iOS cannot pagefile it's exactly part of the reason that things can get more bad way more easily. The way ram is used it exactly like any other phone or system, an application written in C++ wil utilize ram exactly the way it does on iOS like it does on Android, as it would on Windows and Mac OS X. Given the parameters of ram available, and how much the system allows your app to have.

The difference with Major operating systems is that they get enough RAM thrown at them for the system to ever run out.

You obviously don't realise that iOS has ARC - which takes memory management away from the dev. Hence why iOS apps, etc, never have memory leaks.

Again, as I said to the previous poster, if you're going to argue this stuff, take the time to read the API. Everything you've written is debunked in publicly available api documentation. You can code an iOS app with no knowledge of memory management. Yep, none whatsoever.

Here is a rather nice article: https://developer.apple.com/library...sitioningToARC/Introduction/Introduction.html

 

[dejo]

You obviously don't realise that iOS has ARC - which takes memory management away from the dev. Hence why iOS apps, etc, never have memory leaks.

Well, I wouldn't say never. But certainly much less than during the pre-ARC days. All those retain and release calls. Oy!

 

[Serelus]

But how does iOS doing this take more battery than a user doing it manually?

Imagine situation 1:

I have 40 applications in the background suspended.
I play infinity blade, iOS closes 3 apps for RAM usage.(note these could be large apps that require processing to close or small apps, you don't get to choose)
inadvertently i'll be opening those 3 apps again through regular usage. Not taking into account that they might need to be closed again.

situation 2:
I have a maximum of 10 applications in the background suspended at all times.
Whenever playing processor intensive games, I close apps to keep myself to the 10 applications maximum.


In situation 1 your system is doing things in the background while you're actually USING the phone. Processor intensive or not, you don't know.

While in situation 2 most likely nothing is ever being done in the background.
Closing those 1 or 2 apps isn't going to be as processor intensive as it would when iOS would be doing it in the background while you're are playing a game.

----------

You obviously don't realise that iOS has ARC - which takes memory management away from the dev. Hence why iOS apps, etc, never have memory leaks.

Wow really? you think iOS apps never have memory leaks. Well I rest my case then.

 

[Dented]

Why has this thread become so convoluted....Okay, so the native apps that run on iOS 7 may not have any of this trouble. There are still plenty of other applications out there! There is no operating system that is flawless. They'll all have the potential to have issues such as RAM leaks, battery drain, etc.

Can't we all just agree to disagree? We'll always have people who view things differently. While there are facts to support both sides, I really just think it's a little of both.

This is nothing to do with native vs third party apps, it's about how IOS treats *all* apps and manages both their running state and the memory they're using.

Nobody's going to agree to disagree on this, because one side of the argument is grounded in documented fact and a solid understanding of what's actually going on in IOS, and the other side is a lot of superstitious voodoo. IMHO

 

[mattopotamus]

I totally agree about not really needing to clear out the apps, but some do drain the battery.

 

[chabig]

There is no "situation 1" and "situation 2" because iOS doesn't keep apps running in the background (with just a few exceptions).

 

[NT1440]

This is nothing to do with native vs third party apps, it's about how IOS treats *all* apps and manages both their running state and the memory they're using.

Nobody's going to agree to disagree on this, because one side of the argument is grounded in documented fact and a solid understanding of what's actually going on in IOS, and the other side is a lot of superstitious voodoo. IMHO

Right?

It's iOS developer documentation, straight from the dev portal (you know, the area responsible for giving developers the information they need to even make the apps) vs. "well hypothetically speaking..."

 

[I7guy]

Certain applications have to be given an order of importance to avoid them from interfering with the users main functions (dialer, etc). There is even a notion from this same source with tools for an application with RAM leaks. So is it not possible that any app has the potential to be the source of contention with RAM? Wouldn't it then be beneficial to self terminate the application?

https://developer.apple.com/library...ual/ManagingMemory/Articles/FindingLeaks.html

Edit: I guess my reasoning would be that if we truly never needed a "Task killer/Process manager", then why would iOS 7 include it? This OS is generally kept minimalistic to avoid any user created catastrophes. I can't see them adding a tool like this unless it's a useful addition to the function of the device.

I dont think the task killer is as such and I use the gmail app as an example. "Terminating" the gmail app still allows the receipt of gmail notifications. I think some apps are always proessing in the background and other apps not. I think the task switcher allows the user interface to be terminated dismissing all memory held by the ui.

----------

I am sorry, you seem to assume that iOS can perfectly allocate and predict wether or not an app has released enough memory to keep the system running smoothly. This is ludacris. Not even Large OS's have mastered this way of handling RAM, Mac OS X and Windows 7 all can easily come across these problems and they are way more advanced than iOS. Spare us the it's not happening to me, so it's not happening at all analogy. It doesn't apply for people who use apps of lower quality and who are actually in a situation where they require doing this. Also iPhone 4 and 4S have only 512 MB or ram of which iOS7 already uses half. With apps available in the app store that can easily take up way more than the tiny bit you have left, the method applied by apple is WAY to simplistic to handle those kinds of situations. If you're running an iPhone 5S you're not experiecing this problem obviously. But for those who have a lower grade phone this is a completely normal problem to have. If you know what you're doing however this shouldn't ever be a problem for you.

Windows core runs mission critical applications, so yes microsoft has figured out memory management on a properly configured system with properly coded applications. I do admit taking away the paging file in windows is the kiss of death.

 

[chabig]

I dont think the task killer is as such and I use the gmail app as an example. "Terminating" the gmail app still allows the receipt of gmail notifications. I think some apps are always proessing in the background and other apps not. I think the task switcher allows the user interface to be terminated dismissing all memory held by the ui.

The gmail app doesn't run in the background. It uses Apple's notification service to tell you when new messages arrive. The app doesn't run until you launch it.

https://developer.apple.com/library...Conceptual/RemoteNotificationsPG/Introduction

 

[I7guy]

The gmail app doesn't run in the background. It uses Apple's notification service to tell you when new messages arrive. The app doesn't run until you launch it.

https://developer.apple.com/library...Conceptual/RemoteNotificationsPG/Introduction

Good to know, thanks.

 

[Serelus]

There is no "situation 1" and "situation 2" because iOS doesn't keep apps running in the background (with just a few exceptions).

Apps suspended in the background still require ram. Closing these apps, and reassigning shared memory/virtual memory requires processing.

Just because apps are frozen/suspended in the background doesn't mean it's not using up system resources. In fact, in the situation I represent, it's actually working not working in your favor.

 

[Dented]

Apps suspended in the background still require ram. Closing these apps, and reassigning shared memory/virtual memory requires processing.

Just because apps are frozen/suspended in the background doesn't mean it's not using up system resources. In fact, in the situation I represent, it's actually working not working in your favor.

Please just do some research. You can repeat this stuff till you're blue in the face, you're still flat wrong.

 

[Brian Y]

Apps suspended in the background still require ram. Closing these apps, and reassigning shared memory/virtual memory requires processing.

Just because apps are frozen/suspended in the background doesn't mean it's not using up system resources. In fact, in the situation I represent, it's actually working not working in your favor.

I guess you must just be trolling now.

 

[dejo]

Closing those 1 or 2 apps isn't going to be as processor intensive as it would when iOS would be doing it in the background while you're are playing a game.

And you know this how? Please provide some solid evidence that this is the case. I'm willing to be proven wrong. Until then, it's just speculation.

 

[chabig]

Apps suspended in the background still require ram. Closing these apps, and reassigning shared memory/virtual memory requires processing.

Just because apps are frozen/suspended in the background doesn't mean it's not using up system resources. In fact, in the situation I represent, it's actually working not working in your favor.

When an app is suspended, it's state is saved to permanent storage. It isn't using RAM. See http://support.apple.com/kb/HT4211

It says that apps in a suspended state, "are not actively in use, open, or taking up system resources".

 

[GreyOS]

When an app is suspended, it's state is saved to permanent storage. It isn't using RAM.

Um, from Apple on the Suspended state:

"The app is in the background but is not executing code. The system moves apps to this state automatically and does not notify them before doing so. While suspended, an app remains in memory but does not execute any code.
When a low-memory condition occurs, the system may purge suspended apps without notice to make more space for the foreground app."

https://developer.apple.com/library...cationsFlow/ManagingYourApplicationsFlow.html

 

[chabig]

Um, from Apple on the Suspended state:

"The app is in the background but is not executing code. The system moves apps to this state automatically and does not notify them before doing so. While suspended, an app remains in memory but does not execute any code.
When a low-memory condition occurs, the system may purge suspended apps without notice to make more space for the foreground app."

https://developer.apple.com/library...cationsFlow/ManagingYourApplicationsFlow.html

It stays in memory so it can be quickly launched. But it's state is saved and the memory can be taken for another task without doing any housekeeping.

 

[charlituna]

If the app has been designed properly, when it is selected again it should resume exactly where it was unless the designer determined that resuming is not needed.

In short, you shouldn't have to close your apps

Key words here: if and should.

In my experience more often than not they aren't designed properly and thus the need to force quit when you shouldn't have to

----------

Yes, exactly. My question for all of you is why have the Apple store employes been trained to recommend the opposite, even going back to iOS 6 days.

Any apple store employes have thoughts?

SO of an employee and he says the reason they tell folks that is because the world is not ideal. They have encountered plenty of apps with scads of crashes, which shows them that something isn't coded properly. Facebook, Instagram and Grindr are three items often seen with screen after screen of crashes for periods as short as one day.

Rather than try to explain to techno moron customers (which is like 99.9% of the folks they see most days) how to search out which apps are the likely culprit and just quit those to try to band aid the wounds they cause, they suggest folks clear out the whole list. It's just easier for folks to understand than the long but more precise version. And it catches apps causing issues with properly written code that is still off (like accidentally telling it to run a loop 1000 times when you meant 100)

----------

Not having a single button to kill all apps is the single biggest oversight in the ios 5 years running. It would be so easy to implement to.

What would be even easier is for folks to get the code right in the first place.

If anything Apple perhaps needs to be scanning the binaries for certain areas of code that can create issues. Make sure they are correct. It would delay approval but it would be worth it.

Or even perhaps offer some kind of paid service where an apple certified 'expert' will review your code before submission for such issue spots. Second set of eyes can be great for catching odd bits, reducing complaints about bugs you have to fix later etc.

----------

The Facebook app is a confirmed killer of battery. Even with background app refresh disabled, and having it as the only background app in the task switcher, it absolutely eats up the battery. Even more ridiculous is that even leaving the app for as little as 5-10 seconds, then open it again, and it has to reload everything / lose your place. It's the worst of both worlds...

Yep that one has been hideous for a while. And yes it would be a killer feature for them to have it set to reload to the last read entry rather than the top.

----------

In practice there are misbehaving apps that don't comply with the theory and can mess things up.. But I maintain the solution is to weed them out and replace them if you encounter those sorts of issues, not get into some pointless daily routine of shutting down a hundred perfectly functioning (and mostly completely inactive) apps just to work around that one bad egg.

Yep and if you are turning up at the geeksquad, apple store etc then you are typically there because something isn't working right. Perhaps it is in your head, perhaps your combo of apps has a rogue one or two. So in your case, things aren't ideal and thus ideal world notions don't fit.

Also I wonder how many times someone has actually gotten that advice from a 'genius' and not some random blue shirt and assumed they are all techs. I know my own parents have done this a lot.

My SO had said that at his store the managers put their foot down on non tech staff doing trouble shooting etc cause they have often told totally bad info or reset something that then totally ruined crash logs etc that the real techs needed to try to sort out the issue. Especially now that, by corporate system, there is a tech set aside off the appointment schedule, to do those sorts of tests and quickie questions like showing folks they have do not disturb turned on etc

----------

Nope. IOS manages its own ram and shuts down apps long before lack of memory comes anywhere close to affecting the system.

In an ideal world. But many apps aren't written properly and thus they can overload the system no matter how much it tries to manage things. Until you force them to stop

And this ideal world also includes iOS. If it is written perfectly then things work as intended. But clearly it hasn't ever been or we wouldn't have things like 7.0.1, 7.0.2 etc. Those weren't about adding features

 

[GreyOS]

It stays in memory so it can be quickly launched. But it's state is saved and the memory can be taken for another task without doing any housekeeping.

you said "When an app is suspended, it's state is saved to permanent storage. It isn't using RAM."
that was false. it could be using RAM, though not necessarily. thanks

 

[Serelus]

And you know this how? Please provide some solid evidence that this is the case. I'm willing to be proven wrong. Until then, it's just speculation.

the difference is there's a side step, iOS first asks suspended apps to free up virtual memory. While shared memory is fine, then and ONLY wil it begin the process of freeing up memory, which might not even happen at all. This process gives a solid 5 second interval for all apps to give up enough memory. If they don't iOS starts closing things.

This as opposed to you clearing out 1 to 5 apps without first checking if those apps can free up memory first, is MOST definitely less processor intensive. No speculation here.

 

[jr866gooner]

Just like apples advice on charging...when I picked up my 5c I asked about the first charge. In recent years I was told by cpw etc to charge constantly for 17 hours on first charge. Apple said to go to 100% and let it drain to empty then charge again and to do this once a month.

Apple said that what I was doing with my galaxy s2 and ip4 topping up each day was wrong! Who an I to believe about that!?

 

[Shuri]

the difference is there's a side step, iOS first asks suspended apps to free up virtual memory. While shared memory is fine, then and ONLY wil it begin the process of freeing up memory, which might not even happen at all. This process gives a solid 5 second interval for all apps to give up enough memory. If they don't iOS starts closing things.

This as opposed to you clearing out 1 to 5 apps without first checking if those apps can free up memory first, is MOST definitely less processor intensive. No speculation here.

Nope, try again..

iOS does not ask suspended Apps to free up memory, it just terminates them.

What you're referring to is background apps which are not killed permanently, but asked to free up memory and if they don't: they get killed. Sure this is slower then manually killing them, but either you want them to be in the background to fulfill a service you are currently needing (such as navigating), so it would be a bad idea to close the app in the first place or you don't want them to do anything in the background, then you might want to deactivate background refresh for this app.

All these information are from the iOS Programming Guide, I don't mind posting the source as it has been done before.

 

[Brian Y]

the difference is there's a side step, iOS first asks suspended apps to free up virtual memory. While shared memory is fine, then and ONLY wil it begin the process of freeing up memory, which might not even happen at all. This process gives a solid 5 second interval for all apps to give up enough memory. If they don't iOS starts closing things.

This as opposed to you clearing out 1 to 5 apps without first checking if those apps can free up memory first, is MOST definitely less processor intensive. No speculation here.

Dear lord, you really don't understand this stuff do you?

Do me a favour, never develop iOS apps. In fact, stay away from computers in general.

 

[Serelus]

Dear lord, you really don't understand this stuff do you?

Do me a favour, never develop iOS apps. In fact, stay away from computers in general.

No need to involve any lord, or get hostile. I just stopped paying attention to you as you seem to think iOS apps don't have memory leaks.

 

[Septembersrain]

No need to involve any lord, or get hostile. I just stopped paying attention to you as you seem to think iOS apps don't have memory leaks.

Some people will always think that there can be a "Perfect" system. Unfortunately there will always be flaws. Electronics are made by humans, errors are inevitable.

And I agree, no God needs to be pulled into this. We're talking science here.