Disable redboxing on release builds

[HeyImChris]

Please select one of the following

• I am removing an existing difference between facebook/react-native and microsoft/react-native-macos 👍
• I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos 👍
• I am making a fix / change for the macOS implementation of react-native
• I am making a change required for Microsoft usage of react-native

Summary

In the react-native-macos fork, we set the debugging macro, RCT_DEV, to true for both debug and release builds. This differs from facebook's upstream, but is something we do so our white glove partners can debug their release experiences.

13 months ago a PR went into upstream adding ability for devs to toggle redboxing at runtime via RCTRedBoxSetEnabled. This worked for upstream because with RCT_DEV always being false for them, this defaulted to OFF on all their release builds. In our case, we need to explicitly set it to be off when not built in DEBUG mode to counter the fact that RCT_DEV has to always be true for us.

In order to properly test this, I added the proper build target to the Release scheme. Now anyone can run debug or release flavors of RNTester instead of just debug.

Also thanks to @amgleitman for helping track down the problem!

Changelog

[macOS/iOS] [Bug] - Disable release redboxing

Test Plan

I made a trivial spelling mistake in a module name in our JS test app. Then launched RNTester in debug with this fix and we Redbox. Then I launched RNTester in release and we don't Redbox- the view just fails to load.

Microsoft Reviewers: Open in CodeFlow

[alloy]

I’m not quite sure I understand the approach to the desired result. If I understand it correctly, for debugging purposes we set RCT_DEV to YES in release builds, but we do not want redboxes to show up; correct?

If so, isn’t the addition of this redBoxEnabled variable exactly meant to handle that purpose selectively independent of RCT_DEV? I.e. shouldn’t Office code be setting that to NO in release builds without the need to introduce a forked change in RN macOS itself?

[HeyImChris]

I’m not quite sure I understand the approach to the desired result. If I understand it correctly, for debugging purposes we set RCT_DEV to YES in release builds, but we do not want redboxes to show up; correct?

If so, isn’t the addition of this redBoxEnabled variable exactly meant to handle that purpose selectively independent of RCT_DEV? I.e. shouldn’t Office code be setting that to NO in release builds without the need to introduce a forked change in RN macOS itself?

That's a good point and I think it's fair to not hardcode this to be off here, but at the minimum I think it should default to being off which is what FB does with their RCT_DEV macro. Regarding not having a diff, we already have a diff from upstream with our RCT_DEV macro so this is fallout from that.

I'm not comfortable leaving this on and relying on SDX's to know to turn off redboxing but maybe we can add a preprocessor macro that can get set at build time in the CI? Just another potential solution there but again, that'd take a diff from FB to add a new macro

[harrieshin]

I’m not quite sure I understand the approach to the desired result. If I understand it correctly, for debugging purposes we set RCT_DEV to YES in release builds, but we do not want redboxes to show up; correct?
If so, isn’t the addition of this redBoxEnabled variable exactly meant to handle that purpose selectively independent of RCT_DEV? I.e. shouldn’t Office code be setting that to NO in release builds without the need to introduce a forked change in RN macOS itself?

That's a good point and I think it's fair to not hardcode this to be off here, but at the minimum I think it should default to being off which is what FB does with their RCT_DEV macro. Regarding not having a diff, we already have a diff from upstream with our RCT_DEV macro so this is fallout from that.

I'm not comfortable leaving this on and relying on SDX's to know to turn off redboxing but maybe we can add a preprocessor macro that can get set at build time in the CI? Just another potential solution there but again, that'd take a diff from FB to add a new macro

are we letting our client teams to debug any type of ship builds? not just stage = 0?

[HeyImChris]

Checking this in- only failure is a known android CI failure that I just sent a fix out for. This is unrelated and only affects Apple platforms.