apparently you haven’t understood MVI’s purpose: The point of having observables of user events instead of callbacks that call a ViewModel method is that you can write functions that combine or transform them.

Due to the lifecycle mismatch of the ViewModel and the View, the ViewModel managing subscriptions that originate from the View would be unsafe. If these functions need to be combined or transformed, then the ViewModel can handle that internally, unbound from the View’s lifecycle.

Of course there is the argument of making that “implicit state” in observable transformer functions explicit in order to be able to restore it in case of process death, but at the moment I think that’s hardly worth the effort.

You should try taking pictures more often, apps losing their state is very frustrating 😉 but not all state is equal, in fact, some of them (like “loading” state, or “is network available”) are transient, and should stay transient. Those can easily be hidden inside RxJava.

the use of immutable state ADTs. They can be used to model mutually exclusive states and add type-safety that wouldn’t be possible with MVVM.

You are not prohibited from using sealed classes and a single-object state even with MVVM. I’ve seen various incarnations of LiveData<State> that’s based on this concept, so I didn’t feel it was unique to MVI.

that is the price we pay for simple concurrency.

I like the approach of LiveData in this regard: a variable is thread-safe if it’s only ever accessed from the thread where it was created. Views for example also don’t like being updated from other threads than the UI thread, and that’s worked just fine in numerous GUI solutions.