We’re revisiting how the “On app restart” vault timeout option works on mobile and wanted to get some community input before finalizing the behavior.
The core issue is that iOS and Android don’t distinguish between an app being manually closed by the user and the OS terminating it in the background to free up memory. From Bitwarden’s perspective, both look the same, which means both currently trigger a unlock / login prompt when the app reopens.
That behavior is naturally causing confusion. If the OS quietly killed the app while it was sitting in your recent apps tray, you probably didn’t intend to lock your vault.
We’re wondering:
Do you use this setting at all? If so, what made you choose it over a time-based timeout?
And what did you expect it to do when you turned it on?
We’re also considering whether this option should exist on mobile at all in its current form, and whether a straightforward time-based timeout would be less confusing in practice.
In general, If you’ve ever been unexpectedly locked out, or felt like the app wasn’t locking when you expected it to, we’d really like to hear about it.
Do you use the “On app restart” vault timeout on mobile?
I’m already confused by this: what do you consider “manually closing” here? – On my Android 15 device, when I leave the app then it stays active in the background. So, by manually closing you mean active cancellation of that being-active-in-the-background of the mobile app?
I just changed to the session timeout setting “On app restart” with the timeout action “Lock”. Since I use biometrics, I can unlock the BW app with biometrics – also with “On app restart” and after I actively terminate the app in the background. I don’t see a master password prompt when I reopen the app. (of course I could change to master password unlock instead of biometric unlock…)
Or do you just mean (here) “the app needs to be unlocked again” (with whichever unlock method was set up before)?
I’m not sure if I’m in the majority or minority here… but on mobile devices, I’m obviously more careful than with my PC. I use the “1 minute” option for session timeout on Android. I’m not sure if I would use “On app restart” at all… spontaneous thought: I think I would only use it, when it would mean “as soon as I leave the app, it shall lock”… but then – that is already possible with “Immediately”.
BTW, I just realized “On app start” is an inaccurate expression. As it doesn’t lock “on app start”, but on “termination”. It better would be called “On app termination/cancellation” or something similar. (–> what I really can do “on app start” is to unlock it!)
… Sorry, that I can’t answer the rest of your questions…
… yeah, because I would tend to question it’s existence now as well… I think I can only add, if choosing “On app termination/cancellation” () could lead to an unlocked app for hours when either I forget to “manually terminate” it or Android doesn’t terminate it in the background, then I personally would never use “On app termination/cancellation”. (e.g./because: if my phone got stolen in an unlocked state – and I opened BW 5 hours ago – then my vault would still be unlocked, therefore now accessible without any other security mechanisms)
Yes, exactly. “Manually closing” means swiping the app away in the recents/multitasking tray, which tells the OS you’re actively terminating it. Just navigating away and leaving it running in the background isn’t “closing” in that sense.
Exactly, sorry for the confusing wording. Edited for clarity.
That makes total sense, and is exactly why we question the need for “on app restart”.
… yeah, and on the other hand, there is the option “Never”… so, I guess, the question is indeed: what exactly lies between “immediately” and “never” on the mobile apps – if anything meaningful at all.
It makes sense for Desktop and for Browser restart, and I assume historically we just wanted to keep all clients aligned. But in the mobile context it just doesn’t seem very logical.
On iOS mobile app it seems if you have any timed timeout (including custom) if you force close the app you’ll be prompted to enter password/biometric authentication. So by default isn’t that already doing what on app restart would?
People who set this up on mobile likely expect not to be prompted for authentication again unless they force‑close the app, reboot, or log out — but that’s not what will happen: when the OS kills the app silently to reclaim memory, the user will be prompted for authentication again.
Essential questions for this feature are: 1) Is anyone using it in the current form? 2) Does the authentication behavior match their expectations? 3) In the current form, is this useful? Why isn’t the user using more predictable locking/authentication behavior?
I don’t use the mobile apps, so my question may be ill-informed, but wouldn’t the same problem occur for every timeout setting (except “immediate”)? If a user has a 1-hour timeout, and if the OS terminates the app within that 1 hour, will the user not be confused by this (if they attempt to re-open the app before the 1-hour interval has expired, but after the app has been terminated by the OS)?
I have a tangential question: What is the point of locking the vault on mobile?
As far as i know, mobile apps are pretty locked and cannot affect one another/read private memory/resources/etc.
So, unlike desktop/browser, even if the vault is left ‘always unlocked’ on mobile, i don’t think that’s a big concern.
What are your opinions here?
it may make sense to split this question into its own topic, but maybe it’s very closely related to the current topic that it makes sense to keep it here. i’m undecided
I usually like to keep my vault set to never, considering I have strong password/timeout on the phone. However, and I guess due to some limitations, I cannot paste Totp codes after autofill (I guess it never copies). It becomes tedious either having to long press , select auto fill, search for item, press item, minimize keyboard, press copy Totp, minimize, go back to browser, paste.
Defense in depth. You might have your phone unlocked when it is ripped from your hands by a thief, but if not actively using the vault, it would be more likely to be locked.
Phones enrolled in corporate mobile device management can often times be unlocked by the company.
) could lead to an unlocked app for hours when either I forget to “manually terminate” it or Android doesn’t terminate it in the background, then I personally would never use “On app termination/cancellation”. (e.g./because: if my phone got stolen in an unlocked state – and I opened BW 5 hours ago – then my vault would still be unlocked, therefore now accessible without any other security mechanisms)