Add macOS support

[tomekzaw]

Details

Work in progress

Related Issues

GH_LINK

Manual Tests

Linked PRs

[matthargett]

visionOS support also coming? :)

[Simek]

Suggested change

	macos: 'Courier',
	macos: 'SF Mono',

Can we use SF Mono as default for macOS?

• https://developer.apple.com/fonts/
• https://en.wikipedia.org/wiki/San_Francisco_(sans-serif_typeface)

[tomekzaw]

Sure, thanks for this suggestion! Do we want to stick with Courier on iOS though?

[Simek]

Done a bit of checking, and looks like SF fonts are not included by default for all systems to this day on both iOS and macOS.

In this case Menlo or Monaco could be a viable alternative for both platforms:

• https://developer.apple.com/fonts/system-fonts/
• https://en.wikipedia.org/wiki/Menlo_(typeface)
• https://en.wikipedia.org/wiki/Monaco_(typeface)

[hmbrg]

Any updates on this one? MacOS support would be huge!

[tomekzaw]

After applying changes required by macOS itself (e.g. removing UIKit.h imports and replacing UIView with RCTUIView), there's a bug that prevents the user from typing more than only one character – all subsequent keypresses behave like pressing right arrow even though here I'm only pressing a key:

Screen.Recording.2024-10-10.at.20.21.15.mov

I managed to get it working by commenting out two swizzled methods in 7026df1 but then the formatting is applied with a slight delay:

Screen.Recording.2024-10-10.at.20.18.19.mov

So the formatting is incorrect for 1 frame:

[Saadnajmi]

Hello! I would be interested if this PR was revived, though as I understand it, now this library is new architecture only?
Could I get an idea of any blockers y'all were seeing in macOS if there were any?

[tomekzaw]

@Saadnajmi Hey, nice to hear that!

Yep, as of today @expensify/react-native-live-markdown supports only the new architecture, see explanation in #634.

So one of the blockers is that we're still using method swizzling to override the default behavior when typing or updating the value from JS. There's a PR that eliminates method swizzling but there are still some details that need to be fixed: #520

As far as I remember, there were no blockers caused by react-native-macos so far, only some API differences like lack of UITextRange (we'll need to use NSRange instead) or some problems with valueForKey:.

I'm curious to know about your use case, feel free to send me a DM.

[Saadnajmi]

@Saadnajmi Hey, nice to hear that!

Yep, as of today @expensify/react-native-live-markdown supports only the new architecture, see explanation in #634.

So one of the blockers is that we're still using method swizzling to override the default behavior when typing or updating the value from JS. There's a PR that eliminates method swizzling but there are still some details that need to be fixed: #520

As far as I remember, there were no blockers caused by react-native-macos so far, only some API differences like lack of UITextRange (we'll need to use NSRange instead) or some problems with valueForKey:.

I'm curious to know about your use case, feel free to send me a DM.

The use case is mostly "it would be real great to have a proper open source richtextinput library for desktop". It feels like a common request for desktop apps specifically. We have some custom stuff internally, but it's not something that would be useful in open source IMO.