Panelists say JavaScript data layers and much of the UI can carry across mobile, web, and desktop. One example reached about 50 percent code sharing across desktop, web, and Android. They caution that shared code still needs platform-specific work so apps feel at home on each device.
Multiplatform Aspect of React Native
An unnamed Microsoft representative on the React Native EU 2020 Conference Q&A panel discusses code sharing across React Native platforms, adapting apps to desktop, React Native Skia, and the upkeep of platform forks with the host and other panelists.
The Microsoft representative points to desktop needs that mobile-first React Native did not yet cover well, including mouse-over feedback, drag and drop, and multiple windows. Their team had maintained a React Native Windows product on WPF, but it was no longer maintained because they needed to support Windows 7.
Panelists discuss whether a Skia renderer and synchronous execution could make React Native more appealing to Flutter developers. One describes React Native Skia as an early experiment for learning Fabric and extending React Native to another rendering platform, with key work still needed before it could be production-ready. Another argues that synchronous drawing helps respond to user input, while asynchronous work suits slower tasks such as network requests.
The Microsoft representative says React Native Windows uses automatically reapplied patches and is updated weekly, while macOS changes are merged manually and the project lags behind. Windows also uses a TypeScript-based Codegen parser and a different TurboModules API, which Microsoft is discussing with Facebook. The panel considers a future structure with a shared React Native core and separate platform implementations.
Takeaways
- Plan for platform-specific UI and interactions even when data and much of the code can be shared.
- Treat code sharing as an opportunity, not a promise of identical behavior across platforms.
- Match execution to the task: responsive drawing for user input, asynchronous work for slower operations.
- Keep platform forks easier to maintain with small, regularly reapplied patches and frequent upstream updates.
- Align fork-specific APIs with upstream early to reduce the cost of maintaining separate implementations.
Mentioned in this talk
Search inside this talk
What was claimed 12
- metricReact Native: About 50% code sharing across desktop UI, web, and Android in one team’s experience.
“We had about a 50 percent code sharing rate”
YouTube Unverified1 source· Talk
- useshundreds of apps in the Microsoft Store use it
“The Settings team is using React Native”
4:23inReact Native at Scale: How Microsoft is betting big on React Native to target BILLIONS of usersYouTube Verified6 sources· Talk
- featureReact Native: Encourages platform-specific interactions and native app behavior while allowing code sharing.
“it’s critical to ensure your app looks and behaves like a native app”
YouTube Unverified1 source· Talk
- featureSkia: Experimental renderer intended to draw each view itself; the project was described as far from production.
“we still need some critical parts, such as a capacitor, because we want to draw each view ourselves”
YouTube Unverified1 source· Talk
- uses
“React Native Skia is also my chance to learn more about Fabric”
YouTube Unverified1 source· Talk
- featureReact Native: The panel describes synchronous and asynchronous execution as both useful for user experience.
“we’ve realized both are equally important”
YouTube Unverified1 source· Talk
- featureFlutter: Can drive rendering directly to the graphics system and execute drawing synchronously.
“you can drive directly to the GL layer or directly to the graphics system”
YouTube Unverified1 source· Talk
- featureReact Native for macOS: Its upstream changes are manually merged and reapplied, leaving it more out of sync.
“React Native macOS is the most out of sync”
YouTube Unverified1 source· Talk
