Skip to content
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

Open
moffpage opened this issue Aug 31, 2021 · 9 comments
Open

UIKit support #228

moffpage opened this issue Aug 31, 2021 · 9 comments

Comments

@moffpage
Copy link
Contributor

moffpage commented Aug 31, 2021

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?

@arkivanov
Copy link
Contributor

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.

@fnc12
Copy link

fnc12 commented Aug 31, 2021

I am confirming. I also need UIKit support in my nice project using this great library. I am an experienced iOS developer and can help you but my kotlin XP is not so rich. How can I help you?

@moffpage
Copy link
Contributor Author

@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.

@fnc12
Copy link

fnc12 commented Aug 31, 2021

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

@arkivanov
Copy link
Contributor

@moffpage Decompose does not depend on MVIKotlin in any way, and I didn't mention MVIKotlin either. Why such a question?

@arkivanov
Copy link
Contributor

@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 Routers, and also multiple Routers in a component. But it would be also good to demonstrate UI state preservation while navigating between components. E.g. scrolling position should be restored when navigating to a previous component. There is currently no UI state which requires restoration in the Counter sample. So ideally we should add something for this, maybe some scrollable list, etc. I will update the Counter sample soon, so there will be UI state restoration as well.

UI state preservation is very important. It is supported by extensions-compose-xxx and extensions-android modules. And ideally it should work the same way in iOS. So let me first update the Counter sample, and then we can add UIKit. Does it sound good?

@moffpage
Copy link
Contributor Author

moffpage commented Sep 1, 2021

@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 subscribe and unsubscribe methods, couldn't we just subscribe and unsubscribe in UIViewController's (or UIView(?)'s) appropriate lifecycle methods? And I believe we could still use Combine with UIKit, which Decompose has compatibility with through extensions.

@arkivanov
Copy link
Contributor

@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 extensions-xxx modules published, which can be used by consumers to bind UI with Decompose components. But for iOS we can't publish anything like this, as explained in the linked issue. So the only way at the moment is to copy-paste solutions from samples, etc.

@moffpage
Copy link
Contributor Author

moffpage commented Sep 1, 2021

That'd be ok for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants