The only way to survive with a single code base is to go the way of gamedev, to own the substrate you are running on completely. From rendering of fonts to user input. This, of course, depends on the complexity of software. App in this blog post is not really that hard compared to the effort any game would need to go to render on screen. C'mon, it is just a text editor, there is not much of anything there really. All this just shows the state of modern development of too many abstractions for really nothing in exchange except a slow, overengineered fashion hype train. Surprised, there is no mention of WebAssembly in there. (edit typos)
I assume you're sarcastic, because creating a good native editing experience from the ground up is not trivial, when you try to make context menus look native, have native editing keyboard shortcuts, integrate with system IMEs and accessibility for screen readers, etc.
No. There are absolutely no problems with providing accidental native context menu elements or integration with menubar, etc.
BTW, I just tried this app on Android, it is broken, it is simply showing white blank screen. And on macOS, and it asks $90 a year for basic markdown features. Just no.
How many times have you tried this? Text editors are not easy to write. There's a wonderfully fractal level of detail.
The differences in text editing experiences between platforms abound. The boundaries the cursor moves to for different inputs; e.g. are spaces skipped when moving word by word; are they only skipped at the start, at the end, or does the algorithm change depending on the direction of cursor travel. How selection changes from character-based to word-based if it starts with a double-click. How the scroll position changes based on cursor movement, selection extension drag, and so on.
Do you support multiple selection of text? Windows' built-in text box does, if you hold Ctrl down, you can select multiple discontiguous text ranges and delete, cut or copy them.
Cursor navigation isn't trivial. In word-wrapped text, a single location in the text can be represented by a cursor at the start of wrapped a line or the end. Do you go with what Emacs calls goal column (i.e. when cursor passes through short lines and needs to move backwards, does it "remember" where it was when you cursor through to a long line again)? Or does it gradually work its way back to column 0. And of course for variable-width fonts, targeting needs computing in pixels, not characters.
It's extremely rare for games to include a fully featured text editing experience. In the old days, you'd consider yourself lucky to get a navigable cursor over fixed-width text. Even today, where games take text input, it's frequently a simple one-line text box with just a navigable cursor and no selection.
Games also take a big shortcut on performance: a game loop is always running, always presenting frames ideally at the refresh rate. An editor can't afford that, it consumes too much energy. So now you need to worry about dirty regions and damage control, efficiently filling in areas revealed by scrolling and edits, taking care that letters may extend beyond naive bounding boxes, whether due to ligatures, kerning, anti-aliasing, and so on.
> The only way to survive with a single code base is to go the way of gamedev, to own substrate you are running on completely. From rendering of fonts to user input.
It is not, you do not own Flutter in a way that if in 5 or 10 years it stopped being maintained and broken on current platforms, or not available for a new platform you want to port to, you are screwed.
