Edoardo Luppi
11/07/2023, 12:05 PMJacob Ras
11/07/2023, 12:16 PMHave 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/
kevin.cianfarini
11/07/2023, 12:30 PMJacob Ras
11/07/2023, 12:32 PMkevin.cianfarini
11/07/2023, 12:33 PMPavel S
11/07/2023, 12:38 PMBharat Kumar
11/07/2023, 12:39 PMkevin.cianfarini
11/07/2023, 12:42 PMstreetsofboston
11/07/2023, 12:50 PMAhmed Riyadh
11/07/2023, 12:51 PMstreetsofboston
11/07/2023, 12:51 PMEdoardo Luppi
11/07/2023, 12:51 PMWhy would people at large want to consider it outside of mobileYou 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.
Spoudel347
11/07/2023, 12:52 PMPablichjenkov
11/07/2023, 12:52 PMstreetsofboston
11/07/2023, 12:53 PMSpoudel347
11/07/2023, 12:56 PMkevin.cianfarini
11/07/2023, 12:59 PMThrough 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!
Edoardo Luppi
11/07/2023, 12:59 PMPablichjenkov
11/07/2023, 12:59 PMCLOVIS
11/07/2023, 1:15 PMyou'd be able to share business logic between backend and frontendwe are able to! I've been doing that for years now
kpgalligan
11/07/2023, 1:15 PMCLOVIS
11/07/2023, 1:18 PMkpgalligan
11/07/2023, 1:27 PMEdoardo Luppi
11/07/2023, 2:08 PMCLOVIS
11/07/2023, 2:09 PMkevin.cianfarini
11/07/2023, 2:09 PMkpgalligan
11/07/2023, 2:14 PMEdoardo Luppi
11/07/2023, 2:41 PMbut it has considerablyI 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.
kpgalligan
11/07/2023, 2:49 PMWASM 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...
Jacob Rhoda
11/07/2023, 2:52 PMJacob Ras
11/07/2023, 2:54 PMkpgalligan
11/07/2023, 2:59 PM@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 🙂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 writtenis low risk. Risk is underestimated in the discussion of RN vs Flutter vs whatever.
Casey Brooks
11/07/2023, 3:21 PMPablichjenkov
11/07/2023, 3:32 PMkpgalligan
11/07/2023, 3:34 PMI 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...
CLOVIS
11/07/2023, 3:35 PMkpgalligan
11/07/2023, 3:40 PMundefined
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.Vlad
11/07/2023, 3:48 PMJacob Rhoda
11/07/2023, 3:59 PMPablichjenkov
11/07/2023, 4:23 PMalexei
11/08/2023, 3:57 PMJacob Rhoda
11/08/2023, 4:14 PMkpgalligan
11/08/2023, 4:21 PMPablichjenkov
11/08/2023, 4:32 PMJacob Ras
11/08/2023, 4:34 PMkpgalligan
11/08/2023, 4:34 PMPablichjenkov
11/08/2023, 4:34 PMkpgalligan
11/08/2023, 4:34 PMPablichjenkov
11/08/2023, 4:36 PMCasey Brooks
11/08/2023, 4:38 PMkpgalligan
11/08/2023, 4:39 PMI can confirm it is not a great App, that 💯, although it covers the basics for an e-commerce , perhaps is all they needIf 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".
Pablichjenkov
11/08/2023, 4:42 PMkpgalligan
11/08/2023, 4:44 PMJacob Rhoda
11/08/2023, 5:18 PMkpgalligan
11/08/2023, 5:27 PMSKIE 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.
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.Jacob Rhoda
11/08/2023, 5:36 PMkpgalligan
11/08/2023, 5:40 PMBut 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?
Jacob Rhoda
11/08/2023, 7:16 PMpublic 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.
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…
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.”