My use case is: I pass a ResolveInfo object to my composable function and load an app name and icon from inside that composable, at the moment it’s super slow

ResolveInfo

is an Android-specific class, so its use should probably be avoided within Composable functions. Furthermore, you really want to keep your composable functions as reusable as possible, which means keeping them as detached from the rest of your application as possible (nothing should be reading from your manifest file, for instance). Instead, architect your dataflow such that the read of any application-specific information is done at the application level (eg. in your activity) and pass any data needed for rendering via platform-independent parameters into your composable function.

Hi, thanks for the pointers, I’ll try to see if I can do that. I initially did all that work (loading an app name and icon) in a viewmodel and just observed the viewmodel inside my composable function. However I also read that Android code should be avoided in viewmodels so that they are 100% unit testable… so I’m a bit confused as to where I should actually do that

The entry point of your application is your Activity, and your activity is inherently Android-specific and inherently tied to your application, so that is a good place to start. As your application grows, you will likely create an entire application-specific backend which is triggered by your activity and is a good place for such things to be managed. Your activity or application-specific backend can freely create simple platform-agnostic data models which can be passed to your composable functions.

all right yeah that makes sense. Thanks a lot