UISpringTimingParameters should be able to infer the settling duration as CASpringAnimation does

Originator:david.ronnqvist
Number:rdar://32846880 Date Originated:June 19 2017
Status:Open Resolved:
Product:iOS + SDK Product Version:
Classification: Reproducible:
 
Area:
UIKit

Summary:
When using CASpringAnimation it is possible to get set the `duration` to be the `settlingDuration` to get a natural looking animation that takes as long as it needs to settle. This is great for animations where the distance and initial velocity depends on user interaction. A shorter distance, more stationary animation can take less time than a longer distance, high velocity animation would, and both look good.

However, the `CASpringAnimation` API is less convenient to use than the `UIViewPropertyAnimator` with `UISpringTimingParameters` API is. Especially when the initial velocity has a direction with both x and y components (which would require two separate `CASpringAnimation` animations.

Sometimes it is favorable to specify a fixed time duration for a spring animation, but other times it looks more natural to have a variable duration that depends on the time it takes for the spring to settle.

For this scenario, it would be good if a `UIViewPropertyAnimator` could be initialized with a `UISpringTimingParameters` _without_ having to specify a `duration`, allowing the property animator to calculate/use the spring's settling duration as the animation duration.

Such an initializer (or factory method) should make it clear in the name that the duration is inferred from the springs settling duration, and only accept `UISpringTimingParameters` as it's argument.

Steps to Reproduce:
Not applicable

Expected Results:
Not applicable

Observed Results:
Not applicable

Version:
iOS 11 ß1

Notes:


Configuration:

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!