>> But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that.

That's still true for flutter but it all depends on the requirements of the project. In the OP article, the point was to make something that is "native-looking" to Mac OS and Windows OS. This requirement does imply a requirement for different looking and behaving UI. Lose that requirement and then you can get the non-fractured code base back.

Perhaps you may reply "the framework should do that translation for you," to which I would respond "maybe you're right." It would be nice as a framework user to offload this type of work to the framework authors. Conversely, from the perspective of the framework authors they get to work on other features if they offload this type of work to the framework users.

I suspect the deeper questions for both framework users and authors is "who owns this work?" "what tradeoffs are users willing to make to gain this framework features?" and "what does joint ownership of this requirement look like?" Different framework communities will arrive at different answers.

At the end of the day as a pragmatic programmer you just kinda have to hack around the edges to smooth everything out for the end user.

In my projects when I need independent UI per platform I just extract the logic to a new component that renders the right thing for each platform. That way my views aren’t filled with conditionals the component handles it.

And this is why I think the goal of a cross-platform toolkit is misleading. If your language/library/compiler make it really ergonomic to conditionally target code for a platform, then you get the benefit of keeping your business logic in one place, and the pain only with testing the application.

Usually this is not the case, since interfacing with Cocoa is so different from Win32, for example. However, one shouldn't conflate that difficulty with the difficulty of testing an app across platforms.