What should be featured in this template?

[malliaridis]

I have started working on a proposal and was wondering which libraries / elements should be featured in this template.

As we already discussed in arkivanov/Decompose#434, including a module for shared Decompose code and another module for shared Compose UI is one of the requested features. This includes two ios modules, one with Compose UI and one with SwiftUI. The same integration can be done for Android, providing one module with Compose UI and one with XML. Would that be worth the extra module?

And what about other integrations, like MVIKotlin, state preservation (parcelize-darwin), Reaktive or Coroutines support?

In my opinion, a basic navigation example with state preservation would be sufficient, but I usually use Decompose together MVIKotlin and Coroutines and therefore I would find it handy to also have an extended template with those included.

[arkivanov]

Thanks for working on this!

I suggest to begin with the following module structure:

• shared - contains Decompose components, I think we can begin with just one RootComponent showing "Hello from Decompose".
• compose-ui - depends on shared and contains Multiplatform Compose UI, just one RootContent function to begin with.
• app-android - depends on both KMP modules and contains only Compose integration (I think no need for XML for now).
• app-ios-compose - an iOS app with Compose integration, depends on both KMP modules.
• app-ios-swift - an iOS app with SwiftUI integration, depends only on shared module.

What do you think?

[arkivanov]

Awesome! Please try making small PRs, so it's easier to review. Thanks for working on this! 🚀

[azlekov]

Hey guys, I'm following the discussions some and there because I'm also interested in unifying my stack, so I can bootstrap quickly some pet projects. I spend some time to adjust the jetbrains template to use decompose, no cocoapods, material3 - you can check it here: https://github.com/dodi-smart/decompose-multiplatform-ios-android-template

@malliaridis regarding migrating from cocoapods to framework, check this: JetBrains/compose-multiplatform#3340

[azlekov]

@arkivanov can you review my changes there are in single commit. I'm concern about plugging the lifecycle and everything in iOS using the compose UIViewControllerRepresentable

[malliaridis]

@arkivanov I agree on keeping PRs small. It's just the initial one that will be a bit overwhelming. But any follow-up changes can be kept simple.

Thanks for the resources @azlekov. The PR you posted is quite similar to the blog post Arkadii shared. I realized that the easiest approach is to create a multiplatform project via Android Studio for iOS and Android and go from there (adding the other platforms one by one). That way bootstrapping a project without cocoapods is straight forward and works out of the box. I will also include many parts of the sample project the Decompose repo contains, since there are already a lot of best practices applied and it works best with Decompose.

But I will definitely look into your project too to see if I missed anything crucial. Feel free to review and give feedback to the proposal too. The more input and opinions the better the template can be optimized for the general purpose. :)

[arkivanov]

@azlekov Thanks for your input!

PS: I've left a comment in your repository.

[devjorgecastro]

I have started working on a proposal and was wondering which libraries / elements should be featured in this template.

As we already discussed in arkivanov/Decompose#434, including a module for shared Decompose code and another module for shared Compose UI is one of the requested features. This includes two ios modules, one with Compose UI and one with SwiftUI. The same integration can be done for Android, providing one module with Compose UI and one with XML. Would that be worth the extra module?

And what about other integrations, like MVIKotlin, state preservation (parcelize-darwin), Reaktive or Coroutines support?

In my opinion, a basic navigation example with state preservation would be sufficient, but I usually use Decompose together MVIKotlin and Coroutines and therefore I would find it handy to also have an extended template with those included.

I suggest that we could have different examples; perhaps in another example, we could have the implementation with MVI. The idea is to have very simple and easy-to-understand resources to learn how to set up Decompose, especially for those of us who are starting with KMP (I say this from my perspective with the little time I have spent on this technology 🙂).

[arkivanov]

Integrating with other libraries may bloat the template and confuse users. E.g. one may think that MVIKotlin is necessary, while it's not. Though, later we could add MVIKotlin (and other libraries) in a separate branch, or maybe in a fork, or something like that.

[malliaridis]

I like the idea of providing various integrations in separate branches. And if the changes in the commits are kept clean, users will be able to lookup only the differences (e.g. with git diff), allowing them to integrate other libraries at any stage of the project with the help of this template.

[arkivanov]

I have added a CI setup, so that all future PRs are checked.

[malliaridis]

Nicely done. Just a quick question: Is the Java version 17 fine or should that match Java 11 like in the gradle files?

[arkivanov]

That should be fine. It shouldn't be lower than 11, though.