Skip to content

Conversation

ASalavei
Copy link

@ASalavei ASalavei commented Sep 1, 2025

Implement enter end exit animation for Dialog that matches the latest Android animation.

Animation
Android:

Screen.Recording.2025-09-01.at.16.03.32.mov

iOS:

Simulator.Screen.Recording.-.iPhone.16.-.2025-09-01.at.15.57.56.mp4

Desktop:

Screen.Recording.2025-09-01.at.15.59.01.mov

Fixes https://youtrack.jetbrains.com/issue/CMP-4365/iOS-iOS-Dialog-has-no-enter-and-exit-animation

Release Notes

Features - Multiple Platforms

  • Implement enter end exit animation for Dialog

@ASalavei ASalavei changed the title Andrei.salavei/animate dialog appearance Implement enter end exit animation for Dialog Sep 1, 2025
@m-sasha
Copy link
Member

m-sasha commented Sep 1, 2025

I'm not sure this is a good idea, in several aspects:

  1. Dialog feels like a fairly low-level API (it's in ui). Should it even have an animation? That feels like it should be added at a higher-level API.
  2. Should the animation be hardcoded, without allowing customization by anyone? On Android, is the animation also hardcoded, or is it a native dialog, with system/vendor-specific animation?
  3. Should the animation be the same on all platforms? Should it be the one Android uses?

@ApoloApps
Copy link

Customization is key! There should be a default value trying to mimic platform behaviour (per Os and platform like IOS, MacOs, Windows, etc) but it should still be customizable on dev's side

@ASalavei ASalavei marked this pull request as draft September 2, 2025 07:05
@ASalavei
Copy link
Author

ASalavei commented Sep 2, 2025

@m-sasha , thanks for the feedback. If you have any ideas how to organize the API, please let me know.

Dialog feels like a fairly low-level API (it's in ui). Should it even have an animation? That feels like it should be added at a higher-level API.

As animation is a behaviour defined by the platform itself, it seems reasonable to define the basic animation in the 'ui' module. However, there are caveats, which I will explain further in the text.

Should the animation be hardcoded, without allowing customization by anyone?

It's good that you raised this question. To answer it, we must consider that a Popup is not equivalent to an Alert Dialog (or UIAlertController on iOS) — it can be used for a much wider range of use-cases. For this reason, I don't think we need to copy all the Alert Dialog animation variations for all the platforms and their various versions. It's much better to add a common wrapper around the system controls to have the native alerts than to mimic their behaviour.
However, I think the animation customisation API could be useful. Please take a look at the new public API that I added.

On Android, is the animation also hardcoded, or is it a native dialog, with system/vendor-specific animation?

On Android they are using Compose code to draw the Dialog's content and platform-provided scrim/appearance animations.

Should the animation be the same on all platforms?

I don't have a strong opinion on that; it's a question for the designers. What I am sure about is that we should not blindly copy the alert animation as the dialog animation.

Should it be the one Android uses?

Until we have design opinion, I'd go with the one used on Android.

@ASalavei
Copy link
Author

ASalavei commented Sep 2, 2025

@ApoloApps , please read my comment to @m-sasha .

Dialogs can also be used for UI like this. I don't think they should have the same animation as alerts.

*/
@ExperimentalComposeUiApi
@Immutable
interface DialogAnimationScope {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea to introduce such API not in commonMain. My suggestion: introduce android-like animation for now in fork, but do NOT introduce such API for configuring in skikoMain. Instead we can start the thread with Google folks to add this in common in future.

We can still add another boolean flag to DialogProperties just to disable animation for compatibility purposes


/**
* The default scrim opacity.
*/
private const val DefaultScrimOpacity = 0.6f
private const val DefaultScrimOpacity = 0.78f
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert default value here - it's picked from Android OS sources. It should be the same by default across the platforms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants