I've just started looking at Addressables, literally in the last hour or so. One thing I'm finding it hard to find good info on is how we're meant to deal with the async patterns in practical use cases. It's not obvious to me how they tie into the standard Unity patterns which are mostly synchronous. I'm in the early prototyping stages of a project, and looking for something flexible and fast to work with without too much setup. I thought that it would make sense to swap a Resources.Load<Texture3D>("path") call out for the Addressables system, but it's proving a pain because of the sync/async difference. I'm building most of my logic in plain C# classes so that I can be free to use it from either the legacy MonoBehaviours workflow or from DOTS. I have a plain rendering helper class that builds some command buffers for use on cameras and lights. That helper class needs access to a texture resource. The obvious way to deal with that would be to make my RenderHelper.SetupLightCommandBuffer() methods async, but they need to be able to be called from MB Update methods, so I don't think that's much of an option. The only half decent solution that's coming to mind is to load the texture in the helper class's constructor and just force it to happen synchronously via the Task API. That feels like I'm doing it wrong, although it's basically just what I would be doing with Resources.Load anyway. This one texture will always be loading from the local disk and it isn't too large, so I could probably get away with just loading it synchronously when it's first needed, which will be the first frame of the scene. More generally though, are there any good established patterns for dealing with async resource loading like this? I can envision ways I would go about building whole async level loading systems that await the loading of assets behind a loading screen, but the amount of boilerplate setup for that means it's a bit out of reach for rapid prototype development where I'm just jumping in and out of play mode in one scene.