Any interest in macOS support?

[shirakaba]

I've ported the iOS implementation to macOS (for react-native-macos). I can submit a PR if desired (although I suspect there's not too much interest, given that react-native-macos is still in alpha). See the readme for the things it may lack compared to the iOS implementation. Here is a screenshot of it working on Wikipedia, injecting some JS into the sidebar.

[insraq]

I am sure there are people interested in macOS support. As long as it does not add too much complexity to the project, I am happy to merge the PR if you want to open one. And after the PR gets merged, I can add you as a contributor to maintain the macOS port, if it makes things easier.

[shirakaba]

Sounds good!

As long as it does not add too much complexity to the project

In practice, barely any changes to the original code were needed – just substituting UIKit references to AppKit equivalents and removing references to the UIScrollView (the macOS implementation doesn't have a scrollView at all). Any non-visual code can be instantly shared between the macOS and iOS codebases without making any changes.

Currently I've isolated the project so that, just like there's an ios folder with an Xcode project inside, there's now also a macos folder. Is this an acceptable file structure?

[insraq]

I am not the expert on file structure for macOS support. I am sure there are other react native components that support macOS and we should follow their practice.

[shirakaba]

As react-native-macos is still in alpha, there are few (if any) components. The only one I am aware of is react-native-touchbar, which seems to assume it won't run on any other OS (indeed, macOS is the only system with a touchbar). In fact, this is probably most similar to the present ios and macos folder separation.

I think the only alternative options to my current approach are:

1. Use just one codebase, but separate the code files into an MVC architecture (so that we have platform-specific View code) – but this is outside of my expertise. This would surely involve using pre-processor directives (see below), and I haven't been able to get that working.

2. Use one codebase, but maintain the current architecture, instead branching the existing code using pre-processor directives so that the macOS takes one branch while iOS takes another (generally just for view code). I haven't managed this without the compiler making complaints though, so I can't say how to do this.

[shirakaba]

PR created: #148 🚀

[chitezh]

I think this is better to publish these changes as a different package because of the following

• it increases the bundle size by over 50%.
• react-native-macos is an experimental lib that is not being actively developed
• It adds lots of tech debt because most of the code are duplicated.

[insraq]

@chitezh If macOS support is not needed, as long as it is not linked, it shouldn't increase the build size. But other concerns are quite valid. I will leave the PR open for more discussions.