Hi all, there is some hesitancy on my team to depend on <https://github.com/google/accompanist> give...

# compose

[Tash]

Hi all, there is some hesitancy on my team to depend on https://github.com/google/accompanist given this:

Any of the features available in this group of libraries may become obsolete in the future, at which point they will (probably) become deprecated.

We will aim to provide a migration path (where possible), to whatever supersedes the functionality.

Citing that these migrations/deprecations could become problematic to maintain.

Did anyone run into similar concerns and go with some alternative?

[andrew]

Accompanist really is your best bet

[andrew]

The speed at which things get ported over to upstream compose, is not that fast

[andrew]

The last thing to be done was window insets, the accompanist API can still be used either way, as you migrate things over

[andrew]

The upgrade path for me also is pretty painless, it was pretty much just being one find and replace for most of my things

[andrew]

TLDR: there really is no alternative to accompanist, it comes straight from Google developers, who either work on compose, or know people who work on compose, and it's held to the same standards that you would expect from that respective team

[Tash]

My thoughts exactly! Thanks for confirming, Andrew 😅

[Colton Idle]

Also, the best recent example of this was accompanist-inset was deprecated...

but it was added to compose/android directly. And they provided a migration path to move over. 👌

[andrew]

Exactly like I said, painless

[saket]

I also can't help but think that this line can be said for any library:

Any of the features available in this group of libraries may become obsolete in the future, at which point they will (probably) become deprecated.

[Zoltan Demant]

If you have a design system you can make adjustments in there if/when things get deprecated, instead of plowing through the projects "actual" codebase 🙂

[Tash]

Thanks for the replies all, the team is convinced 🙌🏼