> And whoever does that inevitably will have to copy SwiftUI directly or alienate the people who actually know Swift.
I may be wrong, but I don’t think this is actually true. SwiftUI isn’t universally loved in the community, largely thanks to its rough edges and how it struggles with that last 10% of polish in projects written with it. While copying SwiftUI wouldn’t necessarily be wrong per se, you’d actually probably get more rapid buy-in by copying “boring” old imperative UIKit, as that’s what most writers of Swift are using.
s/SwiftUI/UIKit, doesn't matter. (though I'm happy to have someone else point out SwiftUI has...some growing pains...it would have felt unfair for me to do so)
Point is its DOA for UI on non-Apple platforms.
Either you:
- attract current Swift programmers and keep up with $APPLE_UI_FRAMEWORK with no assistance.*
- attract no one and make a brand new framework in Swift.
- bind to some other UI framework, alienate current Swift programmers*, get all the people who have been dying to write Swift yet didn't build a UI framework for 7 years
There's just no universe where using Swift to write UI on non-Apple platforms makes sense to any constituency. You have to be simultaneously obsessed with Swift and don't care about platform-first UI, or want to maintain two separate UI frontends.
I hate being that absolutist, but that is what 16 years of experience on Apple platforms has taught me.
I'm surprised by the # of people arguing there's a possibility something else coudl work. I guess what I'd say is, if there is, where is it? Swift was on Linux eons ago, I believe before I started at Google so 7+ years.
* People used to try this to do iOS/OSX cross-platform, those projects are dead. One could argue this is just because Catalyst exists. Sure, but, let's just say you need at least N / 2 engineers, where N = the number of engineers Apple has on an arbitrary UI framework, in order to keep up with it. That's a lot.
** I've been in Apple dev since iPhone OS 2.0, and while in theory this could work, in practice it doesn't. Ex. Qt won't appeal to Apple programmers. It's antithetical to community values.
I may be wrong, but I don’t think this is actually true. SwiftUI isn’t universally loved in the community, largely thanks to its rough edges and how it struggles with that last 10% of polish in projects written with it. While copying SwiftUI wouldn’t necessarily be wrong per se, you’d actually probably get more rapid buy-in by copying “boring” old imperative UIKit, as that’s what most writers of Swift are using.