Compose was built to solve some pain points that the Android developers had been facing since many years. Let's look at what some of those were: UI is tied to the Operating System The first reason is that the current UI toolkit is tied to the Android Operating System. What this means is that if we the Android team made some new improvements in the View system or as an example the View.java file, we will have to wait for an Android API release to get these improvements. It's not a simple library that I can just bump up to get these latest improvements & changes. Unbundling the view system from the OS would make it easier to quickly fix bugs and bring improvements in a backward compatible way. State Management is tricky The way we managed UI state has always been this complicated dance that we have to do as views store own their own state. And we need to make sure that the state that we store in our view models and presenters is in sync with the state inside of the views. For example, if my business logic requires me to hide a view, that logic is stored in some view model or presenter and then as a reaction to that requirement, I need to get hold of the view I need to hide and explicitly change it's visibility by calling the setVisibility method on the view, which in turn changes the internal state of the view. Now this is really error prone and majority of the bugs in our apps stem from state management. So there has to be a better way. Lots of Context Switching Let's talk about the average workflow of an Android developer. We typically create views in xml, then create our screens which have lifecycles in them using Kotlin/Java. We then reference the views that we originally created in xml using id's/tags and then update its state. When we need to reference styles & dimensions, we again store them in xml. This constant context switching definitely has some impact or our productivity and we've come to accept this unfortunately. Now some folks might say that isn't it good that all the UI is in xml files and all business logic in Kotlin files. Decoupling is supposed to be good after all. Well, it's true that decoupling is a good engineering practice but this is not really decoupling because you are still referencing these xml files in your Kotlin code and making modification to it. So even though you might think that xml is decoupled and your UI code is decoupled, in reality it's just an illusion. Simple things still require a lot of code We are used to writing a lot of code for even doing simple things. We just spoke about the normal workflow where we are making changes across so many files. Even outside of that, we have so many moving pieces that we need to take care of for writing UI code. Want to make a simple list, you create an adapter first, make sure that it extends the right class, override the relevant methods, If your list supports types of views items, then you override an additional method to pass the relevant layout xml file. So there's a lot of boilerplate code that we have to write for even doing simple things. The most effective way to reduce the number of bugs is to reduce the amount of code that we write.