Is this necessary as it's not a critical action but I see it in a few apps. If so, what are the reasons behind it?

4 Answers 4


Yes! You should always confirm sign-out in mobile apps.

Here's why:

  1. Mobile is a personal device: When we mean personal - really personal.. others can have limited to no access to someone's mobile.

  2. Account Safety: In order to keep user accounts safe, users generally opt for strong passwords and when you have more than 10 signed-in apps it becomes difficult to remember all passwords.

  3. Security: If a user is signed-out by mistake, signing-in again might involve multiple steps (OTP, email confirmation etc) to get into the app again particularly when you don't remember your password.

  4. Emergency of use: Mostly we use mobile apps when we need them (excluding games to some extent) such as; to perform a money transaction. Imagine a situation - you're buying something and at the same time you have to board a plane but you accidentally signed-out of Apple Pay and have to go through the tiring process of authentication again.

This happened to me recently -

I booked UBER with an intention of using PAYTM as payment method. I opened the app and because of slow internet connection in that area I tapped on the profile icon multiple times - suddenly PAYTM signed me out and asked to sign-in again. I didn't know the password of it - I chose forgot password option - PAYTM sent me an email - it took a lot of time for the email to arrive in my inbox (because of the slow internet) - then there was OTP too. Finally I gave up and paid hard cash.


Although the action can be "undone" (signing in again), sign in is not the most convenient process as you have to enter the email and password (considering you find out the correct password).

I guess in Mobile it is easy to tap somewhere by accident, the screen is smaller than a desktop and a tap can happen accidentally.

So combine the above arguments and you have a good reason to include a confirmation dialog for the sign out. I guess if the sign in is done easily through a Social Network or similar you might consider not concluding a confirmation.


It's to make the user "think twice" or to prevent mistake since sign-outs increase churn rate.

More information about confirmation messages can be seen here: http://www.uxdesignedge.com/2010/06/are-you-sure-how-to-write-effective-confirmations/

According to that article, the confirmation for sign-out can work on these scenarios:

  1. Prevent the error
  2. Provide feedback
  3. Provide undo
  4. Make results easy to change

You should really question why you are providing a sign-out feature to the User. Most of the time, the justifications are better served by better mechanisms.

Part of the consideration should cover:

A) Push-notifications and other authenticated experiences that are very beneficial to maintain a relationship to the app's business/org/purpose and the User. Logout done right should see push-notifications cease (room for advancements here, e.g. moving the device onto an unauthenticated set of tokens to continue "public messages" type push-notifications), so it typically hurts the business. If you provide logout so Users can take a break from your spam, UX is not important to you.

B) The unauthenticated state relies on surrounding features such as Forgotten Password, if they suck or are broken then you are forcing the User into a bad experience. They probably suck BTW. All of those interactions are points where your loser can lose interest in your product/business and abandon the whole thing - why invite that?

C) The cost to both the User and the business in terms of data usage (radio usage, time spent, cloud services costs) to re-download content upon re-authentication.

Typical (half-baked) justifications (or pain points) for providing a sign-out feature:

  1. Because a User might lose their device.
  2. Because a User might need to sell their device.
  3. Because a User needs to share their device with someone.
  4. Because IT Support need to be able to say "Did you try turning it off and on again?".
  5. Because Bank XYZ's app has a logout feature.
  6. Because there is no app in existence that doesn't provide a sign-out feature!
  7. Need it to be compliant.
  8. ?? (please comment if you think other popular justifications exist)

