[Feedback wanted] Removing the run Metro hook from Xcode

[huntie]

What

Today, we have an inconsistency between Android and iOS in terms of whether the IDE (not CLI) auto-launches a terminal with Metro when an app is built (launchPackager.command).

I am proposing removing this Xcode hook, to align between platforms and reduce the surface area of app startup scenarios we support.

The behaviour would remain when running react-native android or react-native ios (React Native CLI) (potentially a separate future discussion). (Note: The CLI ships with its own launchPackager.command 😅)

Pointers:

• rn-tester/RNTesterPods.xcodeproj
• react-native/template/ios/HelloWorld.xcodeproj

Assumptions

This Xcode build phase differs from the flow in Android Studio, and in my view, conceptually mixes concerns with what building a native app from the IDE should do.

I believe these are distinct steps which developers understand:

• Starting the React Native dev server (react-native start): A process that serves JavaScript code at development time.
  • Supports multiple devices simultaneously and always serves latest JS filesystem state.
• Building a native app from an IDE: Running "Build" in an IDE initiates and outputs a native build to a device/simulator/emulator.
  • May be rebuilt frequently following native code edits.
  • The IDE's job starts and ends with this — doing the step above is an out-of-scope dependency.

For now, the assumption would remain that the CLI entry points (react native, react native ios) offer a managed workflow where we do coordinate these.

Distinct benefits

• Consistent expectations between platforms.
• Removing this entry point to the dev server removes a non-obvious extra flow that the React Native team needs to support (example discrepancy catch).
• Auto-launching Metro often ends up in the background and is a source of confusion (from @robhogan):
  • Metro's startup or build output can easily be missed, which leads to a poor experience if the user first sees a redbox.
  • Because Xcode starts but doesn't stop Metro (and only starts it if the port is open), switching between projects/apps can often mean the wrong Metro instance ends up serving your new iOS build, which is again confusing.
  • The choice of terminal, and the inheritance of Xcode's env vars, can play havoc with user preferences, in particular active (nvm) Node version.

cc @cipolleschi @cortinico @motiz88 @Saadnajmi @kelset

[cipolleschi]

The proposal is good for me. Consider that this change will update the Xcodeproj, and we don't have much control over the users projects. We have to be very clear and very loud about this change as our users can be now used to a workflow on iOS that launches Metro for them.

In general, I'm always very happy to remove code in user space. Let's make sure that we communicate the change well! 😉

[tido64]

Yes, please! This was one of the first things we removed from our internal example apps, and stayed that way when we created react-native-test-app. It was often the source of confusion and issues for all the reasons Rob pointed out.

[Saadnajmi]

",The IDE's job starts and ends with this — doing the step above is an out-of-scope dependency."

You found a great way to summarize my thoughts on it 😁, thank you!

[cortinico]

I am proposing removing this Xcode hook, to align between platforms and reduce the surface area of app startup scenarios we support.

+1 for as this will re-align Android & iOS tooling support

[huntie]

Thanks all! Shipped in facebook/react-native@dc68457.

[tido64]

Do we need to make the equivalent changes in the CLI? Iirc, run-android starts the dev server to compensate but run-ios doesn't. cc @thymikee

[thymikee]

I think we should

[szymonrybczak]

PR: react-native-community/cli#2021