51

I know apparently it’s not a good idea to close apps on your iPhone to save on battery. I’ve read questions and answers like Does force closing apps have any benefit on iOS devices? but it still doesn’t quite gel with me. Sometimes I have found over 50 apps running, so not closing them makes no sense.

Maybe I’m a bit of an old chook and you just can’t teach old dogs new tricks, but can someone here explain WHY it’s better to just keep all these apps running? And when I say “explain” I mean in layman’s terms so I can understand.

spacetyper
  • 1,369
  • 2
  • 15
  • 22
F.C
  • 513
  • 1
  • 4
  • 6
  • 31
    The misconception is the „running“ part. Apps in the Switcher are not necessarily running, most of them actually are not. Think of it more as a „most recently used“ list than a process monitor – nohillside Nov 14 '17 at 08:32
  • 3
    Like patrix, I would like to add that iOS closes apps by itself when it's running out of memory, so even though it looks like 50 apps are "running", if you're watching a video there's a huge chance the other 49 have actually been terminated after 2/3 minutes. The app switcher only shows a recent screen capture of those apps at this point. – Coded Monkey Nov 14 '17 at 10:26
  • 5
    @CodedMonkey I mostly agree with your comment, however the one clarification I would make is that the other 49 wouldn't be terminated, they'd be suspended. The difference is that when an app is terminated it is no longer resident in memory, whereas being suspended means it isn't visible on screen, nor is it executing code. In this state it's not using the processor or battery, but is still resident in memory. However, all that said, using your example, my guess would be that iOS may actually terminate some of the other 49 apps, but keep most of them in a suspended state. – Monomeeth Nov 14 '17 at 10:50
  • 8
    We probably need to address the elephant in the room - what makes you say "just keep all these apps running" - and what specifically is "close the apps" - iOS 11 runs three apps maximum and some apps get periodic background activations (by design) if we're talking about the OS in broad strokes / layman's terms. If this is meant to air out the debate of whether to remove the saved app image thumbnails from the multitasking UI - let's just clear that up in the question. – bmike Nov 14 '17 at 12:03
  • 3
    I really horrify my friends by having (right now) 314 tans I safari and 57 apps “open”. – Tim Nov 14 '17 at 12:50
  • 1
    @Monomeeth There is no way iOS will keep 50 apps suspended at the same time, unless each of them has a truly microscopic memory footprint. I'd estimate, based on my own devices and use pattern, that only the most recent 3-10 apps are kept in suspended mode. If I spend a long time in a single large app (YouTube, Twitter, Safari, etc) even the *next most recently used app* gets a full reload when I switch back. Clearly more ram would improve this somewhat, I use an iPhone 6 with 1GB RAM. – BradC Nov 14 '17 at 19:06
  • 1
    @BradC Everyone's experience will differ, not only because of the amount of RAM their device has available, but also because of the apps they use - both points you rightly acknowledge. :) In my *personal* experience with an iPhone 6s (2GB RAM) and the apps I regularly use, I don't often experience a full reload - it's certainly a lot less than it used to be on, say, an iPhone 5 with 1GB RAM running iOS 8 - but of course not as good as newer models with 3GB RAM running iOS 11. Bring on next year and we'll likely have 4GB RAM in new iPhones. – Monomeeth Nov 14 '17 at 21:39
  • @patrix it's hard to think of it as "recently used" when it remembers where you left off, but doesn't if you "close" it. – ESR Nov 15 '17 at 03:21
  • 1
    @EdmundReed Keeping a restart state is possible even without the app running. And not all apps actually support this. – nohillside Nov 15 '17 at 07:43

5 Answers5

65

You’re not alone. People are just used to their desktop computer habits, and it’s understandable they carry these habits over to their iPhones and iPads.

However, let me try and explain this using an analogy:

Imagine it’s a hot day and you’re outside gardening. You get thirsty, so you go inside to the kitchen, grab a large glass, put some ice in it, and fill it with water. You then drink half of it and empty the rest in the sink before going back outside. Not long later, you get thirsty again, so you go back inside to the kitchen, grab the same glass, put some ice in it, and fill it with water. Again you only drink half of it and empty the rest in the sink!

The above workflow just doesn’t really make sense. Why wouldn’t you take the glass outside with you? And, you’re not only wasting water by emptying it, but you’re spending more time and energy getting that water again.

Likewise, when you quit an app you’re actually using some battery power in the process of doing so (e.g. clearing it from RAM, etc) and then again later when you have to launch it again and load it back into RAM.

So, for a great majority of the time it’s best to leave apps open. Even though they’re open, they’re really just sitting in a type of suspended mode that isn’t using any battery power whatsoever. Yes, the app is still loaded in RAM and taking space, but it’s not actually doing anything - it’s just lying there dormant. And, because it’s not using any battery power in this state, there’s no advantage to quitting it from a battery conservation point of view - especially if it’s an app you know you’re going to be using again and again throughout the day.

There’s also really no advantage to force quitting an app because iOS itself will do this for you if/when it needs to in order to free up RAM. So if you have 50 apps open and they stay open, then iOS hasn’t been pushed to the extent of needing to close any of them to free up memory.

Now, like anything, there are always exceptions to the rule (such as apps that have to perform background tasks). An example of this is one that plays music while you’re doing other things with your phone, or one that’s downloading content in the background, or one that’s counting how many steps you walk in a day, etc. However, iOS has an extremely efficient process for managing background apps/tasks and if you choose to quit these you’re basically saying you don’t trust the operating system to do its job properly.

So, feel free to quit your apps when you have to (e.g. because it’s frozen, etc), but don’t do it to conserve battery power. In fact, if you do, you’ll be achieving the opposite and using more battery power throughout the day!

