fix: address comments under RFC

Author: artus9033

…s/0000-ios-scenedelegate-and-resizing.md …sals/0000-ios-scenedelegate-migration.mdproposals/0000-ios-scenedelegate-and-resizing.md renamed to proposals/0000-ios-scenedelegate-migration.md proposals/0000-ios-scenedelegate-and-resizing.md renamed to proposals/0000-ios-scenedelegate-migration.md

@@ -13,14 +13,14 @@ iOS26 introduced deprecation of many UIApplication APIs and made UIScene lifecyc
 
 ![](assets/0000-ios-deprecation-warning.png)
 
-It is possible to perform dynamic window resizing both via stage manager (split view) and freely via the bottom-right corner handle. `SceneDelegate` with proper configuration in `Info.plist` can enable the multi-window capability for iPadOS, which would require adjustments in RN code and RN libraries code to accommodate such design. Such a change would be large and shall be addressed in a separate RFC. The scope of this RFC is to cover a single resizable window (single instance of a given RN app), yielding the assumption that `UIApplicationSupportsMultipleScenes` **must not** be set to true at the moment. This RFC will bring in an additive change that should allow for adoption of a new `SceneDelegate` entrypoint while also allowing for (deprecated) usage of `AppDelegate`. Also, the `@react-native-community/template` and `packages/rn-tester` should be migrated to implement the `SceneDelegate` API.
+This RFC will bring in an additive change that should allow for adoption of a new `SceneDelegate` entrypoint while also allowing for (deprecated) usage of `AppDelegate`. Also, the `@react-native-community/template` and `packages/rn-tester` should be migrated to implement the `SceneDelegate` API.
 
-One related aspect not covered by this RFC is the performance of `useWindowDimensions` hook, which during intensive resizing of the application behaves suboptimal. This matter shall be addressed in a separate RFC.
 
-The idea proposed in this RFC is to:
+This RFC will bring in an additive change that should allow for adoption of a new `SceneDelegate` entrypoint while also allowing for (deprecated) usage of `AppDelegate`. Also, the `@react-native-community/template` and `packages/rn-tester` should be migrated to implement the `SceneDelegate` API.
 
-1) migrate from `AppDelegate` to UIScene lifecycle by adopting `SceneDelegate`
-2) educate on the need to migrate existing apps to adopt `SceneDelegate`
+:::note
+It is possible to perform dynamic window resizing both via stage manager (split view) and freely via the bottom-right corner handle. `SceneDelegate` with proper configuration in `Info.plist` can enable the multi-window capability for iPadOS, which would require adjustments in React Native code and React Native libraries code to accommodate such design. Such a change would be large and shall be addressed in a separate RFC. The scope of this RFC is to cover a single resizable window (single instance of a given React Native app), yielding the assumption that `UIApplicationSupportsMultipleScenes` **must not** be set to true at the moment. 
+:::
 
 ## Basic example
 
@@ -42,7 +42,7 @@ As an example, the following key APIs are already deprecated:
 
 ### `SceneDelegate` `RCTReactNativeFactory` entrypoint
 
-To support `SceneDelegate` lifecycle, a new entrypoint for RN application initialization should be provided in `RCTReactNativeFactory`, which would be invoked from `SceneDelegate` lifecycle methods. The existing entrypoint from `AppDelegate` would be kept for backwards compatibility, making this an additive change. An example code snippet of a `SceneDelegate` using React Native proposed in this RFC would be:
+To support `SceneDelegate` lifecycle, a new entrypoint for React Native application initialization should be provided in `RCTReactNativeFactory`, which would be invoked from `SceneDelegate` lifecycle methods. The existing entrypoint from `AppDelegate` would be kept for backwards compatibility, making this an additive change. An example code snippet of a ``SceneDelegate`` using React Native proposed in this RFC would be:
 
 ```objc
 @interface SceneDelegate ()
@@ -90,24 +90,24 @@ To support `SceneDelegate` lifecycle, a new entrypoint for RN application initia
 Adoption of `UIScene` lifecycle requires the following actions:
 
 * In application base code  
-  * migration from `AppDelegate` as the primary point of lifecycle-related logic to `SceneDelegate`; for backwards compatibility, RN public API integration points will still be compatible with `AppDelegate` approach for users that may not want to migrate immediately  
-  * invoke RN `RCTLinkingManager` methods from `SceneDelegate`:  
+  * migration from `AppDelegate` as the primary point of lifecycle-related logic to `SceneDelegate`; for backwards compatibility, React Native's public API integration points will still be compatible with `AppDelegate` approach for users that may not want to migrate immediately  
+  * invoke React Native `RCTLinkingManager` methods from `SceneDelegate`:  
     * `scene:continueUserActivity:`
     * `scene:openURLContexts:`
   * update of the app's Info.plist to include a `UIApplicationSceneManifest` specifying the support and disabling multiple scenes capability  
 * In React Native code:  
   * migration of code that relies on `launchOptions` and deprecated `UIApplicationLaunchOptions`\* keys to `UIScene` lifecycle and `UIScene.ConnectionOptions.userActivities`
-* In React Native code, RN native libraries’ code:  
+* In React Native code, React Native native libraries’ code:  
   * migration of app lifecycle methods from application\* to scene\* as per [https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle](https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle)  
   * migration of code that relies on *any* *deprecated* `AppDelegate`-related APIs, which detailed description of is presented below
 
 To enforce the user not to enable the `UIApplicationSceneManifest`.`UIApplicationSupportsMultipleScenes` capability in `Info.plist`, from now on, the following warning would be printed from `RCTReactNativeFactory` provided the user had enabled the multi-window capability:
 
 ![](assets/0000-console-warning-unsupported-configuration.png)
 
-#### Migration: RN app template, RNTester
+#### Migration: React Native app template, RNTester
 
-In case of the RN app template, the iOS boilerplate code is limited only to basic bootstrapping of the application. This implies adjustments to:
+In case of the React Native app template, the iOS boilerplate code is limited only to basic bootstrapping of the application. This implies adjustments to:
 
 * `Info.plist` \- add support for `SceneDelegate`  
 * `SceneDelegate.mm` \- implement the `SceneDelegate`  
@@ -123,51 +123,38 @@ The linking manager is using `AppDelegate` methods for handling URLs being opene
 
 #### Migration: RCTDevLoadingView
 
-The does not account for updating the overlay `UIWindow` constraints so it does not get resized along with the main window. The proposed fix is to update the constraints based on KVO observation of the main window’s frame.
+The current implementation does not account for updating the overlay `UIWindow` constraints so it does not get resized along with the main window. The current implementation mixes automatic layout constraints and manual manipulation of `frame` property of the containing `UIWindow`. The proposed solution is to fully rely on Auto Layout constraints to position and size the loading view overlay window and instead of animating the window's frame, animate the container view's `transform`.
 
 ![](assets/0000-RCTDevLoadingView-width.png)
 ![](assets/0000-RCTDevLoadingView-width-clipped.png)
 
-#### Migrating Dimensions: internal state adjustment & naming convention
-
-Dimensions currently are exported as a constant. Such design does not fit the concept of resizable windows. To accommodate this, `RCTDeviceInfo` (iOS native module) should update its internal state variable upon changes to the frame so as to make `getConstants` return a value that is up-to-date at the time of invocation.
-
-`Dimensions` (JS API) contains a `getConstants` method that wraps the native `getConstants` method and caches the result internally. The caching would now be obsolete (since the value may change in time), therefore the underlying native method should always be invoked. Moreover, the naming of the JS `getConstants` method in face of resizable windows may be misleading, since from now on the dimensions are not constant. Therefore, I propose a gradual adoption of a new method of same functionality, `getInfo()`, along with the deprecation of `getConstants()`, on the JS API side. A rough draft of the JS API changes would be:  
-
-![](assets/0000-nativedeviceinfo-api.png)
-
 ## Drawbacks
 
-### Migration from `AppDelegate` to `SceneDelegate`
-
-- In React Native source and RNTester: will be covered by the PR following this RFC  
-- In user RN applications using `UIApplicationSupportsMultipleScenes=NO`: adjusting Info.plist and the entrypoint according to the upgrade helper diff  
-- In user RN applications using `UIApplicationSupportsMultipleScenes=YES`:  
-  - Ones not using native code:  
-    - adjusting `Info.plist` and the entrypoint according to the upgrade helper diff  
-    - ensuring that consumed libraries work well in multi-instance setups   
-  - Ones using native code:  
-    - the above  
-    - migrating from `AppDelegate` lifecycle methods to `UIScene` lifecycle methods  
-    - inspecting usage of singletons & static fields to ensure they logically fit the multi-instance reality  
-- In RN libraries:  
-  - migrating from `AppDelegate` lifecycle methods to `UIScene` lifecycle methods  
-  - inspecting usage of singletons & static fields to ensure they logically fit the multi-instance reality
+The drawback is that users will finally need to migrate to the `SceneDelegate` lifecycle and use the newly-introduced React Native entrypoint API.
 
 ## Alternatives
-What other designs have been considered? Why did you select your approach?
+
+No alternatives have been considered. Apple will enforce the change and we have to comply with it.
+An alternative way to approach it is to implement some breaking changes without preserving backward compatibility for a while. This can backfire as our users could churn away from React Native.
 
 ## Adoption strategy
 
 This would be a breaking change for apps referencing `AppDelegate`-related APIs (such as lifecycle / obtaining the window instance) or using libraries that do so. For users that do not use the aforementioned, this change would not be breaking. Third-party libraries that made use of `AppDelegate`-related APIs should migrate to UIKit scenes-related APIs to work properly with multiple scenes.
 
-## How we teach this
+An action plan for this RFC is as follows:
+- add React Native UIScene lifecycle API, migrate internal modules and RNTester $\rightarrow$ will be covered by the PR following this RFC
+- migrate user React Native applications: according to the upgrade helper diff $\rightarrow$ the scope of implementing this RFC is updating the React Native app template
+- migrate user React Native applications that have custom native code to use UIScene-lifecycle APIs $\rightarrow$ the scope of implementing this RFC is updating the React Native app template and React Native documentation
+  - we should explicitly mention APIs referenced in React Native code that were used with `AppDelegate` and were migrated in React Native internal code as examples:
+    - `UIScreen.mainScreen.bounds.size` ->  `RCTKeyWindow().bounds.frame.size`  
+    - `RCTSharedApplicatiorean.delegate.window` -> `RCTKeyWindow()`
 
-For use cases not featuring native code, the migration should follow the RN upgrade helper diffs to adapt native app code.
+From the users' perspective, for use cases not featuring native code, the migration should follow the React Native upgrade helper diffs to adapt native app code. For use cases featuring custom native code, the migration should follow the React Native upgrade helper diffs and also migrate to UIScene lifecycle APIs.
 
-For use cases featuring native code, the migration will additionally require migrating to UIKit scenes-related APIs.
+## How we teach this
 
-We should also mention APIs referenced in RN code that were used with `AppDelegate` and were migrated as examples:
+As described above:
 
-- `UIScreen.mainScreen.bounds.size` ->  `RCTKeyWindow().bounds.frame.size`  
-- `RCTSharedApplicatiorean.delegate.window` -> `RCTKeyWindow()`
+1. Via React Native documentation
+2. Via React Native upgrade helper diffs
+3. Via example in React Native code, RNTester app and the community app template