Add support for distributed registration of Fabric Components with Dynamic Libraries #37274
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
Base commit: d8ced6f |
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 5, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: c02ca4072a97c4447eaeae69c37974ec4883fb09
cipolleschi
force-pushed
the
export-D45605441
branch
from
80b4479 to
61b1f55
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 5, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: 9a4d39a70461958924b3db19a2651f10910c2f88
cipolleschi
force-pushed
the
export-D45605441
branch
from
61b1f55 to
7f18b34
Compare
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
1 similar comment
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: 309b85e55c0f699505877a77a8d781202f47e7af
cipolleschi
force-pushed
the
export-D45605441
branch
from
7f18b34 to
c217037
Compare
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: 43d735872669150ecf607aecf1585ed66ba9d406
cipolleschi
force-pushed
the
export-D45605441
branch
from
c217037 to
a5d9ba3
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: 9f28e0668f211fc73f3fe8baaed3e79c91a2c9be
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: 1bc0c53a85cc2f08a2c36374a60756f74c252458
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: 786a6dbedd2ad5bf6b1ef73b940cbf944e080421
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
cipolleschi
force-pushed
the
export-D45605441
branch
from
a5d9ba3 to
2391be1
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: 715fe2bad458232e47fb46b178ec1ef90e894e82
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 6, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: ce86fcb12b059a8a6762e77b4648b7603203fa9a
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
May 9, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: D45605441 fbshipit-source-id: 60e7072441511d261ba6edb2123c29a299d97262
cipolleschi
force-pushed
the
export-D45605441
branch
from
2391be1 to
debdc1e
Compare
|
This pull request was exported from Phabricator. Differential Revision: D45605441 |
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 9, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: 2937897b08429452a209c8672af5c53b80534b7f
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 9, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: bb1c02ae835bf3a602c1e85ba4814b83bb0c512b
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
May 15, 2023
…namic Libraries (facebook#37274) Summary: Pull Request resolved: facebook#37274 With dynamic frameworks, we can't use floating C functions. The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies. Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building. The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded. **This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks. This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a ``` + (void)load { [super load]; } ``` method in their ComponentView. Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules. ## Changelog: [iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries. Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual. Differential Revision: https://internalfb.com/D45605441 fbshipit-source-id: a55c9cfa2b09d539fd9e38337493d2341461fdf3
|
This pull request has been merged in b6b09a7. |
This was referenced Aug 22, 2024
jakex7
pushed a commit
to software-mansion/react-native-svg
that referenced
this pull request
Aug 23, 2024
## PR concerning New Architecture support in the library 🎉 We at [Software Mansion](https://swmansion.com/) have been working on [improving support](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5) for the new architecture for quite a while now. If you need help with anything related to New Architecture, like: - [migrating your library](https://x.com/swmansion/status/1717512089323864275) - [migrating your app](Expensify/App#13767) - [investigating issues](https://github.com/facebook/react-native/pulls?q=sort%3Aupdated-desc+is%3Apr+author%3Aj-piasecki+is%3Aopen) - [improving performance](https://x.com/BBloniarz_/status/1808138585528303977) or you just want to ask any questions, hit us up on [[email protected]](mailto:[email protected]) --- ## Summary <!-- Simple summary of what was changed. --> PR adding `load` method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
kirillzyusko
pushed a commit
to kirillzyusko/react-native-keyboard-controller
that referenced
this pull request
Aug 23, 2024
## PR concerning New Architecture support in the library 🎉 We at [Software Mansion](https://swmansion.com/) have been working on [improving support](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5) for the new architecture for quite a while now. If you need help with anything related to New Architecture, like: - [migrating your library](https://x.com/swmansion/status/1717512089323864275) - [migrating your app](Expensify/App#13767) - [investigating issues](https://github.com/facebook/react-native/pulls?q=sort%3Aupdated-desc+is%3Apr+author%3Aj-piasecki+is%3Aopen) - [improving performance](https://x.com/BBloniarz_/status/1808138585528303977) or you just want to ask any questions, hit us up on [[email protected]](mailto:[email protected]) --- ## Summary <!-- Simple summary of what was changed. --> PR adding `load` method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
WoLewicki
added a commit
to software-mansion/react-native-screens
that referenced
this pull request
Aug 26, 2024
PR adding load method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
WoLewicki
added a commit
to software-mansion/react-native-gesture-handler
that referenced
this pull request
Aug 30, 2024
PR adding `load` method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
ja1ns
pushed a commit
to WiseOwlTech/react-native-screens
that referenced
this pull request
Oct 9, 2024
PR adding load method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
kkafar
pushed a commit
to software-mansion/react-native-screens
that referenced
this pull request
Oct 25, 2024
PR adding load method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information. (cherry picked from commit 29c98e2)
8 tasks
kkafar
pushed a commit
to software-mansion/react-native-screens
that referenced
this pull request
Mar 12, 2025
## Description <!-- Description and motivation for this PR. Include Fixes #<number> if this is fixing some issue. --> Fixes #2652 The `RNSFullWindowOverlay` component was not used with dynamic frameworks, leading to the incorrect use of a placeholder component. As highlighted in [this React Native PR](facebook/react-native#37274), all Fabric components must implement the `load` method to be correctly resolved. Although `RNSFullWindowOverlay.mm` already included this method, it was mistakenly placed in `RNSFullWindowOverlayContainer` instead of `RNSFullWindowOverlay`, where it should have been implemented. After correcting this placement, the reported issue is no longer reproducible 🎉. ## Changes <!-- Please describe things you've changed here, make a **high level** overview, if change is simple you can omit this section. For example: --> - moved `load` method from `RNSFullWindowOverlayContainer` to `RNSFullWindowOverlay` class ## Screenshots / GIFs ### Before  ### After  ## Test code and steps to reproduce <!-- Please include code that can be used to test this change and short description how this example should work. This snippet should be as minimal as possible and ready to be pasted into editor (don't exclude exports or remove "not important" parts of reproduction example) --> ## Checklist - [x] Included code example that can be used to test this change - [ ] Updated TS types - [ ] Updated documentation: <!-- For adding new props to native-stack --> - [ ] https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md - [ ] https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md - [ ] https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx - [ ] https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx - [ ] Ensured that CI passes Co-authored-by: war-in <[email protected]>
kkafar
pushed a commit
to software-mansion/react-native-screens
that referenced
this pull request
Mar 12, 2025
## Description <!-- Description and motivation for this PR. Include Fixes #<number> if this is fixing some issue. --> Fixes #2652 The `RNSFullWindowOverlay` component was not used with dynamic frameworks, leading to the incorrect use of a placeholder component. As highlighted in [this React Native PR](facebook/react-native#37274), all Fabric components must implement the `load` method to be correctly resolved. Although `RNSFullWindowOverlay.mm` already included this method, it was mistakenly placed in `RNSFullWindowOverlayContainer` instead of `RNSFullWindowOverlay`, where it should have been implemented. After correcting this placement, the reported issue is no longer reproducible 🎉. ## Changes <!-- Please describe things you've changed here, make a **high level** overview, if change is simple you can omit this section. For example: --> - moved `load` method from `RNSFullWindowOverlayContainer` to `RNSFullWindowOverlay` class ## Screenshots / GIFs ### Before  ### After  ## Test code and steps to reproduce <!-- Please include code that can be used to test this change and short description how this example should work. This snippet should be as minimal as possible and ready to be pasted into editor (don't exclude exports or remove "not important" parts of reproduction example) --> ## Checklist - [x] Included code example that can be used to test this change - [ ] Updated TS types - [ ] Updated documentation: <!-- For adding new props to native-stack --> - [ ] https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md - [ ] https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md - [ ] https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx - [ ] https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx - [ ] Ensured that CI passes Co-authored-by: war-in <[email protected]> (cherry picked from commit abb1e36)
jamesdev-king
added a commit
to jamesdev-king/flutter_ui_challenge_flight_search
that referenced
this pull request
Aug 1, 2025
PR adding load method needed for dynamic frameworks to work with the library. See facebook/react-native#37274 for more information.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
With dynamic frameworks, we can't use floating C functions.
The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies.
Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building.
The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded.
This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on. There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks.
This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a
method in their ComponentView.
Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules.
Changelog:
[iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries.
Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual.
Differential Revision: D45605441