fix(ios): [new arch] Module provider RNDatePickerManager does not conform to RCTModuleProvider

[hannojg]

On new arch iOS builds i was getting the following error:

We have to conform to that protocol for which we have to implement getTurboModule:.
This PR adds support for that which effectively fixes this issue

[therveux]

@henninghall Can you look at this ? A release would be really appreciated 🙏

[ElhanM]

hit this exact crash on RN 0.81 new arch with 5.0.13. i've been ripping out ios.modulesProvider as a stopgap but that kills the imperative modal module, so this is the better fix imo since conforming + implementing getTurboModule actually keeps it working. any chance of getting this merged? there's like 5 open PRs and a pile of dupe issues all for the same thing 🙏

[seba9999]

@henninghall Any chance to get that merged ? 👍

[godza]

Confirming this on React Native 0.86.2 (New Architecture, bridgeless) with react-native-date-picker@5.0.13 ‚Äî the app dies on launch with exactly Module provider RNDatePickerManager does not conform to RCTModuleProvider, then reload-loops.

Why some people can't reproduce it. ios/build/generated is sticky. A build whose RCTModuleProviders.mm was generated before upgrading to 5.x contains no date-picker entry at all, so the app launches fine and the version looks verified. Any later pod install regenerates the file, the entry appears, and the next launch breaks ‚Äî with nothing in the diff to explain it. To see the crash reliably:

rm -rf ios/build/generated && cd ios && pod install

This PR's approach looks like the right one. #929 removes the modulesProvider key instead. That does stop the crash, but it gives up the modal picker's TurboModule; making RNDatePickerManager conform, as here, keeps it.

One thing worth checking before this lands. On iOS the JS side never asks the TurboModule registry ‚Äî getNativeModule() in src/modules.js is:

case 'ios':
  return NativeModules.RNDatePicker
case 'android':
  return TurboModuleRegistry.get('RNDatePicker')

So after this change the native class satisfies codegen's conformance check, but useModal still reaches the module through NativeModules and the interop layer. That's enough to fix the crash, and it may well be the intent. But if the goal is a real TurboModule on iOS, modules.js probably needs TurboModuleRegistry.get there too ‚Äî and at that point the openPicker argument-count mismatch that #967 / #971 address starts to matter, since JS would be calling through the generated spec rather than the legacy bridge. Might be worth landing those together.