Good thing you noticed. I noticed it too in some cases.

The Initialize task gets created here: https://github.com/MvvmCross/MvvmCross/blob/release/9.2.0/MvvmCross/ViewModels/MvxDefaultViewModelLocator.cs#L170
And then it gets awaited here: https://github.com/MvvmCross/MvvmCross/blob/release/9.2.0/MvvmCross/Navigation/MvxNavigationService.cs#L301

As you can see there is ConfigureAwait(false) that supposes to switch the context. But it only gets switched on inner await. And you have await CreateFilters() that gets awaited. But if there is not any inner await inside your CreateFilters or there are some long running operations before any await then you are still on the main thread. The same goes for await LoadList().

In my case it happened when internet connection was bad on Android and the UI got frozen because in the implementation of HttpClient.GetAsync() there was some long running operation before inner await.

In general, I assume that ConfigureAwait(false) is a bad practice that spreaded much in the C# world, and in MVVM case it is bad to base initialization implementation on it.

My solution was simple. And it is the only right solution if you want to initialize on background:

public override Task Initialize() {
	Task.Run(BackgroundInitialize);
	return Task.CompletedTask;
}

protected virtual Task BackgroundInitialize() {
	return Task.CompletedTask;
}

Here is some good reading about ConfigureAwait(false) problem with samples on GitHub: https://learn.microsoft.com/en-us/archive/blogs/benwilli/an-alternative-to-configureawaitfalse-everywhere

It is still better but it won't save from such a case:

If there is not any await or await after a long operation (the for loop) then it will fail and lag on the main thread until the end of the function.

So I will repeat that the only right way to initialize is to use Task.Run(). You can make your own tests.

Good luck. :)

P.S.: that hack will work but it's bullshit IMO: