-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UIKit support #228
Comments
Decompose is primarily designed for declarative UI frameworks, like Compose, SwiftUI, React, etc. Also it is not possible to publish such an iOS framework (see the following thread for more information on this). All I can do here is to try to create a sample iOS app. However it might be difficult for me, as I'm not an iOS developer. Would it help you? I might need some help from community in this case. |
I am confirming. I also need |
@arkivanov I though Decompose didn't rely on MVIKotlin, why is it important? Sample iOS app would be very much appreciated! It'd help me a lot. I could help as far as I can myself. |
SwiftUI can work with UIKit very well. Example so I am sure that it is very easy to add UIKit projects support and it also will make this beautiful lib even more popular cause a lot of legacy projects will be able to migrate to it |
@moffpage Decompose does not depend on MVIKotlin in any way, and I didn't mention MVIKotlin either. Why such a question? |
@fnc12 I will appreciate your help here! There is Counter sample in this repository. For Android it has two separate UIs: one using Jetpack Compose, and another one using normal Android Views. They both integrated in the MainActivity, depending on a flag. For iOS there is only SwiftUI. So I think we can do similarly to Android here and add UIKit, either in the same app with a flag (if possible), or as a separate app/target. The Counter sample demonstrates nested UI state preservation is very important. It is supported by |
@arkivanov Sorry, I didn't mean anything related to MVIKotlin, just wanted to clarify if Decompose somehow depends on Reaktive? If not, what's the issue? Do we have to to have adapters for RxSwift? Since Value<*> has |
@moffpage I provided the link to the similar discussion we had in Reaktive. It explains why it is not really possible to create and publish a separate iOS Framework with Swift extensions and helpers. E.g. for Android we have |
That'd be ok for now. |
Hi! I'm currently using this amazing library to provide (viewmodel-alike) components to plug into our Android and iOS clients. The Android side is touched on pretty well: it provides extensions to both Jetpack Compose and View UI-building approaches for Android, but only for SwiftUI in iOS side. Unfortunately, Apple doesn't provide compatibility for SwiftUI and Combine with versions, older than iOS 13, but we have to support our customers with earlier devices like iPhones 5S-6 series, which unfortunately do not support iOS 13.
What are the possibilities of this development? I'm priorly interested in linking routing functionality to UIKit. With the rise of Kotlin Multiplatform Mobile technology, I think many people will find this very helpful, since nobody (except maybe Google and Facebook) provides common UI framework and it's usually suggested that native controls should be used. SwiftUI is amazing and all, but it has several deficiencies, e.g. being inconsistent and buggy, and Apple won't deprecate UIKit soon enough. And SwiftUI also provides compatibility with UIKit through UIViewRepresentable, just like Jetpack Compose does the same through AndroidView function. Will this fact help in the development, somehow?
The text was updated successfully, but these errors were encountered: