If I can tie the business logic component to the lifecycle of the ui and keep the bloc around till the ui is definitely done with it (that's what the ViewModel does on Android and that's behavior that can be simulated on iOS, although I'm not quite happy with my solution there yet), then the only reason to save/restore ui state "manually" is to survive a process death. If I understand your approach correctly, a component in Decompose is destroyed and recreated upon configuration change but state can be retained if needed and that's what you use the StateKeeper / InstanceKeeper for (although only state stored in the StateKeeper would survive a process death right?). Retaining the bloc itself seems simpler, especially if it happens under the hood (that's what this article is about).

I applaud your effort to offer an API for state retention on Android and iOS but it's a lot of work for an edge case (process death) on a single platform. My goal was to create a _simple_ framework and in the context of this discussion that means solving the retention problem for configuration changes (more or less transparently) for the user of the framework. I do consider adding the StateKeeper to the BlocContext, to give the user the choice whether they want to cover the process death case or not. I initially had it there but it added quite a bit of complexity when creating a bloc from a ViewModel so I removed it.

Before I re-add the StateKeeper, I want to think about an aspect of ui frameworks that most of them neglect. The ones I researched focus on the business logic part while the state management / container part is an afterthought (Redux might be the exception). For me it's ok to keep some state in the view itself especially with the declarative uis gaining traction on all platforms. Some state is more transactional (see e.g. https://medium.com/androiddevelopers/viewmodel-one-off-event-antipatterns-16a1da869b95) and should be kept at least on a bloc level. Some state is even more important and should be stored in some persistent storage and then we have global ui state (navigation?) which could reside in a global store (Redux store e.g.).

That said there are probably more categories and this certainly also blurs the separation between ui state and domain data but my point is that this still needs some thinking. It's my goal to work on exactly that aspect of the framework. Where does the process death case fit in here? I don't know yet and the StateKeeper might be the answer or not.

Sorry for my ramblings. Now I'm done ;-).