I was trying to determine why all apps were crashing on a phone when I looked at the storage and saw it was completely at-capacity. I tried restarting and exiting all background tasks to no avail. The entire 32GB of storage was shown as being used, and as soon as we deleted an app that took up a sizeable chunk of disk, everything started working again. And many people have the same issue.

This, however, goes against my intuition as to memory management coming from a computer science background — iOS does not swap pages to the disk, so we wouldn't need to reserve space on disk for this. In addition, it's not an issue with RAM as exiting all running background apps didn't change anything, nor did restarting the phone.

I understand that the kernel would kill processes if it were an affair with RAM contention and resident pages in RAM getting too high, but that's not the case here. So my question is then, if there is no swapping to disk, and it's not a RAM affair, what is the most likely cause for apps to all completely crash like this without even starting up? I'm assuming they're not all trying to write to disk on startup...

  • Welcome to Ask Different. From your computer science background, which operating system operates without storage for the OS to manage it’s data, tasks, process tables and such? Lack of storage for unix based OS is generally cause to panic and stop operations in my experience. Your tests seem to indicate the system is staying healthy by killing user space processes so you can investigate and preserve critical functionality. What practical problem (per How to Ask) are you looking to solve?
    – bmike
    Jul 17, 2020 at 6:57
  • Thank you for your response @bmike — first, I would think that iOS, given its user-centric model, would allocate enough to the OS at least a partition of disk that wasn't available for user-space processes, i.e. I'd be surprised if iOS let disk be filled so much so that there was actually no space left for kernel structures. And to support that, the OS itself was not displaying any visible signs of panic with no storage. So I'm trying to understand why they're crashing — is it just all user-space processes trying to write to disk on startup? Or something deeper I'm not considering.
    – rb612
    Jul 17, 2020 at 7:14
  • What method did you use to delete storage or apps?
    – bmike
    Jul 17, 2020 at 7:17
  • I found the app itself on the home screen and deleting it, and immediately free space started to show in the storage panel. So I suppose my question is not so much a practical problem to solve but rather an explanation for the behavior, given that I assume it isn't an unintentional OS bug that causes this.
    – rb612
    Jul 17, 2020 at 7:20
  • Sounds like you witnessed the kernel staying functional, the UI staying functional and despite the operator ignoring the low space warnings, could delete user space files without the system crashing.. You’re correct about the “practical” litmus test, I was trying to evaluate if this was a real question.
    – bmike
    Jul 17, 2020 at 7:22

1 Answer 1


This is a design decision that is made to handle situations where operators of the device choose to ignore low storage space warnings or are not present to see them and react appropriately.

From your comments, you described that the system works well enough to let you inspect storage, choose to delete apps and data and continue working - that’s the case in my experience. The system sacrifices the ability to launch new apps, install updates and do other non-critical functions when storage space is close to empty.

In most cases, the system is able to send a sequence of disk space “warning” and disk space “critical” signals to the OS, the first party apps and third party apps requesting they purge any cached storage, but in the end, you can overload the filesystem and this is the last ditch attempt to get the device in the hands of someone that will realize that files or apps need to be deleted to resume normal operations.

For the nerds that program, there are entire API and processes around this to let an app know how much space is available for opportunistic storage and critical storage:

One of the better articles on this is:

In the end, it’s up to the programmer of an app if they want to check and let you know they may stop working or if they want to be simple in design and let you figure out if your device is full in other manners. Neither decisions is completely right or completely wrong. The OS will nag you about low storage, so most apps let that handle education these days and they just postpone large downloads when things get tight.

  • This is an excellent answer, thank you! So to follow up then, "this is the last ditch attempt to get the device in the hands of someone that will realize that files or apps need to be deleted..." regarding the crashes of user-space processes on startup, from your knowledge is it the kernel killing the process as this last-ditch effort, or is it an unhandled exception caused by, say, a failed disk write by the user-space process causing these apps to crash? Or is it too hard to tell from this information? I know the kernel does this process killing to free RAM when low but not sure about disk.
    – rb612
    Jul 17, 2020 at 7:42
  • 1
    Oh @rb612 - the kernel is 100% in control of scheduling. Nothing runs on iOS until it’s asked to due to sand boxing, app review, strict API on background processing, and several other factors. Think how many active devices are in service - this OS is battle tested, battle hardened, multiple fail safes are designed in to it. When I say last ditch, the OS is done pestering you with another pop up explaining space is low. It’s still logging, running, doing it’s duty all the time the apps won’t launch and are exiting / terminating as they try in vain to write more data.
    – bmike
    Jul 17, 2020 at 7:48
  • That makes a lot of sense then — thanks again. For the sake of completeness for any programmers, some digging shows that the process itself will receive a NSFileWriteOutOfSpaceError and it's then up to the application developer on how to proceed from there, however it seems based on this anecdotal experiment then that many third-party apps don't handle this explicitly or likely crash due to some consequence of this error.
    – rb612
    Jul 17, 2020 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .