In many Apple support threads online where people encounter strange issues with their devices, a restart often fixes the issue. Great, right? I think not.
We shouldn't have to restart our Apple devices to make them work.
Sure, Apple silicon processors are extremely fast these days, making restarts faster than ever. But the fact of the matter remains that we shouldn't need to interrupt our workflows to restart our devices.
Here is an example of this that I encounter often: AirDrop on the Mac. Sometimes it will fail to work; clicking on the icon for my iPhone or iPad will do nothing. Sometimes this can be fixed by running "killall sharingd" in Terminal; however, most of the time, I need to restart the Mac for it to work again. This is on an M1 MacBook Air, by the way. (Now, I'm not saying that we need to tell users to run a Terminal command; this is just an illustrative example.)
From what I've seen -- and this is my opinion -- most of the strange issues that people have are the result of the system entering a "quasi-working" indeterminate state that Apple did not expect to occur and as such does not provide a way for the system to recover from.
If Apple is focusing on bug fixes and performance improvements for their next-generation operating systems as the rumors say, then they need to focus on identifying edge-case/indeterminate situations and providing a way for the system to recover from them, automatically. And they need to make sure that the system can only operate in determinate, well-defined conditions.
How can this be applied to the example above? On Apple platforms, launchd is responsible for launching daemons and background tasks, and restarting these processes if they crash. However, to my knowledge, there is not a way for launchd to detect an unresponsive process and automatically restart it. In the AirDrop example above, it's my belief that the root cause is sharingd becoming unresponsive or otherwise unable to receive user input. A useful fix would be for launchd to send a "heartbeat" signal to the processes and restart them transparently if they don't respond within a certain time frame. (This approach wouldn't work for user-facing applications, but it would certainly work for background services and daemons that don't put windows on screen.)
I believe a similar approach is used in embedded systems where humans might not be physically near the system to restart it at will. If Apple truly wants to make their computers like appliances, then they should build the software with that philosophy in mind; human intervention shouldn't be required to get out of indeterminate states.
Of course, this would lead to a far better user experience, which is the point of me writing all this. Things will "just work."
I would be interested to hear your thoughts on this.
EDIT: original post was written in a moment of frustration. Please read the thread before replying.
We shouldn't have to restart our Apple devices to make them work.
Sure, Apple silicon processors are extremely fast these days, making restarts faster than ever. But the fact of the matter remains that we shouldn't need to interrupt our workflows to restart our devices.
Here is an example of this that I encounter often: AirDrop on the Mac. Sometimes it will fail to work; clicking on the icon for my iPhone or iPad will do nothing. Sometimes this can be fixed by running "killall sharingd" in Terminal; however, most of the time, I need to restart the Mac for it to work again. This is on an M1 MacBook Air, by the way. (Now, I'm not saying that we need to tell users to run a Terminal command; this is just an illustrative example.)
From what I've seen -- and this is my opinion -- most of the strange issues that people have are the result of the system entering a "quasi-working" indeterminate state that Apple did not expect to occur and as such does not provide a way for the system to recover from.
If Apple is focusing on bug fixes and performance improvements for their next-generation operating systems as the rumors say, then they need to focus on identifying edge-case/indeterminate situations and providing a way for the system to recover from them, automatically. And they need to make sure that the system can only operate in determinate, well-defined conditions.
How can this be applied to the example above? On Apple platforms, launchd is responsible for launching daemons and background tasks, and restarting these processes if they crash. However, to my knowledge, there is not a way for launchd to detect an unresponsive process and automatically restart it. In the AirDrop example above, it's my belief that the root cause is sharingd becoming unresponsive or otherwise unable to receive user input. A useful fix would be for launchd to send a "heartbeat" signal to the processes and restart them transparently if they don't respond within a certain time frame. (This approach wouldn't work for user-facing applications, but it would certainly work for background services and daemons that don't put windows on screen.)
I believe a similar approach is used in embedded systems where humans might not be physically near the system to restart it at will. If Apple truly wants to make their computers like appliances, then they should build the software with that philosophy in mind; human intervention shouldn't be required to get out of indeterminate states.
Of course, this would lead to a far better user experience, which is the point of me writing all this. Things will "just work."
I would be interested to hear your thoughts on this.
EDIT: original post was written in a moment of frustration. Please read the thread before replying.
Last edited:
