New Apple security feature reboots iPhones after 3 days, researchers confirm
Apple’s new “inactivity reboot” in iOS 18 automatically restarts iPhones that haven’t been unlocked for 72 hours, putting devices back into a more secure, pre-unlock state that complicates data extraction by thieves and law enforcement alike. Commenters broadly welcome the security benefits, noting parallels to GrapheneOS and payment terminal requirements, but criticize Apple for making the three-day window fixed rather than user-configurable and for limiting automation options around reboots. The feature also raises usability questions for people who rarely unlock their phones and highlights Apple’s broader tradeoffs between strong defaults, user control, and ecosystem lock-in.
How they know it’s an intentional feature
- Logs explicitly show an “inactivity reboot” entry, and researchers mention reverse engineering, so commenters reject the “maybe it’s a memory leak” idea.
- Security Research Devices show verbose boot logs, but that level of output isn’t expected on normal devices.
What the feature does and when it triggers
- iOS 18 reboots an iPhone if it hasn’t been successfully unlocked for ~72 hours.
- Several commenters note this puts the device into a more secure “before first unlock” (BFU) state where user data is still encrypted.
- Some point out it only affects phones unused for days, so most users may never notice.
Configurability, UX, and threat models
- Many want the timeout configurable, e.g. 8–24 hours, or even 30 minutes; others argue 72 hours is a cautious first rollout to avoid user complaints.
- Several suggest tying shorter timeouts to Lockdown Mode, MDM, or Apple Configurator rather than a visible consumer setting.
- Some worry about missed calls/notifications during reboots, others already accept PIN-only workflows due to legal or police threats and would tolerate frequent reboots.
- There’s debate over how usable the phone is post‑reboot before unlock: some say no network/notifications, others report their Android phones are usable.
Shortcuts and automation attempts
- Users try to emulate shorter timeouts via Shortcuts scheduled reboots, but iOS generally prompts for confirmation, defeating unattended automation.
- Some report “Run immediately” works without prompts; others say it doesn’t, possibly device/iOS-version dependent. Overall behavior is described as buggy and limited.
Comparisons to GrapheneOS and Android
- GrapheneOS already has a configurable “auto-reboot after inactivity” (default ~18 hours) and is praised for broader security features.
- Samsung and Pixel devices offer scheduled reboots, but commenters note those are often for performance, and on some devices auto‑reboot appears less “full” (notifications work without unlock).
- Some see Apple’s move as catching up to practices in hardened OSes and PCI‑regulated payment terminals, especially as iPhones increasingly act as POS devices.
Security philosophy and tradeoffs
- Reboots are framed as defense‑in‑depth: clearing in‑memory exploits like spyware.
- Others stress UX and legal realities: stronger technical protections mainly help where due process works; they don’t stop coercive attacks.