[iOS] Support launchOptions in bridgeless mode

[zhongwuzw]

Summary:

Support launchOptions in bridgeless mode

Changelog:

[IOS] [FIXED] - Support launchOptions in bridgeless mode

Test Plan:

useEffect(() => {
    const processInitialURL = async () => {
      const url = await Linking.getInitialURL();
      if (url !== null) {
        console.log(`Initial url is: ${url}`);
      }
    };

    processInitialURL();
  }, []);

[javache]

Modules are always scoped to a single bridge. Accessing the singleton here is incorrect.

If bridge is nil, it means this module is being destroyed and the module should be torn down.

[zhongwuzw]

emm,in the bridgeless mode, bridge ivar is always nil because it is a turbo module.

[javache]

Hmm, isn't this part of bridgeless compat? @cipolleschi ?

Accessing the singleton here is an anti-pattern and should be avoided.

[cipolleschi]

I agree with @javache that we should not access the [RCTBridge currentBridge].

In bridgeless mode, self.bridge would be nil, and the currentBridge will return the bridgeProxy that behaves like a bridge. So, this technically works, but it was intended to be used only for backward compatibility.

However, I'd rather fix the issue properly, looking if we can find a way to remove the reference to the bridge altogether. There are only three reference to the bridge in the RCTLinkingManager: if we find a place to store the launchOptions which can work for both Old and New Architecture, that would be great.

[cipolleschi]

Also... this should actually works already: in bridgeless mode, this module should be created by the RCTTurboModuleManager here.

This method checks whether there exists a _bridge or a _bridgeProxy and it sets the bridge ivar with the _bridge or the _bridgeProxy object (here).

So, my guess is that the

if (!bridge) {
    bridge = [RCTBridge currentBridge];
  }

Is not necessary at all, but we need to store the launchOptions in the bridgeProxy.

[zhongwuzw]

@cipolleschi you can see it also check _isLegacyModuleClass of class, so only legacy module can be set _bridgeProxy in bridgeless mode.

      if (_bridge) {
        [(id)module setValue:_bridge forKey:@"bridge"];
      } else if (_bridgeProxy && [self _isLegacyModuleClass:[module class]]) {
        [(id)module setValue:_bridgeProxy forKey:@"bridge"];
      }

[cipolleschi]

True, but _isLegacyModuleClass checks this. I think that this should be turned on in the OSS to simplify the migration...

I think we should just remove the && _isLegacyModuleClass in that check. We are already checking that the module supports the bridge property, so it would be better to just set the bridgeProxy if it's available.

[zhongwuzw]

@cipolleschi Done, please review again.

[cipolleschi]

This is good enough to unblock us in the short term. We should still look for a way to remove the dependency RCTLinkingManager -> RCTBridge for when we are going to remove it.

[cipolleschi]

/rebase - (this triggers an automatic rebase - build android should be green on main!)

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	18,918,797	+0
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	22,283,293	-11
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: c1081cc
Branch: main

[facebook-github-bot]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@cipolleschi merged this pull request in 90296be.

[github-actions]

This pull request was successfully merged by @zhongwuzw in 90296be.

^{When will my fix make it into a release? | How to file a pick request?}