Summary

  • You only need to quit apps if they're not working properly (e.g. an app has frozen, it isn't displaying properly, etc).
  • Apps listed in the App Switcher are not necessarily running - in fact most of them are not running at all.

  • Most apps in the App Switcher will be in a suspended state - this means they're not: visible on screen, executing code, using the CPU or GPU, or using the battery. However, they are still resident in memory until they are purged (if necessary) by the system to free up memory:

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

    Source: See Table 2-3 within the first reference link at end of this answer.

  • The only apps actually running on your iPhone at any given point in time are the active app (i.e. the one visible on screen) and any others working in the background. (Note: There are some temporary exceptions to this in the case of apps that still need time to complete executing code they already started while they were active - typically this is only in the order of seconds but could theoretically extend to over a minute.).

  • In terms of apps running in the background, you can control which apps are permitted to do so (if they're open) by going to Settings > General > Background App Refresh. (Note: Just because you see an app listed here doesn't mean it will run in the background, but disabling it here means it definitely won't!)
  • If your iPhone is locked, then the app that was active (i.e. it was visible on screen) when you locked your device is now inactive. However, unless you've only just locked your iPhone and it's still finishing executing code or it's running in the background (e.g. playing music, etc) then it's not using the CPU, GPU or battery.

References

  1. For more info about the various states an app can be in, refer to Apple's App Programming Guide for iOS: Execution States for Apps.
  2. For more info about apps running in the background, refer to Apple's App Programming Guide for iOS: Background Execution.
Monomeeth
  • 63,349
  • 14
  • 147
  • 188
  • 9
    *So if you have 50 apps open and they stay open, then iOS hasn’t been pushed to the extent of needing to close any of them to free up memory* To be clear, there's no way that you can tell whether the apps in the app switcher are truly open (ie, resident in memory) or not. – MJeffryes Nov 14 '17 at 10:29
  • 1
    If an app is listed within the App Switcher, this means two things: 1. it was launched at some point, and 2. it hasn't ben terminated. Both these actions can be performed manually by the user or automatically by iOS. So, if an app is still listed in the switcher then yes, it is still resident in memory. If it's not listed, then no it's not resident in memory. However, just because an app is resident in memory doesn't mean it's using any battery power. In practice there's really only two states under which an app uses battery power, when it's active and when it's running in the background. – Monomeeth Nov 14 '17 at 10:44
  • 24
    What's draining the battery is _starting the app again_. Suspending an app is cheap. Resuming a suspended app is cheap. But needing to completely load the app from scratch takes a lot of resources (even if some of them may still be cached): the OS needs to load the app and all its dependent frameworks, the complete app startup code needs to run again, etc. – DarkDust Nov 14 '17 at 10:46
  • 5
    I had always thought that the switcher lists all apps ever opened on the phone up to some maximum limit, in the order they were last used, regardless of whether they were in memory or not. If I scroll back sufficiently far, switching to an app will provoke a fairly long pause as (I assume) the app is loaded from disk. Is there any documentation which confirms your view of its behaviour? – MJeffryes Nov 14 '17 at 10:48
  • 1
    @MJeffryes When I get a chance I will update my answer to also provide a more succinct summary in bulleted form and to add some links to Apple Developer articles. – Monomeeth Nov 14 '17 at 10:54
  • Love that analogy! – Andre Nov 14 '17 at 16:30
  • 7
    This is a useful answer, but there's no way that iOS would keep 50 apps all suspended, unless each of them has a truly microscopic memory footprint. I switch between large apps all day (Safari, twitter, Facebook, Reddit, YouTube, etc), and I often get a "full reload" switching back to an app only 2 or 3 cards down the most-recently-used list. – BradC Nov 14 '17 at 19:03
  • 3
    @Monomeeth Plenty of apps that are effectively terminated - i.e., require a full reload to resume - are in the app switcher. iOS won't completely terminate, I don't believe, unless there's been a crash - it just stays in the app switcher, not resident in memory and just more or less a convenience to access more readily. – Joe Nov 14 '17 at 20:58
  • 1
    This doesn't make sense to me. I use quite a few audio/music creation apps and leaving them open "in the background" absolutely kills my battery life, even if they are doing nothing (and do not have backgrounding enabled in settings). iPhone SE, 64GB. Also (and potentially not relevant anymore) back in the iOS 6 days on my 4s, Skype being open in the background would eat my entire battery in an hour or two. Thankfully as of iOS 10 this is no longer the case. – JVC Nov 14 '17 at 23:35
  • @JonathanvanClute Then those apps are poorly designed; a well-behaved app shouldn’t do unnecessary work in the background for that reason. – NobodyNada Nov 15 '17 at 00:17
  • 1
    I guess there's a lot of poorly designed apps from major corporations then. What a shame. – JVC Nov 15 '17 at 01:15
  • @MJeffryes I've updated my answer to summarise it and include references (with links) to Apple Developer articles. Hope this helps. Let me know if there's anything else you'd like to see. – Monomeeth Nov 15 '17 at 09:07
  • As stated in comments from Mjeffryes, BradC and Joe, it's not because an app is present in the app switcher that it is actually loaded. iOS keeps a screenshot of the app, and can terminate it if it needs the memory (which happens quite often). When switching back, iOS will show the screenshot rather than the splash screen, and if the app implements everything it should (which is rarely the case), it can restart exactly where it left off. Otherwise you'll just get the same result as if you had freshly started the app. – jcaron Nov 15 '17 at 10:40
  • @Monomeeth The references are good, but they don't actually support your assertion that all apps in the switcher are resident in memory. The only reference to the "multitasking UI" is that users can explicitly close an app from it. That doesn't imply that all apps that are in it are open. Imagine that you use a very memory intensive app. Your hypothesis is that if you were to open the switcher, it would be empty. In practice, this has never happened to me, and I think this behaviour would be so confusing to users that Apple wouldn't ever implement it this way. – MJeffryes Nov 15 '17 at 11:16
  • Very bad analogy. Ice melts when you're not drinking it, that's why it's obvious why you need fresh glass every time. The whole point is that frozen app doesn't experience any deterioration, nor it obstructs other apps as glass of water would obstruct your workstation. – Agent_L Nov 15 '17 at 12:20
  • @MJeffryes I’ve clarified my 3rd bullet point as I can see that it was a little ambiguous. However, in reference to the example in your comment, this isn’t a real life possibility as iOS does not allow a single app to be allocated more than a particular percentage of RAM. In other words, no single app could ever result in the purging of all suspended apps! Any app that requires more RAM to run than the system will allocate will either crash or, if designed properly by the developer, will save its data to a temporary file and perform any processing on that (e.g. by using memory mapped files). – Monomeeth Nov 15 '17 at 13:00
  • @Monomeeth Sure, it was a thought experiment. Although I suspect on some lower end iOS devices, a single app could consume almost all the available memory. Thanks for the clarification, I think that makes your answer accurate. – MJeffryes Nov 15 '17 at 13:11
  • A better gardening analogy: you go inside to get a glass of water, but before you do, you put all the tools you were using back into the shed. Then, when you come back out to continue working, you have to take all the tools out again. – Harrison Paine Nov 15 '17 at 19:20
  • Brilliant! Thank you for explaining this. This old dog now has reason to learn new tricks. – F.C Nov 16 '17 at 13:06
22

The provided answers are accurate, I just want to clarify from an iOS developer’s point of view.

iOS is designed to manage as many things as possible so you (and developers) don’t have to worry about them. The end result is a somewhat consistent approach across applications, including those from Apple (even tho sometimes Apple itself cuts some corners).

That being said, the premise is:

  • iOS knows more about memory than us. It knows how much it has, and how much it needs (to a certain degree).
  • iOS has full control over the memory; it has the final word on who uses what.
  • If iOS needs memory, it will find it, and this is usually done by killing other processes that have been idle for some time (and there are many rules behind the scenes, we don’t know them all, and we don’t really worry about them).
  • Everything a Processor (CPU) does, takes energy. Absolutely everything. Don’t forget computers are just very tiny electron containers that move them around in very tiny spaces.
  • When an app is killed, there are some agreed protocols (contracts) that define what needs to be done. iOS enforces and carries these protocols. But work must be done, it’s not free and certainly not always cheap (it really depends on what the App is).

Having said all that, one assumes most users close apps in the hopes to increase battery life, under the impression that, by closing things, then less energy is wasted in maintaining these apps running.

The truth is that, on iOS, this is almost never the case. When you press home, the app is suspended and it no longer uses resources that other app may need. If a new app (or even iOS) needs that memory, it will take care of it by itself, but only if it needs.

You closing the apps over and over, are forcing iOS to make that potentially expensive task of really unloading an app, saving its state and what not, with the added problem that when you re-open the app, all that stuff has to be reverted and, depending upon the complexity of the app, a lot of things must be read from the storage, up into the main memory of the phone, and so forth. All this extra work, could have been avoided if you simply let the app stay in its “suspended” state.

However …

In some instances (and they are rare but not impossibly rare), you want to kill apps that are misbehaving. Examples are (but not limited to): Apps that deal with background audio, or asynchronous services like location (where the app asks for a location and iOS must go and ask around where it is, for example, by firing the GPS if needed), video streaming, etc.

I’ve had countless instances of apps like Lyft, United Airlines, even Twitter, that end up in a broken state (or simply don’t properly work), either because you’re in a bad network (iOS has gotten really bad at recovering from some bad networks in the past 3-4 releases) or the network simply doesn’t properly respond.

In time, most of these problems tend to go away and the app starts working again; but if you really need the app to work now, then you have to go ahead and pay the price of having to kill it and restart it from scratch. You used more battery by doing that, but, hey, you needed it.

And if this was confusing, I can give you a car analogy, because that’s what we tend to do all the time.

The Car Analogy

I know that car technology has advanced and this is no longer a good example, but play with me here.

Firing a Car’s engine used to use more fuel than just idling. When cars had carburetors instead of injectors, this was even worse; that’s why turning your engine off when you stop at a red light, can theoretically use more fuel than just idling for a minute. Newer cars have a much more efficient mechanism and can stop the engine, but stay in a semi-started state (let’s not get too into cars here).

You closing apps, is the equivalent of a person turning the car off at every stop light. As opposed to just letting it idle until you need it again, normally a few seconds later.

The analogy is not perfect, for the truth is, idle cars still use fuel, whereas suspended apps don’t; however, In the eyes of the phone, they are not using anything memory/battery related (as long as they don’t have background processing of any sort active, obviously).

You’re basically turning your engine off every time you kill an app, and you’re not letting the iOS “smart” mechanism of idling your engine take care of it, so when the light turns green, you can simply press the accelerator and the engine is running faster than if it would have been 100% stopped. Starting an engine from a stopped state, also uses more power than just fuel, you need to turn the starter so the engine can be cranked, fuel injected and sparks created, so… it’s a lot of work behind the scenes. Apps are like engines. :)

