I work at Notion and recently rebuilt much of the editor core, and I don’t think Slate is a good choice because it considers nice, simple code more important than CJK or Android support. Notion doesn’t use Slate or any other editor framework. I just study a lot of editor core code.
1. Android also has a browser. It is an important platform with many users.
2. Building an editor is so complicated that most organizations want to do it only once. They build a web editor, and wrap it in a native app. The shell like file browser, sharing screens, etc are “native” but the editor surface is a webview. This is how Quip, Dropbox Paper, Google Docs, Notion, etc work. Even iOS worked this way initially for all editable styled text (per https://twitter.com/kocienda/status/1400484473540513792?s=21...)
3. If you are going to bet the core competency of your business on a framework, it’s important to understand the motivations and limitations of said framework.
Slate has a nice, approachable API from a React perspective. I think depending on your project it could be an okay trade off.
I co-wrote a post about our editor internals after finishing up the recent re-work but we decided not to publish it to conserve our Competitive Advantage.
Since it doesn’t implement editing itself I haven’t studied its source. Under the hood it’s ProseMirror so it should be okay, although I’d be uneasy about stacking abstractions too high: Your code —> TipTap React —> TipTap Extension —> ProseMirror Plugin —> ProseMirror Core —> DOM feels like there’s a lot of incidental complexity to learn all of the APIs across these layers. Right now the docs site is returning HTTP 502 to me ¯\_(ツ)_/¯.