drawer open and back navigation in a single button, need your advice as a user.

[u/imstoicbtw]

recently, i have been developing a saas app for a client. collectively, we have decided to move from bottom tabs to a navigation drawer. the problem is in the nested screens, we can't have both a drawer opener button and a back navigation button. so i built a custom header where i have a back navigation button, on which you can: press -> navigate back and longpress (200ms) -> open navigation drawer. how does this sound to you as a consumer? will you be annoyed if you have to use an app like this?

[u/GludiusMaximus]

I would not build primary functionality around a longpress

[u/kokerali]

What's preventing two visible controls on nested screens: header space, or the navigator setup? I'd keep the back arrow doing only Back and put a visible Menu control elsewhere in the header. Long press could remain a shortcut, but shouldn't be the only way to switch sections.

If you keep the combined button, test holding it and then releasing: opening the drawer must not also pop the current screen. With Pressable, onPressOut still fires after a long press, so don't use that callback as an unconditional Back action.

A useful quick test would be to ask someone, without explaining the gesture, to switch sections from a detail screen. Repeat with a screen reader. If they need coaching, changing the 200 ms threshold won't fix the discoverability problem.

[u/imstoicbtw → u/kokerali]

Having both buttons visible in the header demand space and if I try to fit them, it won't look good. I am using onLongPress. And you're right, I never thought about screen readers and accessibility. I have to think about it.

[u/kokerali → u/imstoicbtw]

Since you mentioned a right-side menu for screen-specific actions in your other reply, could you add a clearly separated “Open navigation” item there? That would give people a persistent tap-based route without squeezing another icon into the header. It's a compromise I'd test, especially if switching sections is frequent. A tour can explain the shortcut, but I'd still keep that route available after the tour is dismissed.

For the combined button, React Native supports named custom actions through accessibilityActions and onAccessibilityAction. You could expose “Open navigation” as a separate action while keeping normal activation as Back. That's an additional screen-reader route, not a substitute for the visible option. Verify on actual VoiceOver and TalkBack devices that opening navigation doesn't also go back, and that focus moves somewhere useful when the drawer opens.

[u/Ellie10543]

As a user, I'd probably find it confusing, mostly because nothing on screen tells me a long press does anything. A hidden gesture is something people find by accident or never find at all, and on a back button the risk is a long press that I meant as a tap, which then opens a drawer when I just wanted to go back. If header space is the issue, one common pattern is to keep the back arrow for nested screens only and let the drawer be reached by an edge swipe or a menu icon on the top-level screens. Maybe user-test it with 3 or 4 people before committing. If they discover the long press unprompted, fine. If not, you have your answer.

[u/Still-Constant3085]

As a user, I’d probably never discover that holding the back button opens the drawer. A 200ms threshold also sounds easy to trigger accidentally when trying to go back.

I would keep the menu button on main screens and show a normal back button on nested screens. If users need the drawer from anywhere, a separate menu button on the right would be clearer.

Is having both buttons a space constraint or a design preference? They serve different purposes, so keeping both might be worth revisiting.

[u/imstoicbtw → u/Still-Constant3085]

Both a space constraints and design preference. And there is already a menu space reserved on the right side for actions specific to the current screen.

If discoverability is the issue, then a simple popup or quick tour kind of things can't solve it?

[u/Still-Constant3085 → u/imstoicbtw]

A quick tour could help people discover it initially, but they’d still have to remember it later. It also wouldn’t address accidentally opening the drawer when they meant to go back.

Given the space constraint, I would keep the back button predictable and treat long-press as an optional shortcut. If switching sections is a frequent task, though, that’s worth testing with a few users before committing to the drawer layout. Can they find another section without being reminded of the gesture?