The economics of RN allows us to share the last 4. However, sharing the first is actually more or less impossible without tooling like react-native-web as the components that exist on a native iOS app and the components that exist in HTML are just different. Certainly you can argue that sharing this much business logic would necessitate that the UI layer looks all the same, but I fundamentally disagree. That is like saying that because all your clients use the same API, they all must look the same.
I guess there is an implicit value judgement here that React+Redux's approach is desirable for your team, so that motivates using utility libraries not optimized for the constrained environment and a FRP framework with those characteristics.
Yes, this is 100% correct. That being said you can also create a React app using FRP framework such as Cycle JS and share exactly the same amount of code that I've listed above. Our team has chosen to go the React/Redux approach; I would argue that as an untyped language Javascript is unsuitable for FRP in the first place, despite FRP's advantages in handling reactive UI.
+ view/UI layer
+ flux/redux stores
+ data fetching and processing
+ action creators
+ utility libraries (date functions, markdown processor, etc)
The economics of RN allows us to share the last 4. However, sharing the first is actually more or less impossible without tooling like react-native-web as the components that exist on a native iOS app and the components that exist in HTML are just different. Certainly you can argue that sharing this much business logic would necessitate that the UI layer looks all the same, but I fundamentally disagree. That is like saying that because all your clients use the same API, they all must look the same.