This might have been answered before, but given the current need for a successful build in order to have a working preview, does it worry you guys that Compose may become unsustainable in larger apps that have a build time greater than one minute? Is anything in the works so that something like a "real-time pre-build" sort of thing allows for a reasonable fidelity preview or something else?

yes, for sure build times are top of mind for lots of folks over here and there are a number of things that are being worked on in this vain. I don’t think there are any silver bullets here, but there are a few things in the works that will be helpful

You only need to build the current module to get the preview though, right? So after the first build, once all the dependencies have been built and cached, as long as your module compiles relatively quickly this shouldn’t be too bad, I would hope.

yes, but we can do better

SwiftUI-like instant rendering would be amazing 😅

it’s important to note that that only works with constant literals, but yes, we are planning on doing something similar in these cases

Well, potentially build more than one module if you're composing components scattered around modules. IIRC, building a module will trigger a rebuild of other modules that depend on it (which is plausible for an ui-components sort of module). The mileage may vary, but in my experience modularization can still have relatively long rebuild times, enough to make something like building a UI, that requires a decent amount of tinkering, quite a tedious effort

In general there are a lot of avenues to improve dev experience here. Some that i know can help are below. Some of these I know we are working on already, but not all of them (yet?): 1. improving actual kotlin compiler speeds. there’s an entire team at google working on this in addition to jetbrains folks. There’s a new frontend that has shown some promising results here. 2. Improving compose plugin times. There’s some low hanging fruit here that should provide big wins as we haven’t optimized it at all yet. 3. gradle currently invalidates artifacts based on hashes of the results of their dependencies artifacts changing. This can be made smarter and only invalidate on public api changing. 4. for emulator, reducing time to hot swap and install app 5. improving the time it takes for gradle to check tasks for updates. this is problematic because of gradle’s model, but there might be some leeway we can make when running in a daemon and IDE only detects certain files changing. 6. incremental compilation for kotlin. This works already for example in JPS but not in gradle currently, but doesn’t seem to be any fundamental reason why it doesn’t. just needs to be wired up. 7. skip compilation entirely for changes to literal values in compose projects and just send update directly to the runtime. This is equivalent to the “instant rendering” zach was talking about with swift UI. 8. use kotlin compiler daemon and host it in the same process that the preview is running and use a dynamic class loader to swap classes and then recompose UI after changes. 9. tweak compose compiler code generation to produce more durable tree generation such that we could hot-swap refactored kotlin code and the bulk of the ui could recompose instead of being completely torn down and rebuilt every time. This is similar to “hot reloading” in react for example.

That was a great answer, in fact I've come across a few things you mentioned (most of kotlin and gradle related issues). I see Compose needs a huge heap of work done since an UI framework for android is a huge deal, specially considering its long way until now. I have zero experience with contributing to Google repos or AOSP, but Compose is really something I'd like to lend a hand on, if it's possible.

yeah, this particular area (build+dev tooling) is probably one of the harder areas to contribute externally as it requires a lot of coordination and consensus across teams and separate products