feat: display dev menu as a sheet when invoked from Metro (1/2) #2750
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Saadnajmi
changed the title
amgleitman
approved these changes
Nov 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
You can launch the dev menu 3 ways:
This PR is focused on fixing issues with (3).
When the dev menu was presented from metro, we didn't have a window or mouse location to key off of, so a context menu would present at coordinates (0,0), AKA, the bottom left of your screen on macOS. This isn't very discoverable or useful. To match other platforms, I think it would be better to make the dev menu an NSAlert, presented on top of the apps window.
Let's also preserve the right click context menu for now, since that is still useful and muscle memory for most macOS devs. Let's also use some newer NSMenu APIs to set the title / subtitle while we're here.
Test Plan:
Screen.Recording.2025-11-05.at.1.12.02.PM.mov
Notes
We don't want to support (1) because we don't want to register hotkeys on the window, a window may have multiple instances of RN running. We could register it on the root view... but on macOS, keyboard focus is rarely in the root view (it's usually just on the window or application) so this isn't very discoverable. I'll elect to skip implementing this flow for now.