Martin Marconcini
  • 21,730
  • 1
  • 59
  • 86
  • 1
    Haha, I like the analogy (and your answer). :) – Monomeeth Nov 15 '17 at 09:08
  • Question about your comment re: misbehaving apps: "[...] if you really need the app to work now, then you have to go ahead and pay the price of having to kill it and restart it from scratch. You used more battery by doing that [...]" Do you believe this to be universally more wasteful? While I don't quit apps otherwise, I often assume that a hung-up or otherwise troubled app is likely consuming a lot of resources by repeatedly trying and failing to do whatever it wants to do. I see that this could be less intensive than starting back up from scratch, you believe that is generally the case? – brhfl Nov 15 '17 at 18:29
  • 1
    @brhfl It’s tough to say, each app is a different world. There are some clear signs that something is wrong. If you phone gets very hot in a short period of time while you’re just trying to use an app, it may mean the CPU is being used, of if the phone feels sluggish (animations skipping frames for example). Those are good signs that something is using more resources than it should and in those cases killing the suspected app is the way to go. In general, if an app is suspended (background) even if it wasn’t doing great, it will have no choice but behave; or risk being killed by iOS. – Martin Marconcini Nov 15 '17 at 18:38
1
  1. If you force-shutdown an app entirely, then when you need to re-open it at a later time, the overhead associated with launching a new instance of the app is more CPU and energy intensive than just switching from one app to another.
  2. When an app is just sitting there in memory, unless it is actually built to run in the background, it is usually paused or killed and does not consumed any CPU cycle (usually). If it's a fairly simple app, then it will be just sitting there using memory. In such case, the app state is persisted somewhere else (on device storage in the case of Android) so that the app state can be restored later. To give you an idea, a rather long unsent message that I wrote in the Viber app in my phone survived a phone shut down due to battery depletion. After restarting the phone, then Viber, I found the message waiting for me to send it. Halleluja.
  3. Depending on your memory chip, whether it contains zeros or ones will not make any significant difference in the power consumption. So keeping stuff in memory of not won't significantly make you save battery.
  4. When an app is in super deep sleep (guys, please confirm this), only a reference to it will be visible in the app switcher as a snapshot of the last screen that was visible from it before going under. I am saying this because one day, I have decided to close all the apps in my iPad, and I was surprised by the amount of apps I had to close. It was more than 60 apps. These cannot be all held in the memory of the iPad. I saw some apps in there, that were used several months ago.

