https://kotlinlang.org logo
Join Slack
Powered by
<https://www.donnfelker.com/why-kotlin-multiplatfo...
# multiplatform
e
https://www.donnfelker.com/why-kotlin-multiplatform-wont-succeed/ Yet again another article that seem to focus entirely on a mobile POV. I feel like there has to be a major investment into distancing Kotlin from the mobile world. Just a little a bit at least, or it's doomed to never be considered for anything else. But, starting from the new Wizard, we really aren't there, we're stepping backwards.
j
Have you ever tried to convince an iOS developer or a JavaScript developer to try Kotlin for their main language or for major components of their app? Ha! That’s a fun conversation …
Says the guy who thinks those devs would rather choose Dart 😁 https://www.donnfelker.com/flutter-just-might-work/
😂 3
k
Went rather well with our iOS devs actually 😂
☝️ 1
j
Cool, if they like it they like it. Ours are opening up to KMP thanks to Dart 🙂
🤣 5
k
The biggest hurdle and pain point for iOS and android eng on our team is gradle. Just generally painful
➕ 4
p
Why would people at large want to consider it outside of mobile? Where else in reality do you have common logic across several platforms? When creating some executable binaries? But you don’t need kotlin muliplatform for that, besides it’s a rather niche usecase. Or do you write the same backend logic for JVM, NodeJS, etc?
b
i think actually by bringing in kmp work load of IOS devs would atleast be reduces with common logic as major players would prefer native ui and as he said > Have you ever tried to convince an iOS developer or a JavaScript developer to try Kotlin for their main language There is no need to convince them if someone woud bringup KMP then android part already would be shared and natives can use it ios dev will not need to learn it anyways
k
KMP itself is useful for web stuff too, and I think webassembly will play a huge role there. People are itching not to use JS on the web where possible.
K 1
➕ 2
But on the server side it's not useful. Use Kotlin JVM
s
@kevin.cianfarini Through the JVM, you'd be able to share business logic between backend and frontend to improve or enable a frontend's offline behavior
👌 1
a
I disagree, kotlin it self need more time to be not dependent on java and others
s
KMP has the same chance of success as RN and Flutter, etc. It mostly depends on the quality of tooling that JetBrains can provide us
e
Why would people at large want to consider it outside of mobile
You can build all sort of SDKs/libraries with Multiplatform. There is almost no reason to bootstrap a project with Kotlin JVM instead of Kotlin Multiplatform nowadays.
➕ 2
s
Whatever they say, for me KMP wins when it comes to doing platform specific things. There is no other technology that embraces this. You can pick and choose whatever common thing you want and do rest natively.
☝️ 6
💯 5
☝🏼 1
☝🏻 1
p
I am using it for a web project. I don't want to write JS no more 🤭
➕ 5
s
And nowadays, as a mobile dev, not considering or learning other platforms, including cross platforms, code sharing platforms, will be a big hindrance to your career.
s
@Pablichjenkov do you have anything open source? I’m thinking of also supporting web for one of my pet project.
k
Through the JVM, you'd be able to share business logic between backend and frontend to improve or enable a frontend's offline behavior
Great point!
e
As a practical non-mobile example, I'm currently developing a Windows/Linux/JVM/JS client/server TCP protocol. The only non-shared part is the socket implementation, which Ktor does not - currently - offer.
➕ 1
p
Yes I do, although very early stage, has issues because compose-web still has has issues. Back to the subject. These tools came to stay, companies are interested in these Multiplatform tools to get better.
c
you'd be able to share business logic between backend and frontend
we are able to! I've been doing that for years now
k
Donn has been saying the same thing for a while. We chat about this on and off. That, essentially, devs don't change and want their tools. There is some truth to this, but obviously its not "true", or we'd all be coding in C or something. It's an anecdotal observation. Donn is a smart person and has been in the industry for a long time, but it's an opinion. However, he's also very good at marketing, and putting that post out right after "stable" wasn't an accident. Just keep that in mind before quote-tweeting or whatever 🙂 (Donn, if you're reading, I say that with respect)
👍 3
c
I agree with most points from this article, but there's one thing missing: KMP is not the same as other multiplatform solutions because of expect-actual. You are not forced to share everything, you can select exactly which part of the codebase you want to share (because the common ecosystem is more convenient there) and which part you don't want to share, and instead do fully native. This solves the main issue with multiplatform code: the ecosystem's not ready yet? Who cares? Share just the domain layer, do everything else custom. You like Ktor? Well, share the network layer too! You're never forced to do anything.
💯 5
k
Optional sharing, of course, is critical, but I wouldn't say its the first. There are other things about KMP that are important. I'll be honest, I didn't read the whole thing. Once you start arguing from "human nature" you're getting dangerously close to "trust me" as the basis of the argument. Anyway, while there is some reflexive pushback, that's far from the whole story. On the plus side, some devs are curious and like trying new things. That is more common as the tooling and libraries have improved. On the "negative" side, I feel like more devs, and dev management, are open to new things because the tech economy has made "diversifying" your skill set and increasing efficiency a priority. Also, Donn completely ignores the fact that, while devs influence tech decisions, they don't necessarily just get to make them. That's been one of my counter arguments for a while. At some point, if the tech is working well, it's pretty difficult to say "well, I just prefer to rewrite everything in Swift!" The danger for KMP adoption is to assume the pushback is simply reflexive, rather than listen and sift through the pushback for serious issues and try to address them. The simpler argument of "we've tried this before" ignores how progress happens. You learn what didn't work before and try to address it.
☝️ 1
👍 3
e
@kpgalligan note that mine wasn't an attack towards the article or the author. I'm purely stressing out the fact every KMP article or resource is mobile focused. And that, imo, should change. People need to understand you can do much more with KMP than using it in Android Studio.
👌 2
c
Well, I for one do no mobile development whatsoever, and I've been using KMP in production for 3 years or so.
very nice 1
k
I agree with that. I like using Kotlin/Native for CLIs quite a bit. I wish there was more documentation about raw binaries that aren’t XCFrameworks
For example, the dead code elimination bit in the docs is only called out for XCF and not other binaries
k
@Edoardo Luppi Oh, I also skimmed what you wrote 🙂 No offense. I just kind of scanned to the bottom. I don't disagree that Kotlin should expand outside of mobile, but it has considerably. At last KotlinConf, the % of "backend" Kotlin was quite high. In my talk, I actually said "I feel like I need to explain who Jake Wharton is", which was not the case, say, in 2018. I think it should expand further, of course. I'm very excited to see where WASM goes, both front and back ends (and in between somewhere? Edge servers?) Anyway, that and JVM server growth. My wife did the front end dev/bootcamp thing in 2019. Learned react/rails (I also got to learn react as sort of a TA to her, which has been pretty useful, but I digress). Anyway, she started a new job recently, and her first commit was actually Kotlin as they moved their backend to Kotlin, and she's never written any before. That's one data point, but I would say, its certainly picked up.
🎉 1
Native mobile is obviously important to KMP, but the next, say, 5-ish years will be pretty interesting. I don't have a lot of data on this, but "native mobile" really seems to have consolidated around larger apps/orgs. Startups, etc, don't seem to be doing anywhere near as much. I don't think that trend changes. Yet, users generally prefer "native" apps (by "native" I mean just "non-crappy"), and what the PWA crowd consistently misses. It's not simply that browser tech needs to catch up to "native" tech. The app stores and distribution are often critical. Anyway, native mobile KMP and Compose UI, assuming progress and tooling continues, could be a major player in that space that "abandoned" native apps for the last several years. That is the only part of the "startups don't build native" trend that can be pushed back. If "mostly-native" apps aren't as wildly expensive to build as they have been, that sector should grow (relative to whatever else is going on in tech). What'll also be interesting to see, and maybe a complete fail, but maybe not, is how both the browser trend towards "sandboxed containers" rather than "custom, restricted JS Apis" (https://developer.chrome.com/blog/fugu-status/, https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system/), WASM, and "portable UIs" (Compose Canvas being one option, obviously), will allow building a much more homogenous client. The "will WASM and Compose replace JS and React?!" clickbait debates aside, the fact that this kind of deployment will be possible soon (if it isn't already), could change a lot of thinking. A lot of "mobile-first" startups still need to build a website, so the decision is often something like "We have the website and its in react, and the dev says React Native is great, so..." If its more like, "well, we can make the mobile client available from the web, and add some more views for larger screens...", the situation could change. If you say that outside of the Kotlin slack, prepare for a lot of "always bet on Javascript" style replies, but we'll see...
e
but it has considerably
I agree, sure. I mean, I'm more than happy to see KMP on mobile. It means it works. But then you see a talk where they say "KMM was wrong, scrap it", while building docs and whatnot where mobile is the only thing mentioned. That's why I'm not entirely happy. Regarding WASM, I feel like it's blown out of proportion. WASM adoption will grow but it will take ages, while Kotlin seem to be diverging resources away from the JS backend. WASM exists as a KMP target because of Compose pretty much, that's the main purpose.
k
WASM exists as a KMP target because of Compose pretty much, that's the main purpose.
That I strong disagree on. WASM exists as a KMP target because the GC profile (among others) is/has matured and stabilized. WASM progress has been slow largely because its been primarily the domain of C++, Rust, etc. In the same way that I like to push back on people who think sharing code is bad with, "well, why do we think sharing code is bad?", for web, the question is "well, why do we think JS is good?" and, more importantly, "what happens to JS if you don't need it?" Native mobile teams don't share code because it's painful to do so for a number of reasons, but if you removed that pain, writing the same code multiple times would be nonsense. If WASM languages and tooling improve considerably, and you can publish to the web with similar(ish) architectures that you'd use for non-web, let's say that's at least an interesting possibility. Now, I'm not saying that web teams will suddenly be ditching React and JS, not even close. However, if you're building a new product, and you're leaning mobile as the primary use case, and you don't need to hire a separate web team...
👍 4
j
My 2 cents is that I chose KMP over Flutter/RN because it allowed me to pick and choose which pieces I shared, so if I wanted to share UI I could, or domain, or network, or some combination of them all. I can’t easily do that with Flutter or RN. And I didn’t want to learn Dart or be using JS in my day-to-day work. Kotlin is a nice language to work with, imo. Now, I’m the only developer on my team (startup) which helps immensely with tech selection, but the fact that Kotlin is so similar to Swift made it super easy for me to learn (especially once the memory model loosened up.) I feel like I would have no issue hiring someone who only knew Kotlin for Android, or who knew Swift for iOS, and would not be hard to cross-train. You don’t need to be a polyglot who knows esoteric languages. As for Compose UI, I have the same concern there as I do with Flutter since AFAIK it uses the same rendering engine as Flutter… Which means, you’re re-building the native UI and it has the risk of not feeling “native” on either platform. So I’ve stuck with SwiftUI/Compose on iOS/Android, respectively, and I’m keeping an eye on Compose UI to see what happens. All that to say, I think KMP can succeed as a mobile product. I think the mobile space is pretty saturated, so it’ll be hard to contend with the Flutters and RNs of the world, but I think it has great potential to be a heavy hitter and is already showing some fruit of that. Because KMP chose mobile first, they can get a lot of momentum in the mobile world before pivoting to the other use cases as well. I’m also super interested to see what happens with other platforms once more progress is made, but I don’t know if that will become useful for me or not. My advice for the KMP team would be not to put all your eggs in one basket, but don’t lose sight of the other baskets either.
👍 1
j
Beauty of Compose UI is also that you can start with it and if it doesn't fit your needs you only need to write a SwiftUI variant because the Android one you will already have written 🙂
k
On Compose UI, its the same thing as KMP. Optional. That's where I think it'll be rather different. See thread: https://x.com/kpgalligan/status/1720459176109920328?s=20 Interesting timing, as I'm doing this right now...
Copy code
@Composable
internal actual fun SettingsView(viewModel: SettingsViewModel) {
    UIKitView(
        factory = {
            println("Calling settingsViewFactory")
            SwiftUiFactoryFinder.settingsViewFactory(viewModel)
        },
        modifier = Modifier,
    )
}
Was going to post a pic but I broke something 🙂
👍 1
💚 2
💯 1
Figured it out. Koin couldn't separate the types I put in, but that makes sense (in the context). I'm mostly just hacking here to get a sense for how to approach architecture, etc. Anyway, while ugly because it's not styled...
😮 1
🙌 1
Now, were I to build a real app, I'd probably go the other way. Maybe "native" for the main screen and shared for the settings. I only did native for settings because there was much less architecture to pass around.
➕ 1
Also, should nav be SwiftUI with Compose views, or Compose nav with SwiftUI views? I assumed the former, but I'm less sure. Really depends.
The real value here, to condense this:
Beauty of Compose UI is also that you can start with it and if it doesn't fit your needs you only need to write a SwiftUI variant because the Android one you will already have written
is low risk. Risk is underestimated in the discussion of RN vs Flutter vs whatever.
👍 4
💯 1
c
I saw this article the other day, and gave up reading when I realized how mistaken his entire premise was. Technologies don’t need to “win”, nor will any technology every be able to “win”. Technologies exist to serve a particular niche, and as long as it is doing that in a way that sustains its own development, the technology is successful. And especially, looking at the example of Flutter, it seems like the author is skeptical of KMP and is looking for reasons it will fail. If Google could successfully convince so many people to learn Dart for Flutter, a net new language that has basically no other value besides Flutter, why is it so hard to imagine that JB and Google could do the same for Kotlin and Compose?
👍 7
And it’s also helpful to look at the JS ecosystem, which, by all measure, is the language that is currently “winning”. It’s ridiculously large in scope, number of libraries, number of developers, etc. but the JS landscape is incredibly fragmented. You’ve got React, Angular, Vue, and Svelte to name a few frameworks. Then you also have the folks that prefer the untyped ES6, while others like the static types of TypeScript. There are multiple build tools (NPM, Yarn, Lerna), and some folks prefer none of that at all and just write scripts directly into HTML. Even if one language is “winning”, as the community grows, it will naturally begin to specialize to better serve the particular needs of its users. And this is a good thing, a kind of “technological Darwinism”. If you don’t like React, that’s fine, there are other options for you to try out. The same kind of specialization happens whether it’s across languages or within a single language, but that doesn’t mean some technologies “fail” while others “succeed”. It just means that the world is massive, and the technology needs of the users and companies are so much greater than you can imagine. So lets embrace the diversity without bashing on other frameworks, while also being fully convinced in the one(s) you choose to use!
p
I see the web as the big piece of cake. I didn't expect the chrome team to put gc in production so fast. I forecasted 1/2 years
k
I saw this article the other day, and gave up reading...
Its an opinion about the future. It's also (again, respectfully, Donn) an opinion you can express for free. Nobody's going to dig up the post in a few years and throw it in Donn's face (or they may, but Donn has way more followers than almost everybody, so nobody will see it, or care). This is similar to most tech hot takes. The startup CEO's getting clicks with things like "there will be no software developers in 5 years!" aren't putting money on that (directly, anyway). Nobody will show up to collect on a bad take if they're wrong. Now, we all may be "wrong" for any number of reasons, but I don't think the primary one will simply be reflexive pushback from iOS devs. But, I should probably get back to Tuesday things...
c
> As for Compose UI, I have the same concern there as I do with Flutter since AFAIK it uses the same rendering engine as Flutter… Which means, you’re re-building the native UI and it has the risk of not feeling “native” on either platform. So I’ve stuck with SwiftUI/Compose on iOS/Android, respectively, and I’m keeping an eye on Compose UI to see what happens. > @Jacob Rhoda You're not the only one that feels this way. I recommend watching #kobweb and #decouple.
👀 1
k
On web world fragmentation, that is true. I do see people basically saying "JS is too entrenched. It'll always be the primary language". Then a new React competitor comes out and its like 1/4 of the community immediately switches, or Bun gets released and they raise a pile of cash. Yes, those are frameworks/tools and not the language, but still. The web community is not homogenous at all (throw typescript & friends in, of course). JS is not an optimal language. It exists only because you can't do anything serious on a browser without it. If there was a market for tech standup, there's some terrible joke along the lines of "If null was the billion dollar mistake, what is 
undefined
and triple equals?!" Not a good joke, but you get the point. Things change. Sometimes slowly, then "all at once". Or they don't. In any case, it'll be interesting.
😁 2
v
Biased message, I am in very bad mood. I didn't like the post but lemme share just my experience, related. I am an android dev with 7+ yofs, not the worst one. I am working in a small product team doing LMS platform. Like year ago we decided that we want to go from 2 native apps to 1 MP. We tried flutter, both android (me) and iOS devs wasn't hyped by Dart so we said no. After some time we researched KMP and me say yes, iOS said no again. iOS left. We hired new one senior, he also left after 4 months. Yesterday I bought MB pro 2023 and started using macos for the first time. After 2 days trying to configure everything I am really feeling like I hate xcode, my self, hate development and your face. Seems like my Sonoma macos is new and not all the answers from google correct for it. Also seems like my xcode15 also new and the same issue. Maybe it is just wrong time, unlucky. I managed to build on the mac both my project and new KMP project but only for android, worked almost out of the box. Building to iOS doesn't work for both my project or new one from the plugin. Sure thing, I remember I had the very same issue when I started on windows 10 years ago. JAVA_HOME? What, how. Maven or Gradle? But I was junior and I had no choice. But now, all these struggles just make me feel bad.
🤗 1
j
@Vlad I feel the pain. It can definitely be like that sometimes and it ends up being a struggle some days when things don’t work together. You’re right, Xcode 15 definitely broke some things (like the Kotlin plugin, until recently fixed). I haven’t upgraded to Sonoma yet out of fear of more things breaking. The tooling perhaps still has some ways to go, and more moving parts means more risk of breakage. By far, though, my experience with KMP tooling is still better than React Native, which breaks every 6 months when I have to touch that app again. My advice for you is ask questions in #ios and/or #multiplatform. Lots of people willing to help out.
🙏 1
p
It takes some time to get used to the Mac way of doing stuff but then, happens like from java to kotlin. You don't want to go back
a
Donn needed clicks, and it is far easier to obtain clicks by writing controversial takes, than writing informed ones. Hence this article. A useful technology, backed by competent people, is very likely to succeed - and KMP is one of them. There’s a place for KMP just like there’s a place for every other similar tech, ReactNative, Flutter, etc. Java is the 3rd most popular language according to SO 2023 survey, after JS/TS, and Python. Which pretty much means Kotlin is 3rd most popular. Theoretically there’s no scarcity of potential KMP devs. Flutter is more popular than ReactNative and it uses Dart! KMP is successful because it actually solves a long standing problem the right way, which the competitors failed to do. It is the right tool for the right job because it’s actually native to its multi-platforms. So when things get complicated, KMP allows switching to pure native in a non-complicated way. KMP is just the next significant evolution step of cross/multi-platform technologies. https://survey.stackoverflow.co/2023/#technology-most-popular-technologies
👍 1
j
I mean, Kotlin intends to replace Java, but just because of this and that it was designed originally to run on the JVM doesn’t mean that they’re identical. That’d be like saying Java is the 3rd most popular language so therefore Clojure, or Scala, or Groovy is also the 3rd most popular. Languages are tools and often better for different tasks. But what you can use a language for often affects one’s willingness to learn it. Apple platform developers like Swift, Android devs like Kotlin, etc. If Kotlin was as niche as Dart is, you’d have the same problem with adoption. As an example, when NodeJS came out, suddenly all these frontend developers could use the same language on the back end and become backend developers. The horizon was expanded. Similarly, now KMP makes it easier to share code between Android and iOS (and web and CLI and backend, like NodeJS). It’s all about expanding your existing market share and making the best experience for the biggest amount of people.
👍 1
k
Yeah, it's interesting to see the responses. Either "this guy's take is terrible" but sharing it, which gets traffic, or "what an informed piece!" for people who want to believe that native dev is the only reasonable solution. Again, I like Donn, but you could sum it up with "1) iOS devs won't like it, and 2) since its new you can't find devs for it". Neither point is interesting or new, to me I guess. To be specifically critical, the points are backed on history of working with devs and speculation, and neither as far as I can tell, any research. Just anecdotes, and anecdotes not specific to KMP. Its like the Dropbox post. What it actually says is C++ was a bad choice, but it's like a Rorschach test for people who simply don't want to entertain anything except fully native dev. Donn's post is being shared to amplify either "he's so wrong!" or "he's so right!", but there's not really any new info there. To be fair, I skimmed through it because I've talked about this with Donn several times in the past, but perhaps I missed something...
✔️ 2
What's interesting is the response on the Kotlin reddit and the Android reddit. The Kotlin reddit posts (multiple) were all pretty much downvoted to negative, but Android was doing fairly well. A lot of the comments were the usual uninformed replies, summed up with "we've tried this all before", yada yada.
p
I don't know man, I just worry about react native. That thing is everywhere and I really try to avoid it. Donn might be in my same shoes but kmp instead of rn
j
The format of these kind of posts seems to be: "We've tried it [having to rewrite everything in a new solution to get it cross-platform] before so that's why this [super flexible technology that doesn't require rewriting your whole codebase amongst other huge improvements] will not work" 😉
k
On the two points, having talked to a lot of teams at this point, some iOS devs are certainly reflexively against it. However, a lot of the feedback and pushback is legitimate, and that's what we've been focused on improving. We've met a lot of iOS devs who were quite interested. It depends. On "can't find devs", I mean, it's an interesting time to argue that you'll struggle to find devs who are willing to learn what I would argue is not a ton of new stuff. Head over to the iOS dev reddit. Multiple posts about how finding native dev jobs is very difficult.
p
This morning I just read that Amazon App heavily uses RN, I wanted to cry 😭
k
It does, and its not a great app. That's been the joke for a while. I'm amazed that amazon using RN is news.
💯 1
You know who doesn't use RN in their main apps...
p
I can confirm it is not a great App, that 💯, although it covers the basics for an e-commerce , perhaps is all they need
c
While I personally wouldn’t ever choose RN, I do believe it has a good use case in companies which have invested heavily in web devs but have no experience (or desire) to hire and train mobile devs, or maintain mobile apps. Does it make good apps? No. But does it make apps that can be deployed on the App Store? Yes. Flutter’s use case is companies that want to get into the native mobile space, but don’t have budget for separate iOS/Android teams. Similar to RN, it doesn’t create the best experience for mobile apps, but it gets the job done. KMP’s use case is companies that have already invested heavily in native technologies, but are trying to improve consistency across their Android and iOS apps. If you’re starting a new project, especially with Compose Multiplatform, reduced costs can also be another benefit, but until this point the main motivation I’ve seen is for improving consistency and reducing bugs [edit: by sharing logic].
👍 1
k
I can confirm it is not a great App, that 💯, although it covers the basics for an e-commerce , perhaps is all they need
If anything, I'd look at this as a positive for KMP and blended UI's. If you can write all of your logic with Kotlin, and write all of your UI with Compose, then make a few core screens SwiftUI, you'll accomplish the same thing, but it'll "feel" much better. At a company of the scale of Amazon, even if they wanted to have a single app code base, I imagine they'd be OK finding the devs to make that all Kotlin vs React.
KMP’s use case is companies that have already invested heavily in native technologies, but are trying to improve consistency across their Android and iOS apps.
For shared logic. New apps with Compose is the new "market".
jetpack compose 2
p
I would say 90% of the industry
k
What's interesting is how not far off the tech really is. I see people saying like, "Oh, it'll be a couple years". Last night and this morning I was just playing around with the Droidcon app and blending UI's. Compose "host", SwiftUI for the actual scrolling list, inside Compose tab view, links out to Compose nav and detail screens. The "view model" actually gets passed from Compose into SwiftUI, and it works. Still plenty to sort out (it doesn't remember the scroll position), but that's certainly solvable. Other architecture stuff, nav, etc, well, longer discussion.
dcswiftuiblend.mp4
Now, round-trip builds, tooling, etc. That'll all need work, but they're definitely working on that stuff.
👍 1
j
I think that as things continue, what I’ll be looking for are some “best practices” and libraries/framework that make doing those blended things really easy. Right now, I struggle with my architecture and knowing how best to cross that line between Kotlin / Swift. SKIE helps a lot, but with the plethora of various libraries (KMP-NativeCoroutines, KMP-ViewModel, MVIKotlin, Orbit, etc etc) makes it very confusing to figure out how you should be doing this. I love being able to pick and choose, but it makes your head spin. There’s a lot of friction there that I’m willing to endure, but I have been tempted to throw in the towel because of it before. I’m sure not everyone will have that endurance.
k
SKIE helps a lot, but with the plethora of various libraries (KMP-NativeCoroutines, KMP-ViewModel, MVIKotlin, Orbit, etc etc) makes it very confusing to figure out how you should be doing this.
True. SKIE, in the grand scheme of things, just came out. On the rest, we, or more accurately, I, was struggling with this. I wanted some Touchlab content on best practice for this, but that ignores a basic historical fact. I started Android before there were phones, and we've been heavily involved in the community since the beginning. It took like 15 years of blog posts, libraries, conference talks, etc, to get to where Android is today. If you asked, "what's the best architecture?", good luck. "Clean", Molecule, MVVM, MVI, Circuit (slack), Workflow (square), etc. How long did it take to go from AsyncTask, to "service bus", to Rx, to coroutines, and everything else in between? 15 years. For KMP, we're talking about trying to pull together 2 (or more) different lifecycles, while the industry is going through a general transition to declarative state-based UI. It's going to be confusing for a while.
I struggled with trying to have a comprehensive answer. That won't work. Right now, on the SKIE end, I want to "finish" the next step, which is getting Flow structures into SwiftUI in a way that isn't overly manual. Sort of like 
collectAsState
in Compose. SKIE is at a layer below the other things mentioned (except 
KMP-NativeCoroutines
). It's a bridge tool. The goal is to present Kotlin structures to Swift, in a way that is natural to Swift, and helps with type safety. It says nothing about how you should manage your lifecycle, where your "view model" should live, or even if you should have one.
That layer is less opinionated. With all the grains of salt you want to take this statement, if you're starting a new KMP project that isn't 100% Compose UI, you should add SKIE right at the start. It will make enums and sealed classes much more usable, and for suspend functions you get cancellation and don't need to worry about which thread you're on. For Flow, they are AsyncSequence instances. They cooperate directly with the Swift async context. No extra boilerplate. However, using them directly in SwiftUI is more manual, but we have some property wrapper stuff coming (hopefully soon).
👍 1
On the "view model" layer, well, that'll be a debate for quite a while. Our current plan is to focus on what we'd use for different situations, but trying to give general "best practice" advice is necessarily opinionated, and won't have broad agreement.
j
Yes, I didn’t mean to mix categories. Of course, SKIE is a language interface rather than an architecture pattern. But the interface tools you have is going to affect the architecture you adopt. For example, my biggest issue currently is that I have these view models that inherit from an abstract class which specifics generics for its state and side effects. But when you bring those over in Obj-C, you can’t make that conform to Swift protocols that specify associated types because of runtime type erasure. (Classic Java problem, right?!) So now, I have to workaround that language issue in my architecture and it just brings confusion.
k
But the interface tools you have is going to affect the architecture you adopt.
True. The Kotlin you write that is intended to be used from Swift will need to be written in a way that will work. That is going to be difficult to avoid. Some of that is easier with SKIE, depending on what you're doing, but some isn't.
or example, my biggest issue currently is that I have these view models that inherit from an abstract class which specifics generics for its state and side effects. But when you bring those over in Obj-C, you can’t make that conform to Swift protocols that specify associated types because of runtime type erasure.
Concrete example?
j
@kpgalligan Sure. So I’m using Orbit-MVI, which has you make your view model by implementing a Kotlin interface with generics…
Copy code
public interface ContainerHost<STATE : Any, SIDE_EFFECT : Any> { ... }
class MyViewState 
class MyViewSideEffect
class MyViewModel: ContainerHost<MyViewState, MyViewSideEffect> { ... }
Now, how do you make this adapt to Swift’s 
ObservableObject
? I did this before SKIE was released publicly, so I used KMP-NativeCoroutines.
Copy code
public abstract class ViewModelContainerHost<STATE : Any, SIDE_EFFECT : Any>: ContainerHost { 
    var nativeStateFlow
      get() = container.stateFlow.asNativeFlow() // KMP-NativeCoroutines
    var nativeStateValue
      get() = container.stateFlow.value
}
I have all my view models inherit from this class instead. Now to make them all observable, I’d really like to do this…
Copy code
protocol Store<State, SideEffect> {
    associatedtype State
    var state: CurrentValueRelay<State> { get }
    
    associatedtype SideEffect
    var sideEffect: AnyPublisher<SideEffect, Never> { get }
}
// Some other things adapting Store to ObservableObject...

extension ViewModelContainerHost: Store {
    typealias State = STATE // ERROR
}
That’s a bit more verbose than I needed, but you get the idea. If you try to use the STATE type in the extension at all, you get the error “Extension of a generic Objective-C class cannot access the class’s generic parameters at runtime.”
23 Views
Open in Slack
PreviousNext
Powered by