[Feedback wanted] Removing "run on iOS/Android" key handlers from the CLI dev server

[huntie]

What

Remove the "run ion iOS" and "run on Android" options from npx react-native start.

Motivation

TLDR: The existing android/ios commands provide a convenience mechanism to trigger start (in a new terminal), but let's remove the hooks for doing this the other way round. Frameworks are better placed to make decisions around orchestrating these parts.

Quality — incomplete and buggy CLI output

Our dev server should only be concerned with the first party actions of serving JS bundles and supporting debugging (all key commands except Android/iOS). These actions don't create distracting noise for the user and complete very quickly.

Conversely, for "run ion iOS", "run on Android":

• These commands generate a lot of CLI output, competing with Metro's logs.
• This output is streamed directly to the console, and not via Metro's buffered terminal API.
• The current way we wire up the iOS and Android builds omits all stderr output — meaning a failed native build will output nothing, and just hang as the dev server continues to listen!

Maintenance and lack of feature fit in core

• Supporting these actions, which call outer npx react-native commands, keeps a strong dependency on @react-native-community/cli-plugin-android and @react-native-community/cli-plugin-ios.
• These actions are untested in our repo/release test plans.
• For the case of brownfield apps, I'm not convinced that these commands will always align with the containing project build setup.

Alternatives

None needed.

• For Community CLI projects, these already offer the react-native android|ios commands, which will open a terminal window for react-native start (the same dev server) if needed. Post Frameworks, we don't need the convenience of doing this both ways round.

[tjzel]

Yes please, I sometimes accidentally press 'i' or 'a' and then get infuriated 😆

[coolsoftwaretyler]

I only use those commands every now and then. I don't think this would negatively impact my day-to-day development experience with React Native.

[huntie]

Thanks all! Intending to ship in facebook/react-native#46781 (on main, will land in React Native 0.77).

[simoneantonicchio]

I'm totally agree!

[shtefanilie]

Same as @tjzel, happens to me way to often.

[Rexogamer]

not opposed to this change (alongside the above, it also seems less confusing to only have one entry point), but I do want to note that, at least for me, yarn android doesn't seem to start Metro? I'm using Ubuntu 24.04/GNOME Terminal if it matters - I swear it did work (at least occasionally) on Windows but I'm not certain about that

[huntie]

@Rexogamer Interesting, I'll check this. Will also check our docs, which should state that users run yarn start themselves anyway — the auto-launch behaviour is intended to be a convenience.

[coolsoftwaretyler]

I think I noticed this same thing. I caught it when doing some work out-of-tree in React Native Mac OS, but also had the experience where it worked one day and then all of a sudden didn't (I maybe updated a version somewhere but I can't remember). I filed it over here: microsoft/react-native-macos#2208, but perhaps this is actually upstream.

[szymonrybczak]

@Rexogamer @coolsoftwaretyler could you please create a proper issue with all necessary informations, I'm more than happy to help you fix your issue 🙏

https://github.com/react-native-community/cli/issues/new/choose

[9764319764319764]

ذ