SwiftUI? Very low, for technical reasons. Compose ...
# multiplatform
k
SwiftUI? Very low, for technical reasons. Compose for iOS would be more feasible, but it’ll be a while, and clearly not trivial
j
Could you delve deeper into these technical reasons? Why is SwiftUI much harder to use for mp than compose?
m
Well, it's written primarily for swift and apple platforms so you'd need full rewrite for MP. Compose is pure Kotlin, intentionally written as platfrorm-independant lib so port wouldn't be much of a hustle.
h
Also the general consensus in the iOS community is SwiftUI isn’t ready for prime time yet
k
Swift UI is far more ready than compose. Most prod teams won't be able to make ios13 the baseline for a year or 2. That's the bigger issue. As for "why compose and not Swift UI", @Marko Mitic hits on the big reasons. Also, the way the idea and code integrate is why these UI toolkits will be good. Even if you could "wrap" Swift UI , you'd lose that
j
I generally agree with what @kpgalligan said above. I'd just add that, given the semantic similarities between Compose/SwiftUI, it wouldn't surprise me to see 3rd party libs cropping up to provide a compatibility/translation layer in the future (i.e. something that autogens Compose/SwiftUI views from a single Kotlin source).
k
Autogen’s a maybe, but I don’t see how that would be popular. One side would need to be 100% “native” to the tool, so you get the dev efficiency (round trip editing, etc). The “other” side would then be full dependent on the output and uneditable. Not saying it’s impossible, but it seems super inflexible. A 3rd “anko-like” DSL might happen, but again, you lose the tooling. We’ll see, though. Either way, unlikely in 2020, so there’s plenty of time to speculate…
j
Yea I agree autogen is always hacky and hard to maintain. But these declarative UI DSLs are all so darn similar...
k
Yeah. Before they came out I thought there would be a common UI option sooner, but if anything their success will push that iff
*off