I’ve somewhat researched iMessage handling on iOS for a jailbreak tweak called TypeStatus, and I find this bug odd. In iOS 7, SpringBoard was restricted at the

I’ve somewhat researched iMessage handling on iOS for a jailbreak tweak called TypeStatus, and I find this bug odd. In iOS 7, SpringBoard was restricted at the sandbox (kernel) level from any access to the Messages database. I had to adapt my code to instead run inside imagent, which is responsible for keeping a push socket open with iMessage among other Messages housekeeping things (this also exists on macOS). There was a trend since iOS 6 to move backend/non-UI responsibilities away from SpringBoard. But in iOS 11 or 12 or so, more responsibilities started creeping back into SpringBoard. Maybe because of performance or memory consumption concerns, maybe it’s laziness avoiding having to set up a new daemon with appropriate dependencies and sandbox profile when the code can easily be plopped into SpringBoard, it’s not clear. As Natalie says in the report, on macOS this bug only causes DoS on a daemon. Worst case, iMessage stops working and your battery dies quicker. Being totally locked out of the device because SpringBoard is “boot looping” due to an existing fail-safe being excluded from the design seems awful. On the subject, my Android phone stopped even presenting a keyboard on the lock screen or anywhere else, because the default keyboard is Gboard, and Gboard relies on Play Services, which was crashing inside Gboard. Like this iOS bug, the only known solution is to wipe the device and start over. At least I was still able to get into the device by connecting a USB keyboard. Sucks to know most would have no idea how to diagnose such an issue though, needlessly wiping their photos and all.