Is it ok to use `@OptIn` annotations in a production app?

# compose

[Gerardo Ernesto Rodriguez Navar]

Is it ok to use @OptIn annotations in a production app?

[Gerardo Ernesto Rodriguez Navar]

Particularly AnimatedVisibility and StickyHeader

[Gerardo Ernesto Rodriguez Navar]

It’s ok if changing in the future the compose version breaks the code and needs to fix it, but will this make crash my app or have a weird behaviour?

[nitrog42]

no crash or weird behavior, it just means as you said that a futur version might require you to change/rewrite code

[Gerardo Ernesto Rodriguez Navar]

Thanks @nitrog42!!!

[gildor]

General note about OptIn, the meaning of OptIn annotation may be very different depending on the case, so it up to author of annotation to mark different APIs with it, or about backward compatibility, or about internal API and of course nobody prevent to mark unstable not tested API, so always check original annotation doc, in this case AnimatedVisibility is annotated with ExperimentalAnimationApi, so in case of compose experimental just means API which may change, but always check what this OptIn is actually doing by checking original annotation RequiresOptIn message

[Gerardo Ernesto Rodriguez Navar]

Thanks @gildor!!!

[Gerardo Ernesto Rodriguez Navar]

Great explanation 😄

[Zach Klippenstein (he/him) [MOD]]

Experimental APIs are generally bad for libraries to use, since they can break consumers if the consumer updates the transitive dependency without updating the library, but fine for apps as long as you’re willing to deal with the potential extra upgrade work.

[Gerardo Ernesto Rodriguez Navar]

Thanks @Zach Klippenstein (he/him) [MOD] 😄