Designs are created for iOS and don't match Android guidelines, and that also leads to problems

[alwx]

When working on chat top bar (#14315 + #14312) and other components that require blur & transparency, we (together with @flexsurfer) realised that we start experiencing too many issues and spend too much time dealing with that. Those issues are mainly caused by the fact that blur is not really something that people use on Android, it's not part of Android guidelines and it's basically an iOS pattern, which also means there are no good and stable blur implementations for Android.

Some technical details

We use https://github.com/Kureev/react-native-blur, and it seems to be the only maintained react native blur library available. It works fine on iOS (see my PR: #15204) but it has many unresolved issues on Android. Most of them are due to the fact that it uses https://github.com/Dimezis/BlurView underneath, and this library is in fact not too stable — it doesn't seem to support ripple effect on Android and it has different issues on different Android devices.

But that's not the main issue — we probably do have capacity to solve most of the issues if we try hard but the problem is we're not sure if it's worth it because what we're actually doing here is we're implementing iOS patterns and designs for Android, and that seems to be a bigger issue.

Proposal

What we think makes sense to do is either create separate designs for Android or just get rid of transparency on Android completely.

But this issue is mainly to initiate a discussion around this topic.
cc @cammellos @pedro-et @John-44

[flexsurfer]

Thank you @alwx i agree there is a bigger issue, 99% of our user use Android devices (most of them old and slow and have small screens) which means our designs should be first for Android, optimized for small screens, and respecting Android guidelines, so any Android user feels comfy in our app

so far we have these registered issues for Android:

#15346
#15340

but there will be more for sure

also, we should remember that we have big performance limitations (RN, js), and we can implement whatever beautiful and complex design with animations and transitions, blur, etc, but they won't work for 90% of users, they just won't use our app, because it will be slow and laggy

more regarding performance
https://discuss.status.im/t/application-performance-and-ux/1168
https://discuss.status.im/t/the-story-about-100ms/1630
#10383

[pedro-et]

@alwx Let us discuss it within the design team! its quite a nice challenge!

[flexsurfer]

In Android 12, public APIs are available for implementing window-blur effects, such as background blur and blur behind.
https://source.android.com/docs/core/display/window-blurs

[expo-blur][Android] Add support for BlurView on Android
expo/expo#21744

[alwx]

True but the existence of APIs doesn't mean people should use them for navigation bars :)

[flexsurfer]

yeah and it seems like it will be not easy to implement in RN

[OmarBasem]

Thank you @alwx for opening this discussion.

Regarding the chat top bar issue, the animated-header-list component (which you can check in Quo2.0 Preview in-app) is using the same animation and blur view, and it is working on both platforms. I believe the current problem in implementing the chat top bar UI, is implementing this animation for an inverted list. I see the same problems mentioned in the PR videos are still there for iOS. If you believe you can implement this animation for an inverted list without the blur view, you can do so, and I can take care of the blur view in another PR.

Regarding BlurView usage in general, it works a little differently on both platforms. On Android there are a few points that need to be taken into account:

• The BlurView should be used as a background view, not as a parent view.
• It should have a container view (otherwise would cover the whole screen)
• The view on top of it, if it needs transparency, it should use opacity prop and not rgba.

In my experience with BlurView, when doing the above points, it works fine on both platforms.

Away from the BlurView, I agree that in some designs, the Android experience and guidelines should be taken into account.

[flexsurfer]

thanks @OmarBasem there are two issues on Android:

1. i use opacity prop , but still blur color is different

2. Bleeding BlurView on light views

Kureev/react-native-blur#511

[OmarBasem]

@flexsurfer can you please point me to the Figma design and the code file? I will try to look into it.

As for the bleeding colors, it seems to happen under certain conditions as we discussed before. We can try to find what are these conditions and avoid them.

Since we will be targeting Android 12 at minimum as John mentioned yesterday, maybe we can look into this one also: https://source.android.com/docs/core/display/window-blurs

[John-44]

@OmarBasem yes I would definitely suggest focusing on using what can be achieved with https://source.android.com/docs/core/display/window-blurs for all blurs, as this is the native Android way of achieving the blur effects we want to achieve, and it should be well optimised and supported into the future.

Try to get as close to the design as possible using the functionality that https://source.android.com/docs/core/display/window-blurs supports, and don't worry about trying to do anything that https://source.android.com/docs/core/display/window-blurs doesn't support (of course a semi-transparent tinting layer might be required in some cases)