Better mechanisms to mitigate the risks associated with the above:

  1. More than your app is at stake here, much more. If the OS provides remote tracking, remote wiping, or similar features those are the features to leverage. Logout in this scenario is an attempt for the user to pre-empt the theft or loss of their device - why not also help them pre-empt their device catching fire and providing them a fire-extinguisher to carry around too??

  2. Factory reset. If the users doesn't factory reset the device before selling it, they just shared it with a stranger forever and should look at (1). User education is the right thing to do to mitigate against the risks of this scenario.

  3. OK. That lacks a ton of detail. Are they sharing with someone who is overseas and the sharing is going to be for years? Is that the scenario we should prepare for here? That would be better treated as a sold device. Practically, sharing may be at worst handing your device to a stranger who needs to make a phone call, if you don't monitor that person closely while that is happening, well you probably need to refer to (1) because they ran away with your phone. Guest accounts, multi-accounts, and app-pinning in combination with screen lock on Android are better solutions for this. The best mitigation here is User education, similar to mitigating against Phishing attacks.

  4. If you rely on a User self-unauthenticating to deal with problems/bugs, put more focus on architecting and implementing quality software before wasting time on UX forums. This is similar to (1), preparing for potential future situations with the wrong, archaic controls.

  5. Bank XYZ's app is probably vulnerable to something, are you looking for parity there too? Bank's tend to be very slow moving in the uptake of new technology, partly due to the cost of security team engagements, it turns out that most banks weren't pioneers in the mobile app space and their security team will insist that the mobile app has a logout feature because the website has a logout feature. Also there is a much greater risk, I imagine, compared to your app/system and banks typically not only provide logout - they forcibly log you out when the short-lived session ends - they are timeboxing any open connection into your account to mitigate against the high risks (and mostly to save themselves losing money not the user).

  6. E.g. both the Dialer app and Google Play app do not provide a means to sign-out. Google Design advocates even discussed this topic, questioned whether sign-out needs to always exist (unfortunately I can't cite that, I recall it was Nick Butcher).

  7. Your hands may be tied, but I can assure you that the compliance mandate is ill-thought-out when it comes to mobile. PCI-DSS is, OWASP Top 10 upon which PCI-DSS relies is, and OWASP Mobile Top 10 is 10 years overdue. While we're at it, NN Group is extremely late to the game too.

When an option comes with many drawbacks and there are better options available, why spend time polishing the bad option? Sometimes by stepping back and rethinking the approach one can get out of a "local maximum" and go on to find the actual best solution.

Direct answer to the OP's Question: No. You ideally never have to. Don't make the sign-out button a CTA, make it the lowest priority action in the app, hidden behind menus in a way where one would have to intentionally seek it out to action it.

  • I downvoted this for a couple of reasons: - The info about push notifications isn't accurate, they are based on app permissions not the authentication state - The point about banks and vulnerability is not accurate. Regulatory or legislative reasons are based on the cost of loss. The primary driver shouldn't always be smoothest UX and that's ok for some industry - Your point about logging out relying on forgotten passwords which "suck" is also inaccurate. Many apps will/do provide a biometric authentication process which is no mort obstructive that unlocking your phone in the first place. Dec 8, 2020 at 20:18
  • Please elaborate as to how passing a User over to a (typically) web app flow that typically sucks (if I try to login, it fails, and then I go to forgot password it typically makes me reenter the username and that "sucks") is good or better UX? Web apps within a native flow, just wow. Please tell me how push-notifications are based on permissions and have nothing to do with authenticated state (consider that the pushed payload contains PII)? Re: Banks and vulnerability, my point is that blindly copying what banks do isn't a great thing to do.
    – straya
    Dec 9, 2020 at 2:45
  • My overall point here is that there are a lot of assumptions within your answer that don't provide a balanced view suitable for a generic answer. Perhaps if you stated the assumptions in a way which supports a balanced response it would be better. E.g. "If you user logs out, you should consider the friction of the login process and issues arising from lost credentials" - If you're making blanket statements about your opinions on flows that "suck" without citing examples or evidence to support that view the answer will likely be perceived lower quality because it's opinion based. Dec 9, 2020 at 13:36
  • What can I say? If you believe that a web flow hosted within a mobile app doesn't "suck" and that I need to provide citation to convince you, I am not convinced I can convince you.
    – straya
    Jun 8, 2021 at 5:50
  • My point here is that at no point has the OP talked about the assumptions you're making in your answer. No one has mentioned a "web flow hosted within a mobile app" except you. It seems your perhaps citing something you've experienced personally, which is not relevant to the question unless you can provide the type of flow your might avoid and why, saying something "sucks" isn't an objective evaluation. Jun 8, 2021 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.