iOS SceneDelegate migration proposal

[artus9033]

A proposal for adding SceneDelegate support to iOS.

View the rendered RFC

[cipolleschi]

Good job here!
I left a bunch of comments that should be applied/adressed in the RFC.

Make sure not to have any RN acronym. In official documentation we always use the full React Native product name.

[cipolleschi]

I don't think this is actually required for the SceneDelegate migration. probably we can move it to a different RFC/effort

[artus9033]

Agreed, I will move it from here, then

[artus9033]

I opened a separate RFC to track this idea: #969 - CC @cipolleschi

[artus9033]

Thank you for the comments Riccardo! Yes, sorry for not using the full name of React Native - I will keep that in mind. I think the RFC is now ready for a re-review, I applied your suggestions and also reworded few sections.

[TheRogue76]

Think it would be ok to not have that backwards compatibility. The Delegate is on a clock anyway that we do not control, so everyone NEEDS to migrate, and keeping the old approach around is just delaying an inevitable that will be significantly more painful then and we would need to live the double life in the mean time supporting both approaches.
Might be best to just say, from this version of RN, in order to be compliant with Apple's requirements, we are moving off, older versions not affected. Just being clear in the comms with the framework end users

[artus9033]

I agree on the point that this has to be removed at some stage, yet the objective I had in mind was to bring an additive, non-breaking change. We should definitely deprecate those methods, but a sudden removal would make an unpleasant surprise for the users. By deprecating, we make it a gentle migration and we'll get to removal anyway.

[matinzd]

I agree with Parsa. It is better to do this properly once rather than carrying things forward just for backward compatibility. Many things in the core break over time without being visible to us, and this is not an exception.

Another issue is the terminology itself. In the React Native ecosystem, the term “users” is often used to refer to consumers of a package, which easily causes confusion. In our case, those “users” are developers, not end users. Since the audience is developers, they are expected to adapt to changes and learn new patterns. We are not building a product for non-technical end customers.

[artus9033]

Thanks for sharing that, then I think the matter is up to be discussed. WDYT @cipolleschi ?

Regarding the "users", definitely the user persona I was referring to in this context was the developer - yet, I'll keep in mind that the default meaning here is the end user, thank you for noting that!

[objectiveSee]

Hey, this is great work. I'm exploring CarPlay support in a React Native/Expo app where CarPlay would be implemented natively in Swift using CPTemplate APIs, while the main app stays in React Native.

A few questions about the proposed API:

1. Will RCTReactNativeFactory gracefully handle scenes it doesn't manage? In my case, the CarPlay scene would be pure Swift with no React Native involvement.

2. Should the factory be instantiated globally or only for React Native-managed scenes?

3. Any caveats for scene role routing when some scenes bypass React Native entirely?

[artus9033]

Hey, this is great work. I'm exploring CarPlay support in a React Native/Expo app where CarPlay would be implemented natively in Swift using CPTemplate APIs, while the main app stays in React Native.

A few questions about the proposed API:

Thank you, it's a pleasure to hear that! Regarding your questions:

1. Will RCTReactNativeFactory gracefully handle scenes it doesn't manage? In my case, the CarPlay scene would be pure Swift with no React Native involvement.

I think it should not collide in any way, since scene management happens in the driver code of your application:

- (void)scene:(UIScene *)scene
    willConnectToSession:(UISceneSession *)session
                 options:(UISceneConnectionOptions *)connectionOptions
{
  // ...
  RCTReactNativeFactory *factory = [[RCTReactNativeFactory alloc] initWithDelegate:delegate];
  // ...
  [factory startReactNativeWithModuleName:@"RNTesterApp"
                                 inWindow:self.window
                        initialProperties:[self prepareInitialProps]
                        connectionOptions:connectionOptions];
}

That said, React Native operates only in the window in the scene you start it with.

2. Should the factory be instantiated globally or only for React Native-managed scenes?

I think this is a question more related to brownfield, this PR does not change anything w.r.t. the previous state, but anyway the factory should be initialized once from what I remember - as in this piece of code in react-native-brownfield.

3. Any caveats for scene role routing when some scenes bypass React Native entirely?

Just to confirm, by that you mean creating some scene roles that never have anything to do with React Native? I haven't done any experiments in such a scenario, but don't foresee anything that would break - the code path for initializing the RN scene would just never be hit, I guess.