Support Compose Multiplatform

[Nek-12]

Compose Multiplatform landed resources (including multi-module) support in this release. As such, it should be possible now to support compose multiplatform, and as a consequence, wasm, ios and desktop targets.

[mikepenz]

That is a great suggestion. I have not looked into the font rendering support of KMP recently. But I would be eager to add and expand support for it if possible.

[mikepenz]

Also happy to take PRs related to this

[Nek-12]

I can't promise a PR, but we're migrating to CMP right now and I may take some time to fiddle with iconics and see whether I am able to run it with CMP.

[mikepenz]

No worries. Eager to hear what you find

[mikepenz]

As it's been a while I've went through the pain and upgrade all dependencies and gradle (including Kotlin 2)
While this does not yet enable multiplatform support, it should at least make it simpler to test.

Still need to find time at some point to completely redo the build set-up for this project 🙃

[Nek-12]

I took a look at the library code, and my findings, in summary, are:

1. The core module is extremely android SDK-oriented. Core module does not contain much of an api. Instead, it defines the logic to create the platform SDK drawables that "are" icons.
2. The compose module is a simple two-file wrapper around a drawable, exposed as a painter. This means that 80% of the code is delegated to the platform APIs.
3. Iconics relies on obscure platform APIs for initialization and a global singleton to manage icon registries. While a valid solution for the XML world, compose offers LocalComposition APIs that operate under a different paradigm.

In order to port the library to compose multiplatform, a huge amount of breaking changes is required, with a re-implementation of the API and interfaces, untying the library from the platform code, changing the initialization logic, creating new modules and designing a new API layer that does not rely on any of the android.graphics APIs. In the process, a significant amount of existing functionality will be lost or would take time to re-implement for little to no benefit, given that the library has not been very actively developed and/or used lately.

Our decision was unfortunately to develop an in-house solution that is specifically tailored to CMP and our needs, as porting iconics would be a far greater ordeal than migrating our whole project to a new composable Icon function. According to my research, rendering icons as a font at the minimum number of functionality that we require (letting users choose their own icons) should not take a significant amount of code to implement. We may consider opensourcing our solution.

I am going to close this issue for now as judging by the conversation, without additional interest, no CMP support will be planned. Feel free to reopen as needed.