Maybe a stupid question for Flutter users, but why are there two versions for every UI element in the source code? I'd expect that I initialize the theme once at application startup, and then the widget and layout engine works in "Windows" or "macOS" mode (or whatever else the theme decides to implement). What's the point of using a cross-platform UI framework if I need to duplicate the code for each platform?
> Maybe a stupid question for Flutter users, but why are there two versions for every UI element in the source code?
The author is using 3rd-party UI libraries that have each been designed to be platform-specific.
Traditionally a Flutter app would use the built-in UI components that are not platform specific, but then you end up with a Material-style look and feel.
There's not actually anything stopping the app from running with the macOS style UI on a Windows machine or using the Windows-style app on the web platform because they're all inherently cross-platform. In fact, the Windows-style UI package actually has compiled to Flutter web and you can use it straight from your browser: https://bdlukaa.github.io/fluent_ui/
The decision to build separate UIs for each platform was the author's choice, but it's not a traditional Flutter practice.
If you're happy with the UI looking the same on each platform then you don't need any duplicate code. E.g. I used to have a Android+iOS app that was Material UI, so on iOS it looked like a Google thing and less like something that was Native Apple.
If you want it to look native on each platform (and this is key) you need to write different code anyway. MacOS and Windows design rules behave sufficiently differently that some of your UI logic will need to be different on each platform - it's not just a different skin that can be abstracted away.
Flutter itself doesn't magically do anything for you - it doesn't care what platform you're running on because it does all its own rendering. It'll perfectly happily let you build a Mac looking app on Windows. It's then up to the libraries that you use (or create) to do whatever you want and abstract away whatever cross platform details.
The point I am trying to make is that Flutter is doing the right thing here, but the ecosystem is still maybe a bit limited.
It makes sense if you have significant code that's not UI-related.
IIRC, Photoshop is implemented this way - there is little code reuse at the UI side, but the bulk of the program is platform neutral. I had Photoshop (2.5) running on IRIX on my desktop for some (very fun) time.
I too had Photoshop running on IRIX way back when. As a matter of fact, it saved my butt on a job where I had a massive file for a poster design, and it would keep crashing on my PC whereas on the O2 with an older version of photoshop it just chugged along slowly but surely. It was an exercise in patience, for sure, but it also ensured I could deliver on the job and ultimately get paid!
The peer widgets seem to have many differing properties. Compare the two AlertDialog widgets. You'll see they are very similar, but not at all the same:
There are some UI elements you cannot generalize, yes. But there are definitely some that you can. There is no reason you cannot have an abstract text input control with different native widget implements. wxWidgets has been doing it successfully for decades now.
