The Force Quit Fallacy

As a former Apple Genius and independent Mac Certified Technician, I have seen my fair share of technology problems. Matters have only worsened with the rise of smartphones. Now it’s hard to remember life before smart devices. Yet there remains a lot of urban legends among smartphone users — from people using a microwave oven to charge an iPhone’s battery, to software updates that make an iPhone “waterproof”. A recent misconception is less destructive, and even has a sort of logical undertone to it, flawed as it may be.

The issue: force-quitting your iOS apps.

To be perfectly clear in the meaning of “force-quitting” specificially I mean swiping up to close an app from the chooser. You can’t go outside without seeing “normal” people force-quitting apps — this can cause even the most seasoned of us to cringe. It has gotten to the point that I hear this erroneous advice being handed out freely, even by people who should know better. To this day most people assume force-quitting iOS apps will preserve battery life and increase performance.

How Force-Quitting Came About

In order to fully understand the problem we must first go back to the beginning. Apple introduced multitasking and the backgrounding of apps with iOS 4. This was the very beginning of the fallacy.

iOS apps have one of five states of existence:

  1. Not Running
  2. Inactive
  3. Active
  4. Background(ed)
  5. Suspended

States 1, 2, and 3 don’t pertain to multitasking or backgrounding, so we can leave them be. This leaves us to consider states 4 and 5 — Background and Suspended.

Apple defines both of these states in the App Life Cycle Developers Guide:

Background — The app is in the background and executing code. Most apps enter this state briefly on their way to being suspended. However, an app that requests extra execution time may remain in this state for a period of time. In addition, an app being launched directly into the background enters this state instead of the inactive state…
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.

A backgrounded app is limited in both time and level of access to system resources. Background mode was originally intended to be a “cleanup time” that the developer could use to prepare the app for the next launch. Over the years it has evolved to include activation from push notifications and additional background processing. However, with this expansion of power, Apple has added several user level alerts to inform the user of background activity.

Apple has restricted long-running background tasks to playing audio, recording audio, location updating, VOIP, downloading and processing critical data, and receiving updates from accessories. In order to use long-running background processes the app must declare which tasks it wishes to perform in the info.plist. If you really want to see if an app can run indefinitely in the background, examining the info.plist is a good place to start. Yes, there are some notable problem apps on the market that selfishly grab cycles in the background and drain your battery, but they are in the minority, and Apple has continued to make great strides to restrict these apps.

There are two types of background activity: short running and long running. Short running activities will be completed in just a few minutes, while long running actives are almost always obvious to the users. Force-quitting an app that is playing audio or using your location in the background will of course benefit battery life, but most apps do not fall into this category. Those that do are typically apps that you want to be running while backgrounded.

Most apps that appear in the app switcher are part of the “Suspended” state group. These apps are using no battery, processor, or network time. They do use a small amount of passive memory to enable quick relaunch through app state persistence. If the device runs out of memory, these apps will be purged. Keeping an app Suspended allows for faster relaunching and state restoration than a cold launch provides. This was Apple’s intention when creating the suspend state for apps since Apple always wants to make sure the device is providing the fastest experience.

Back to the Matter at Hand

This is where urban legends begin. Many people think that force-quitting these apps will at the very least do no harm since “they aren’t running anyway.” The logic of “…you might as well quit, just in case” comes into play. The problem is that force-quitting apps that are Suspended, and not taxing the battery, produces negative effect and can do quite the opposite of the intention.

If you force-quit an app, it’s removed from memory, its state is instead saved to disk, and the app is closed or quit. This event triggers a multitude of tasks from disk i/o, to memory swaps, and even cpu cycles processing data. If the app is relaunched, additional resources are required to open it from a closed state as opposed to the faster Suspended state. Since the OS manages purging apps when memory is already low there is no benefit to force-quitting suspended apps, unless of course they are misbehaving and need to be relaunched.

Let us put an end to the misinformation right now.

Force-quitting suspended apps will, under most circumstances, drain your battery faster than simply waiting for the user to return.

The very process of quitting an app will use up a measurable amount of battery life. There are times when the device may need those resources and it will quit the app on your behalf, which will drain the battery in the same fashion. However, modern smartphones have an abundance of memory and you would be surprised how often an app can just stay suspended forever. This is doubly true for any app that you are frequently launching and using, these apps in all likelihood will never need to be closed and the repetitive exiting and relaunching can have a very noticeable toll on your battery life.

The only time you need to force-quit an app is if it is frozen, or otherwise misbehaving — beyond that the best battery life can be attained by not force-quitting any apps.


MartianCraft believes in software as a positive change for the human experience. Their proven approach to software — a deep focus on the customer — advances the state of the art for clients. What can MartianCraft do for you?