Miguel de Icaza ᯅ🍉

Thinking about making my SwiftUI code cross platform, beyond Apple.

I don’t really want SwiftUI on every platform and dealing with the impedance mismatch of SwiftUI and the host - despite having a few OSS engines that do it.

What I have come to realize is that using SwiftUI @Observables is all you need: swap the actual front end for a tightly coupled UI to the host platform, but keep your logic shared.

And you can have an LLM do the heavy lifting for you.

Mar 7 at 10:19pmIvory for iOS
Show threadKrystian KopećMar 8
@Migueldeicaza I agree. As long as you push most of the code into services/view models (or any kind of code separated from the view) and make the view lean and dumb, the overhead of having multiple platform-specific views should be small. I’d definitely prefer to go this way in the era of LLM instead of having non-native cross-platform frameworks.
Show threadnSonicMar 8

@Migueldeicaza I’m using Xamarin/ now Maui for some years and in theory it’s how you describe it. Back with Xamarin it was two apps, each with its own “native” UI bound to the core logic that’s used by both apps, then with .forms / now Maui it’s “the same” UI which is nice.

But in reality it’s still adding platform specific code and handling. Navigation stack handled differently, Modal acting differently, statusbar, toolbar, navigation bar, accidental double touches …it’s quite some extra work

Show threadAlper Çuğun-GscheidelMar 8
@Migueldeicaza You keep the logic in Swift in this setup?
Show threadMiguel de Icaza ᯅ🍉Mar 8
@alper yes, the Logic would be still swift.
Show threadAndy FlisherMar 8
@Migueldeicaza that’s very much the approach Kotlin Multiplatform takes (it can do UI using Compose, think Xamarin Forms) but ultimately create core app and data logic and use platform UI, like Swift UI for the native interface - looks pretty flexible