As an analogy ... with you car, if you need to make too many stops during the day and keep stopping and starting the engine, a time will come when the battery will be totally depleted. This can happen if the charging time while you are driving between stops is not long enough to restore the tremendous amount of energy that is sucked out of the battery every time you start the engine. Besides, it's not good for the starter and the overall gas consumption. That's why many delivery truck drivers will keep the engine idling during their short stops.

This analogy is IMO similar to the memory saving myth.

Abdoulaye Siby
  • 121
  • 4
-1

Just throwing a differing opinion out there for the sake of discussion. This concept has a certain degree of truth to it, but once you have a certain number of apps open, you're likely going to start seeing diminishing returns on keeping apps suspended.

The more apps you have open, the more ram is going to be getting used up, obviously. Typically each app in memory gets divided up as memory the app itself is actually currently using, memory that the app wants to have on hand, and memory the operating system actually allowed the app to use, which gives you the final amount of memory the app is allowed to use. The reason the app keeps a separate portion of this memory as memory it wants to use, is because the app may need to grow it's heap, but it doesn't necessarily want to do that right off the bat because it's bad for garbage collectors to have large heaps (large heaps = longer garbage collections), so the app will set aside a portion of memory not currently being used, but that can be used by the app exclusively if need arises.

Say the OS allows my app up to 700mb, and the app set's aside 300mb of that memory for itself, leaving 400mb out there for my app to use if it wants, but then another app opens and needs some memory; the OS looks at all the different apps, and decides if it's okay to pull some memory from another app and use it for the new app, in this case it may decide to take 150mb from my apps allowed memory and give it to the new app, requiring the memory to be swapped around to give the new app memory to use (think of this as a reallocation of funds in a business) well, the more apps you have open, the more work the operating system has to do to actually decide which app's memory it can siphon off to give the new app memory.

In this sense, every app that get's opened and the suspended adds complexity to this process, making it more CPU intensive, and eventually requiring potentially more battery power to open future apps than the battery power saved by not closing other apps.

Now mind you, none of that takes into consideration that unless you truly kill an app, there can be background services running that will eat up processing power, for example notifications set to notify you on a timer, etc. On the flip side, some apps don't use a true background service, and actually use push notifications from services like firebase, which don't require the app to be open at any point.

Another thing to consider, the more apps you continually open, the more fragmented that memory will initially be until the OS goes through and cleans up the memory to be more clean and laid out more efficiently, this itself also chews up processing power, and the more memory that is occupied by apps, the more intensive this process will be for your device.

All of this to say, leaving apps open is mostly more efficient, unless too many apps are opened, however I am not sure how many apps need to be open to get to this threshold, if the number exists.

Sources:

SGen garbage collector for Mono: http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

Overview of memory profiler for both iOS and Android Xamarin apps, which shows the way memory is managed by the app (working set, private bytes, memory allocated, etc.) https://blog.xamarin.com/say-hello-to-the-xamarin-profiler/

Trevor Hart
  • 107
  • 2
  • 1
    I'm not sure this is correct - are you an iOS developer? I believe that iOS can, at its own discretion, kill suspended apps as needed to free memory, but I strongly doubt it can *partially* reduce the memory footprint of a suspended app. At least as a user, it appears to be all or nothing. – BradC Nov 14 '17 at 19:53
  • Every single operating system I know of can partially reduce memory, so I'm not sure why it would be different in iOS, the key to what I'm saying though is the amount of memory the OS says the app can use, vs. what the app itself is actually using. In cases where the OS deems that there is plenty of memory to go around, it will often give a generous amount of memory to a process, even if the app only requests a fraction of that, then the OS will pull memory from that excess memory if it deems it necessary. – Trevor Hart Nov 14 '17 at 19:57
  • The reason for this is because if the app needs more memory, it's there for the taking, and the OS doesn't have to do more work to provide more memory to the app, this is generally a very efficient way of managing memory, so what I'm saying is if iOS doesn't do this, it would seems kind of foolish not to, and if you build an app with Xamarin (what I do), the mono runtime runs on top of the iOS runtime, and the SGen garbage collector definitely manages memory how I'm describing it, so it should be the same for iOS. – Trevor Hart Nov 14 '17 at 19:59
  • 2
    That's all true for "full" OS's doing simultaneous multitasking of fully running apps. That's not the case for iOS (except for newer split-screen configurations). I'm not saying I am *positive* you are wrong, I'm just saying your instincts from other OS's may not apply here. – BradC Nov 14 '17 at 20:09
  • You could be right in terms of pure native iOS, but like I said for Android, and for iOS apps written with Xamarin that utilize the Mono runtime, that is for sure how at least the Mono portion of the app works, I've seen it in app memory profilers, and I've verified it in the SGen garbage collector documentation and the Android documentation. – Trevor Hart Nov 14 '17 at 20:17
  • I've added some sources if you'd like to take a look and maybe we can have a more informed discussion on this, because if I'm wrong I'd like to know. – Trevor Hart Nov 14 '17 at 20:59
  • I wonder whether memory usage in Mono and Xamarin is representative for the majority of iOS apps or if these are special cases due to the cross-platform focus of the frameworks involved. – nohillside Nov 14 '17 at 21:17
  • 1
    And IMHO you confuse the app switcher with a list of „open“/„in memory“ apps. This is clearly not the case, so the memory footprint may very well be the same for an iPhone with 5 or 20 apps in the switcher – nohillside Nov 14 '17 at 21:20
  • It very possible, but I would be surprised if iOS didn't follow basic memory management schemes of every other platform including other mobile and embedded systems, especially since iOS supports this type of memory management with Mono apps, but again I could be wrong, I would like to see some documentation explaining how iOS does things for true native apps. – Trevor Hart Nov 14 '17 at 21:22
  • 2
    The Mono/Xamarin framework's memory management is not representative of how native apps/services work on the iOS platform. iOS and the Objective-C/Swift runtime do not implement garbage collection. – Mike Mertsock Nov 15 '17 at 04:33
  • @MikeMertsock see I didn't realize that, how does Swift do memory management if that is the case? – Trevor Hart Nov 15 '17 at 05:23
  • 2
    @TrevorHart it uses Automatic Reference Counting https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html – Mateusz Szlosek Nov 15 '17 at 07:55
-2

Clean cut version: It is better because the OS was designed to make it better to the point that the user would want to keep apps on (or in a "suspended" state) in order to gather more information on your actions[*] later if needed.

Longer version: Apps that are "suspended" will have their state saved in memory so once you want to start them back up the proces of loading everything back will require less time for the procesor and almost no use of the storage unit...With this you can't know if your apps are doing some other things in the background which in a lot of cases they sit there collecting data on you.

[*] To elaborate on the collecting data on you part... apps that are stored in memory can be either "suspended" or active in the background. You as the owner of the device can't know (if you don't possess the knowledge of and some other apps to actively scan CPU usage) what said app is really doing. From the point of view of security I'd advise to shut any app that you aren't going to use for the next 10 mins off.

P.S. This practice is done on Android devices as well btw ...

Monomeeth
  • 63,349
  • 14
  • 147
  • 188
Kaotis
  • 15
  • 1