title: How do duration and UISpringTimingParameters interact in UIViewPropertyAnimator?
body: <p>iOS 10 has a couple of new classes for animating. Notable ones include <a href="https://developer.apple.com/reference/uikit/uiviewpropertyanimator" rel="noreferrer"><code>UIViewPropertyAnimator</code></a> and <a href="https://developer.apple.com/reference/uikit/uispringtimingparameters" rel="noreferrer"><code>UISpringTimingParameters</code></a>. The property animator can be <a href="https://developer.apple.com/reference/uikit/uiviewpropertyanimator/1648362-initwithduration?language=objc" rel="noreferrer">created</a> with a duration and timing parameters - the timing parameters can be an instance of the spring parameters.</p>
  
  <p>One common <a href="https://medium.com/@flyosity/your-spring-animations-are-bad-and-it-s-probably-apple-s-fault-784932e51733#.kkk1xhi2h" rel="noreferrer">complaint</a> about spring animation APIs in iOS in the past is that they require a duration - the duration of a real spring animation should be determined by the spring properties like damping ratio and initial velocity. <code>UISpringTimingParameters</code> can be <a href="https://developer.apple.com/reference/uikit/uispringtimingparameters/1649832-init" rel="noreferrer">created</a> with those kinds of parameters.</p>
  
  <p><b>My question</b>: Does <code>UIViewPropertyAnimator</code> still use the duration you give it when its timing curve is a spring? Or will it discard the duration and use the spring parameters to calculate it? That would be a weird API decision on Apple's part, but it also seems weird to come so close to giving designers what they want (real springs) and yet not quite get there (force specifying a duration).</p>