Imagine a future where everyone is wearing “AR glasses”, and digital content isn’t limited to screens. Would that future look like this?

Nathan Gitter on Twitter

Imagining future AR interactions with wearables. 😎⌚️ Using #ARKit image detection to recognize images displayed on an Apple Watch, showing more information in AR. Built with #ARKit2 on #iOS12. https://t.co/2PETNbRO3Q

Maybe. It raises some questions:

1. If we can display content next to the watch, does the watch need a screen?
2. Do we need a physical watch at all?
3. How would a user interact with the content? Voice commands? Hand gestures?

Prototyping the Future

These are good questions to ask and help us solve future UX problems. By materializing an idea as a prototype, we can experience it firsthand and explore possible improvements.

I built five prototypes using image tracking in ARKit 2, and would like to share what I’ve learned. Hopefully the following concepts help you design better AR experiences.

Concept #1: Screen Space vs World Space

When designing phone-based AR experiences, we need to think about where we place visual elements—should they be placed “on the screen” or “in the world”?

Here’s my prototype of a potential future shopping experience, where physical packaging comes to life in AR.

Nathan Gitter on Twitter

Image tracking in #ARKit2. So many potential applications! https://t.co/tSrpupjIXU

The video of the rotating AirPods is placed in the world, fixed to the position of the box. It’s placed in world space. The buttons at the bottom are placed on the screen, unmoving even when the camera moves. They’re placed in screen space.

Generally, visual elements should be placed in world space when they act like real objects, and should be placed in screen space for easy reading or control.

The Measure app on iOS 12 does a great job of finding the right balance between screen space and world space. The measurements are always in screen space, rotated to match the lines, and can transition to a larger, expanded format when tapped.

Concept #2: Setup Costs

AR has the ability to bring static media to life. In this prototype, I added videos on top of a print newspaper to make it more engaging.

Nathan Gitter on Twitter

Bringing newspapers to life with #ARKit. 📰📱 Animated weather maps and sports highlights are just the beginning! Built with #ARKit2 on #iOS12. https://t.co/JVth2FQCFw

The experience feels magical—straight out of Harry Potter. 🧙‍♂️

However, it suffers from the high setup costs of current AR apps. In order for a user to have this experience with a newspaper, they need to switch contexts, turning their attention from the newspaper to their phone.

On top of this context switch, they need to:

1. Download the app.
2. Launch it.
3. Allow camera access.
4. Physically move to position the camera or initialize AR.

These added steps dictate that AR content should be as meaningful and useful as possible. A newspaper with a special section explaining a concept in AR would be more compelling than a passive layer over the reading experience, and therefore more likely to motivate users to overcome the high setup cost.

Concept #3: Real World Context

AR content can be more compelling when it’s directly augmenting what the user is already experiencing.

This prototype identifies key figures in historical artwork, allowing the viewer to learn more about the paintings.

Nathan Gitter on Twitter

Exploring paintings in AR! 🖼📱 Look at artwork to identify key figures, and tap them to learn more. Built with #ARKit on #iOS12. #ARKit2 #AugmentedReality https://t.co/1pgSEr0iW4

By highlighting the key figures in world space, the user continues to view the painting while learning more about it. The user is already physically viewing the painting—the app enhances their current experience.

Instead of switching contexts between a museum brochure (or a museum brochure app) and the painting, AR delivers additional information seamlessly.

Concept #4: Interaction Models

In this prototype, the user is able to see into the past. Artwork in this public graffiti park is constantly covered up, but this app lets the user peel back layers of paint to reveal past artwork.

Nathan Gitter on Twitter

Time travel in AR! ⏳✈️ The artwork in this public graffiti park changes daily. With the power of #ARKit, it's possible to see into the past. Built with #ARKit2 on #iOS12. https://t.co/APa2Nj8jdC

The user can navigate forward or backward in time by tapping on the left or right sides of the screen. While great for demo purposes, without a prompt, the user experience is difficult.

Here are a few alternative interactions:

1. Provide explicit controls in screen space similar to scrubbing through a video.
2. Use gestures to directly manipulate the position of the images in world space, swiping left and right between them.
3. Determine the image to show based on the relative camera angle, similar to a lenticular print.

The best option for an AR interaction model depends a lot on the user’s context. In this case, the ground is rough and uneven, which might make it difficult to move around while looking through the camera. Direct manipulation might not make sense if the images of the artwork don’t align precisely.

Because the experience varies so much on the particular use case, it’s important to prototype early and often to determine the best interaction model. Oftentimes you won’t know what works best until you try it.

Concept #5: The Future

Until AR headsets are widely adopted, most AR applications will be experienced via mobile devices. While there are a lot of current constraints, it can be valuable to think about future possibilities.

Here’s the prototype from the beginning of this post, allowing watch apps to display more information in AR.

Nathan Gitter on Twitter

Imagining future AR interactions with wearables. 😎⌚️ Using #ARKit image detection to recognize images displayed on an Apple Watch, showing more information in AR. Built with #ARKit2 on #iOS12. https://t.co/2PETNbRO3Q

This is not currently practical—holding a phone to look at another screen doesn’t work too well.

However, exploring one step further than current technology can lead to new ideas today. What if we could use the digital crown on an Apple Watch to control some other kind of AR experience, or use haptic feedback to provide additional information about the surrounding world?

The Power of Prototypes

My goal with these prototypes is to clearly show others the potential of augmented reality. AR has an incredible number of use cases beyond placing virtual IKEA furniture in your living room.

Prototypes are powerful because they inspire. They should feel like a glimpse into tomorrow. They should set an aspirational goal—a vision for the future.

Takeaways

1. Consider which elements live in screen space versus world space.
2. Make your content compelling—AR apps have additional setup costs.
3. Augment the user’s current real-world context.
4. Think through various interaction models—prototype whenever possible.
5. Imagine future possibilities—it will be here sooner than you think.

Additional Resources

If you want to learn more about AR design (and specifically designing ARKit apps), I highly recommend these resources:

1. WWDC18 Presentation “Creating Great AR Experiences”
2. WWDC18 Presentation “Prototyping for AR”
3. Apple’s Human Interface Guidelines

If you enjoyed this post, please leave some claps. 👏👏👏

You can clap up to 50 times, so get clicking/tapping! 😉

If you like this kind of stuff, you should follow me on Twitter. I only post high-quality tweets. twitter.com/nathangitter

Thanks to David Okun for revising drafts of this post.

At WWDC 2018, Apple designers presented a talk titled “Designing Fluid Interfaces”, explaining the design reasoning behind the gestural interface of iPhone X.

It’s my favorite WWDC talk ever—I highly recommend it.

The talk provided some technical guidance, which is exceptional for a design presentation, but it was pseudo-code, leaving a lot of unknowns.

If you try implement these ideas, you might notice a gap between inspiration and implementation.

My goal is to bridge this gap by providing working code examples of every major topic in the presentation.

Here’s an outline of what we’ll cover:

1. A brief summary of the “Designing Fluid Interfaces” talk.
2. Eight fluid interfaces, the design theory behind them, and the code to build them.
3. Applications for designers and developers.

What are fluid interfaces?

A fluid interface might also be called “fast”, “smooth”, “natural”, or “magical”. It’s a frictionless experience that just feels “right”.

The WWDC presentation talks about fluid interfaces as “an extension of your mind” and “an extension of the natural world”. An interface is fluid when it behaves according to the way people think, not the way machines think.

What makes them fluid?

Fluid interfaces are responsive, interruptible, and redirectable. Here’s an example of the swipe-to-go-home gesture on iPhone X:

The interface immediately reacts to the user’s input, can be stopped at any point in the process, and can even change course midway.

Why do we care about fluid interfaces?

1. Fluid interfaces improve the user’s experience, making every interaction feel quick, lightweight, and meaningful.
2. They give the user a feeling of control, which builds trust with your app and your brand.
3. They are hard to build. A fluid interface is difficult to copy and can be a competitive advantage.

The Interfaces

For the remainder of this post, I will show you how to build eight (8) interfaces which cover all the major topics in the presentation.

Interface #1: Calculator Button

This is a button that mimics the behavior of buttons in the iOS calculator app.

Key Features

1. Highlights instantly on touch.
2. Can be tapped rapidly even when mid-animation.
3. User can touch down and drag outside of the button to cancel the tap.
4. User can touch down, drag outside, drag back in, and confirm the tap.

Design Theory

We want buttons that feel responsive, acknowledging to the user that they are functional. In addition, we want the action to be cancellable if the user decides against their action after they touched down. This allows users to make quicker decisions since they can perform actions in parallel with thought.

Critical Code

The first step to create this button is to use a UIControl subclass, not a UIButton subclass. A UIButton would work fine, but since we are customizing the interaction, we won’t need any of its features.

CalculatorButton: UIControl {
    public var value: Int = 0 {
        didSet { label.text = “\(value)” }
    }
    private lazy var label: UILabel = { ... }()
}

Next, we will use UIControlEvents to assign functions to the various touch interactions.

addTarget(self, action: #selector(touchDown), for: [.touchDown, .touchDragEnter])

addTarget(self, action: #selector(touchUp), for: [.touchUpInside, .touchDragExit, .touchCancel])

We group the touchDown and touchDragEnter events into a single “event” called touchDown , and we can group the touchUpInside, touchDragExit, and touchCancel events into a single event called touchUp.

(For a description of all availableUIControlEvents, check out the documentation.)

This gives us two functions to handle the animations.

private var animator = UIViewPropertyAnimator()

@objc private func touchDown() {
    animator.stopAnimation(true)
    backgroundColor = highlightedColor
}

@objc private func touchUp() {
    animator = UIViewPropertyAnimator(duration: 0.5, curve: .easeOut, animations: {
        self.backgroundColor = self.normalColor
    })
    animator.startAnimation()
}

On touchDown, we cancel the existing animation if needed, and instantly set the color to the highlighted color (in this case a light gray).

On touchUp, we create a new animator and start the animation. Using a UIViewPropertyAnimator makes it easy to cancel the highlight animation.

(Side note: This is not the exact behavior of the buttons in the iOS calculator app, which allow a touch that began in a different button to activate it if the touch was dragged inside the button. In most cases, a button like the one I created here is the intended behavior for iOS buttons.)

Interface #2: Spring Animations

This interface shows how a spring animation can be created by specifying a “damping” (bounciness) and “response” (speed).

Key Features

1. Uses “design-friendly” parameters.
2. No concept of animation duration.
3. Easily interruptible.

Design Theory

Springs make great animation models because of their speed and natural appearance. A spring animation starts incredibly quickly, spending most of its time gradually approaching its final state. This is perfect for creating interfaces that feel responsive—they spring to life!

A few additional reminders when designing spring animations:

1. Springs don’t have to be springy. Using a damping value of 1 will create an animation that slowly comes to rest without any bounciness. Most animations should use a damping value of 1.
2. Try to avoid thinking about duration. In theory, a spring never fully comes to rest, and forcing a duration on the spring can cause it to feel unnatural. Instead, play with the damping and response values until it feels right.
3. Interruption is critical. Because springs spend so much of their time close to their final value, users may think the animation has completed and will try to interact with it again.

Critical Code

In UIKit, we can create a spring animation with a UIViewPropertyAnimator and a UISpringTimingParameters object. Unfortunately, there is no initializer that just takes a damping and response. The closest we can get is the UISpringTimingParameters initializer that takes a mass, stiffness, damping, and initial velocity.

UISpringTimingParameters(mass: CGFloat, stiffness: CGFloat, damping: CGFloat, initialVelocity: CGVector)

We would like to create a convenience initializer that takes a damping and response, and maps it to the required mass, stiffness, and damping.

With a little bit of physics, we can derive the equations we need:

With this result, we can create our own UISpringTimingParameters with exactly the parameters we desire.

extension UISpringTimingParameters {
    convenience init(damping: CGFloat, response: CGFloat, initialVelocity: CGVector = .zero) {
        let stiffness = pow(2 * .pi / response, 2)
        let damp = 4 * .pi * damping / response
        self.init(mass: 1, stiffness: stiffness, damping: damp, initialVelocity: initialVelocity)
    }
}

This is how we will specify spring animations for all other interfaces.

The Physics Behind Spring Animations

Want to go deeper on spring animations? Check out this incredible post by Christian Schnorr: Demystifying UIKit Spring Animations.

After reading his post, spring animations finally clicked for me. Huge shout-out to Christian for helping me understand the math behind these animations and for teaching me how to solve second-order differential equations.

Interface #3: Flashlight Button

Another button, but with much different behavior. This mimics the behavior of the flashlight button on the lock screen of iPhone X.

Key Features

1. Requires an intentional gesture with 3D touch.
2. Bounciness hints at the required gesture.
3. Haptic feedback confirms activation.

Design Theory

Apple wanted to create a button that was easily and quickly accessible, but couldn’t be triggered accidentally. Requiring force pressure to activate the flashlight is a great choice, but lacks affordance and feedback.

In order to solve those problems, the button is springy and grows as the user applies force, hinting at the required gesture. In addition, there are two separate vibrations of haptic feedback: one when the required amount of force is applied, and another when the button activates as the force is reduced. These haptics mimic the behavior of a physical button.

Critical Code

To measure the amount of force being applied to the button, we can use the UITouch object provided in touch events.

override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {
    super.touchesMoved(touches, with: event)
    guard let touch = touches.first else { return }
    let force = touch.force / touch.maximumPossibleForce
    let scale = 1 + (maxWidth / minWidth - 1) * force
    transform = CGAffineTransform(scaleX: scale, y: scale)
}

We calculate a scale transform based on the current force, so that the button grows with increasing pressure.

Since the button could be pressed but not yet activated, we need to keep track of the button’s current state.

enum ForceState {
    case reset, activated, confirmed
}

private let resetForce: CGFloat = 0.4
private let activationForce: CGFloat = 0.5
private let confirmationForce: CGFloat = 0.49

Having the confirmation force be slightly lower than the activation force prevents the user from rapidly activating and de-activating the button by quickly crossing the force threshold.

For haptic feedback, we can use UIKit’s feedback generators.

private let activationFeedbackGenerator = UIImpactFeedbackGenerator(style: .light)

private let confirmationFeedbackGenerator = UIImpactFeedbackGenerator(style: .medium)

Finally, for the bouncy animations, we can use a UIViewPropertyAnimator with the custom UISpringTimingParameters initializers we created before.

let params = UISpringTimingParameters(damping: 0.4, response: 0.2)
let animator = UIViewPropertyAnimator(duration: 0, timingParameters: params)
animator.addAnimations {
    self.transform = CGAffineTransform(scaleX: 1, y: 1)
    self.backgroundColor = self.isOn ? self.onColor : self.offColor
}
animator.startAnimation()

Interface #4: Rubberbanding

Rubberbanding occurs when a view resists movement. An example is when a scrolling view reaches the end of its content.

Key Features

1. Interface is always responsive, even when an action is invalid.
2. De-synced touch tracking indicates a boundary.
3. Amount of motion lessens further from the boundary.

Design Theory

Rubberbanding is a great way to communicate invalid actions while still giving the user a sense of control. It softly indicates a boundary, pulling them back into a valid state.

Critical Code

Luckily, rubberbanding is straightforward to implement.

offset = pow(offset, 0.7)

By using an exponent between 0 and 1, the view’s offset is moved less the further it is away from its resting position. Use a larger exponent for less movement and a smaller exponent for more movement.

For a little more context, this code is usually implemented in a UIPanGestureRecognizer callback whenever the touch moves. The offset can be calculated with the delta between the current and original touch locations, and the offset can be applied with a translation transform.

var offset = touchPoint.y - originalTouchPoint.y
offset = offset > 0 ? pow(offset, 0.7) : -pow(-offset, 0.7)
view.transform = CGAffineTransform(translationX: 0, y: offset)

Note: This is not how Apple performs rubberbanding with elements like scroll views. I like this method because of its simplicity, but there are more complex functions for different behaviors.

Interface #5: Acceleration Pausing

To view the app switcher on iPhone X, the user swipes up from the bottom of the screen and pauses midway. This interface re-creates this behavior.

Key Features

1. Pause is calculated based on the gesture’s acceleration.
2. Faster stopping results in a faster response.
3. No timers.

Design Theory

Fluid interfaces should be fast. A delay from a timer, even if short, can make an interface feel sluggish.

This interface is particularly cool because its reaction time is based on the user’s motion. If they quickly pause, the interface quickly responds. If they slowly pause, it slowly responds.

Critical Code

In order to measure acceleration, we can track the most recent values of the pan gesture’s velocity.

private var velocities = [CGFloat]()
private func track(velocity: CGFloat) {
    if velocities.count < numberOfVelocities {
        velocities.append(velocity)
    } else {
        velocities = Array(velocities.dropFirst())
        velocities.append(velocity)
    }
}

This code updates the velocities array to always have the last seven velocities, which are used to calculate the acceleration.

To determine if the acceleration is great enough, we can measure the difference between the first velocity in our array against the current velocity.

if abs(velocity) > 100 || abs(offset) < 50 { return }
let ratio = abs(firstRecordedVelocity - velocity) / abs(firstRecordedVelocity)
if ratio > 0.9 {
    pauseLabel.alpha = 1
    feedbackGenerator.impactOccurred()
    hasPaused = true
}

We also check to make sure that the motion has a minimum displacement and velocity. If the gesture has lost more than 90% of its velocity, we consider it to be paused.

My implementation is not perfect. In my testing it seems to work pretty well, but there is an opportunity for a better heuristic to measure acceleration.

Interface #6: Rewarding Momentum

A drawer with open and closed states that has bounciness based on the velocity of the gesture.

Key Features

1. Tapping the drawer opens it without bounciness.
2. Flicking the drawer opens it with bounciness.
3. Interactive, interruptible, and reversible.

Design Theory

This drawer shows the concept of rewarding momentum. When the user swipes a view with velocity, it’s much more satisfying to animate the view with bounciness. This makes the interface feel alive and fun.

When the drawer is tapped, it animates without bounciness, which feels appropriate, since a tap has no momentum in a particular direction.

When designing custom interactions, it’s important to remember that interfaces can have different animations for different interactions.

Critical Code

To simplify the logic of tapping versus panning, we can use a custom gesture recognizer subclass that immediately enters the began state on touch down.

class InstantPanGestureRecognizer: UIPanGestureRecognizer {
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesBegan(touches, with: event)
        self.state = .began
    }
}

This also allows the user to tap on the drawer during its motion to pause it, similar to tapping on a scroll view that’s currently scrolling. To handle taps, we can check if the velocity is zero when the gesture ends and continue the animation.

if yVelocity == 0 {
    animator.continueAnimation(withTimingParameters: nil, durationFactor: 0)
}

To handle a gesture with velocity, we first need to calculate its velocity relative to the total remaining displacement.

let fractionRemaining = 1 - animator.fractionComplete
let distanceRemaining = fractionRemaining * closedTransform.ty
if distanceRemaining == 0 {
    animator.continueAnimation(withTimingParameters: nil, durationFactor: 0)
    break
}
let relativeVelocity = abs(yVelocity) / distanceRemaining

We can use this relative velocity to continue the animation with the timing parameters that include a little bit of bounciness.

let timingParameters = UISpringTimingParameters(damping: 0.8, response: 0.3, initialVelocity: CGVector(dx: relativeVelocity, dy: relativeVelocity))

let newDuration = UIViewPropertyAnimator(duration: 0, timingParameters: timingParameters).duration

let durationFactor = CGFloat(newDuration / animator.duration)

animator.continueAnimation(withTimingParameters: timingParameters, durationFactor: durationFactor)

Here we are creating a new UIViewPropertyAnimator to calculate the time the animation should take so we can provide the correct durationFactor when continuing the animation.

There are more complexities related to reversing the animation that I am not going to cover here. If you want to learn more, I wrote a full tutorial for this component: Building Better iOS App Animations.

Interface #7: FaceTime PiP

A re-creation of the picture-in-picture UI of the iOS FaceTime app.

Key Features

1. Lightweight, airy interaction.
2. Projected position is based on UIScrollView's deceleration rate.
3. Continuous animation that respects the gesture’s initial velocity.

Critical Code

Our end goal is to write something like this.

let params = UISpringTimingParameters(damping: 1, response: 0.4, initialVelocity: relativeInitialVelocity)

let animator = UIViewPropertyAnimator(duration: 0, timingParameters: params)

animator.addAnimations {
    self.pipView.center = nearestCornerPosition
}

animator.startAnimation()

We would like to create an animation with an initial velocity that matches the velocity of the pan gesture and animate the pip to the nearest corner.

First, let’s calculate the initial velocity.

To do this, we need to calculate a relative velocity based on the current velocity, current position, and target position.

let relativeInitialVelocity = CGVector(
    dx: relativeVelocity(forVelocity: velocity.x, from: pipView.center.x, to: nearestCornerPosition.x),
    dy: relativeVelocity(forVelocity: velocity.y, from: pipView.center.y, to: nearestCornerPosition.y)
)

func relativeVelocity(forVelocity velocity: CGFloat, from currentValue: CGFloat, to targetValue: CGFloat) -> CGFloat {
    guard currentValue - targetValue != 0 else { return 0 }
    return velocity / (targetValue - currentValue)
}

We can split the velocity into its x and y components and determine the relative velocity for each.

Next, let’s calculate the corner for the PiP to animate to.

In order to make our interface feel natural and lightweight, we are going to project the final position of the PiP based on its current motion. If the PiP were to slide and come to a stop, where would it land?

let decelerationRate = UIScrollView.DecelerationRate.normal.rawValue
let velocity = recognizer.velocity(in: view)
let projectedPosition = CGPoint(
    x: pipView.center.x + project(initialVelocity: velocity.x, decelerationRate: decelerationRate),
    y: pipView.center.y + project(initialVelocity: velocity.y, decelerationRate: decelerationRate)
)
let nearestCornerPosition = nearestCorner(to: projectedPosition)

We can use the deceleration rate of a UIScrollView to calculate this resting position. This is important because it references the user’s muscle memory for scrolling. If a user knows about how far a view scrolls, they can use that previous knowledge to intuitively guess how much force is needed to move the PiP to their desired target.

This deceleration rate is also quite generous, making the interaction feel lightweight—only a small flick is needed to send the PiP flying all the way across the screen.

We can use the projection function provided in the “Designing Fluid Interfaces” talk to calculate the final projected position.

/// Distance traveled after decelerating to zero velocity at a constant rate.
func project(initialVelocity: CGFloat, decelerationRate: CGFloat) -> CGFloat {
    return (initialVelocity / 1000) * decelerationRate / (1 - decelerationRate)
}

The last piece missing is the logic to find the nearest corner based on the projected position. To do this we can loop through all corner positions and find the one with the smallest distance to the projected landing position.

func nearestCorner(to point: CGPoint) -> CGPoint {
    var minDistance = CGFloat.greatestFiniteMagnitude
    var closestPosition = CGPoint.zero
    for position in pipPositions {
        let distance = point.distance(to: position)
        if distance < minDistance {
            closestPosition = position
            minDistance = distance
        }
    }
    return closestPosition
}

To summarize the final implementation: We use UIScrollView's deceleration rate to project the pip’s motion to its final resting position, and calculate the relative velocity to feed it all into UISpringTimingParameters.

Interface #8: Rotation

Applying the concepts from the PiP interface to a rotation animation.

Key Features

1. Uses projection to respect the gesture’s velocity.
2. Always ends in a valid orientation.

Critical Code

The code here is very similar to the previous PiP interface. We will use the same building blocks, except swapping the nearestCorner function for a closestAngle function.

func project(...) { ... }

func relativeVelocity(...) { ... }

func closestAngle(...) { ... }

When it’s time to finally create the UISpringTimingParameters, we are required to use a CGVector for the initial velocity even though our rotation only has one dimension. In any case where the animated property has only one dimension, set the dx value to the desired velocity and set the dy value to zero.

let timingParameters = UISpringTimingParameters(
    damping: 0.8,
    response: 0.4,
    initialVelocity: CGVector(dx: relativeInitialVelocity, dy: 0)
)

Internally the animator will ignore the dy value and use the dx value to create the timing curve.

Try it yourself!

These interfaces are much more fun on a real device. To play with these interfaces yourself, the demo app is available on GitHub.

Practical Applications

For Designers

1. Think about interfaces as fluid mediums of expression, not collections of static elements.
2. Consider animations and gestures early in the design process. Layout tools like Sketch are fantastic, but don’t offer the full expressivity of the device.
3. Prototype with developers. Get design-minded developers to help you prototype animations, gestures, and haptics.

For Developers

1. Apply the tips from these interfaces to your own custom components. Think about how they might be combined in new and interesting ways.
2. Educate your designers about new possibilities. Many are not aware of the full power of 3D touch, haptics, gestures, and spring animations.
3. Prototype with designers. Help them see their designs on a real device, and create tools to help them design more effectively.

If you enjoyed this post, please leave some claps. 👏👏👏

You can clap up to 50 times, so get clicking/tapping! 😉

Please share the post with your iOS designer / iOS developer friends on your social media outlet of choice.

If you like this kind of stuff, you should follow me on Twitter. I only post high-quality tweets. twitter.com/nathangitter

Thanks to David Okun for revising drafts of this post.

The Medium iOS app is a native app with a fake navigation bar and the Product Hunt app is built with React Native.

How do I know? Unless I wrote the code myself or asked the developers who did, I can be confident based on a few simple tests—no jailbreaking required.

Want to learn how it’s done?

Background

In the “early days” of the web, it was easy to learn how any site was built. By viewing the source in a browser, the underlying code could be exposed for anyone to see, remix, and reuse. As the web progresses and frameworks increase the complexity of sites, this is nearly impossible now.

Apps have the same problem, but worse. Apps are compiled, which means the original source code has been translated from a human-friendly format to a computer-friendly format.

While there are tools to de-compile iOS apps, they require a jailbroken device, special tools, and coding expertise. I’m going to share tactics that don’t require any hacker skills—all you need is the app installed on your device.

The Key Idea

Our strategy is simple: push apps to their limits in hopes of breaking them. If we see how they break, we can infer how they work.

We are going to try to answer the following:

1. Is the app native? If not, is it a web view? React Native? PhoneGap? Unity? Some kind of hybrid?
2. What UI elements are being used? Mainly out-of-the-box components or something custom? How are they used to achieve the desired effect?

The Experiments

To gather data, we are going to perform five tests. I will explain how to perform each test, what to look for, and what to conclude from the results.

We will be testing:

1. Button touch states 👆
2. Interactive navigation gestures 🔙
3. VoiceOver 🔊
4. Dynamic type 🔎
5. Airplane mode ✈️

Experiment #1: Button Touch States 👆

A button may seem simple. You tap on it, and something happens. However, not all buttons are created equal.

We are going to test the edge cases of button interaction—the behavior when the user doesn’t simply tap the button.

New iOS developers are often surprised by the complexity of interaction on a UIButton (the default button component on iOS). There are nine events that occur at various points in the interaction.

1. touchDown
2. touchDownRepeat
3. touchDragInside
4. touchDragOutside
5. touchDragEnter
6. touchDragExit
7. touchUpInside
8. touchUpOutside
9. touchCancel

(Learn more about UIControlEvents in the developer documentation.)

Almost all buttons perform an action on touchUpInside (when the user releases their touch inside the bounds of the control). Most buttons have a special state when the user touches down.

The real differentiating factor is how buttons handle the touchDragExit and touchDragEnter events. How do buttons respond when the user touches down on the button, then without lifting their finger, drags outside of the button and then back in?

Standard UIButton's have some common behaviors:

1. The “touch area” when dragging back into the button is larger than the button’s bounds.
2. There is an animation on touchDragEnter and touchDragExit.

However, customized native buttons often lose these default animations.

An Example

Let’s try an example with the Medium app. If you’re reading this on the Medium iOS app, you can follow along at home!

Let’s try this fancy-looking button in the bottom right:

If you tap on the button, then while still holding, move your finger out and back in, you’ll notice the hand icon switching between its light and dark state.

(My next post: “How I growth-hacked my way to 100k claps” 😉)

React Native Buttons

React Native buttons are pretty easy to spot. They often have a slow fade animation, and it’s applied to everything.

React Native apps usually make heavy use of scroll views, which can make this button behavior difficult to test, since dragging the button also scrolls the view.

While on the topic of React Native, another big giveaway is the touch states on “cells”. Traditional table cells apply a solid background color, while React Native cells usually apply a highlight effect similar to their buttons.

Web View Buttons

Of the PhoneGap apps I downloaded to test, ~95% of the buttons had no touch states at all, and the remaining ~5% had a touch down state, but didn’t have any effect when dragging out or back in.

Conclusions from button touch states

It’s important to keep in mind that these button behaviors are easily overridable. Exhibiting a particular behavior does not imply a cause—it’s just a clue in a certain direction.

You’ll have to get a “feel” for buttons over time, but it’s one of the easiest ways to start making educated guesses about how an app is built. (This technique can also be used to determine whether an interactive element is a button or some other kind of control.)

Experiment #2: Interactive navigation gestures 🔙

Since iOS 7, users have been able to navigate to the previous screen by swiping the left edge of the display. This gesture is especially fun because it’s interactive, meaning it can be scrubbed back and forth.

This behavior comes for free when using a standard UINavigationController on iOS. For one reason or another, many apps forgo the standard behavior and end up with a missing, broken, or janky navigation transition.

Let’s try it on the Medium app.

Unlike a standard navigation transition, the Medium app moves the navigation bar with the rest of the screen. Normally the navigation bar stays constant and any labels cross-fade.

Additionally, the dark overlay on the previous screen is much darker in the Medium app, leading me to believe that the transition has been overridden, or more likely, is a totally custom component.

I personally think it looks really good, and understand there are major design and development benefits gained from this approach.

React Native Navigation

From a development perspective, navigation is more difficult in React Native. As a result, React Native apps tend to use custom navigation transitions instead of the standard “push” and “pop” of UINavigationController.

Default modal presentations on iOS are not interactive, and don’t have a scaling effect on the screen that’s re-appearing.

Here’s another example of a custom transition in React Native.

There’s no shadow or dark overlay, but the real giveaway is the animation timing. It’s hard to see in this gif, but after I release my touch, the animation completes much slower than normal.

Just like button touch states, this is something you can get a “feel” for over time by testing many navigation transitions.

Conclusions from interactive navigation gestures

This is one of my favorite tests since it can reveal more about an app than just how the navigation bar works. If the gesture breaks an app, it’s possible to learn about more than just the navigation transition.

However, just like button touch states, navigation transitions can be overridden. In practice, navigation transitions are less likely to be heavily customized since it requires significant development effort.

Experiment #3: VoiceOver 🔊

You want superpowers? VoiceOver will give you superpowers.

VoiceOver is Apple’s version of a screen reader. Meant for low-vision users, this accessibility option reads the user interface aloud.

VoiceOver has another effect we are more interested in: it displays a black box around the currently selected element.

This allows us to break a screen into its parts. Instead of guessing how a screen is built, we can just have VoiceOver tell us! Sometimes it will even read aloud the type of element (“button”, “date picker”, etc).

If you haven’t played with VoiceOver before, it is worth learning. The basics:

1. Drag on the screen to select elements.
2. Double-tap anywhere on the screen to “tap” the selected element.
3. Swipe left and right to quickly jump between elements.

Let’s investigate the Medium app with VoiceOver.

Most of the elements act as expected. VoiceOver simply reads the content of the selection or the name of the element. However, there are a few unusual behaviors.

On the home screen, selecting the title of a post only reads half of the title. First it says, “Color Contrast Crash C”, then selecting the bottom of the title reads “Course for Interface Design”. There must be something custom about the layout of the labels that makes VoiceOver think the title is split into multiple labels, one per line. (My guess is they built a workaround for labels with custom line spacing, which usually requires overriding the attributedString property, and can lead to complications later.)

Selecting the description, we can see the power of VoiceOver to reveal hidden information. To most users, the label only says “There are an estimated 285 million…”. But VoiceOver tells us more: “There are an estimated 285 million people in the world who are visually impaired. This number includes anyone from legally blind to those”. In this case, all that data is stored in the label, but visually cut off.

If you’re lucky, you can use this to access information you otherwise shouldn’t be able to access.

Here’s another fun one. On the “bookmarks” tab, if you have no bookmarks, there is an invisible label. It says “To bookmark stories, tap on the bookmark icon anywhere and it will be added to this list.”

My guess is that a developer quickly hid this label temporarily, with the assumption that it might be shown in the future. (Or maybe I’m just being A/B tested.)

Non-native Apps

VoiceOver works well for web view-based apps as well. If you hear words like “link” or “heading level one”, you’re in a web view.

Additionally, text can be split in various odd ways based on styling (because of its HTML representation), and elements may not be grouped naturally.

Games (built with Unity, SpriteKit, etc) generally do not have any VoiceOver support at all.

Conclusions from VoiceOver

VoiceOver provides the most reliable evidence of any test. It shows the visual bounds of elements, and reads invisible attributes. It’s a treasure trove of data about any screen.

As you use VoiceOver more, you’ll learn the default phrasing for various UI elements, and start to notice when it’s different.

As with any of these tests, VoiceOver is not 100% reliable. All of the VoiceOver text and bounding boxes are configurable by the developer. Apps optimized for VoiceOver tend to display less rich information about how the app works since the developer has fixed issues that cause it to break.

(Pro tip: Setting VoiceOver as your “Accessibility Shortcut” makes it easy to toggle on and off while testing.)

Experiment #4: Dynamic type 🔎

Similar to VoiceOver, dynamic type is an accessibility setting for low-vision users. It modifies the text size throughout the system.

We want to use dynamic type to break layouts. And with the new “Accessibility Sizes” which are absolutely gigantic, this is easier than ever.

Dynamic type can be activated in Settings > Accessibility > Larger Text. This can also be added as a widget to the control center in iOS 11 for easier access.

Unfortunately the Medium app doesn’t support dynamic type, so we are going to use the App Store app instead.

I set the text size to the maximum, and was able to find one broken layout—an advertisement on the search screen.

The clipping text “22K” is pretty great, but it doesn’t reveal too much about the layout, since the layout is adjusted for large type (seen by the elements in a stack instead of being side-by-side).

My favorite part here is the light blue “Ad” button. Instead of a nice rounded rectangle, we get a funky stretched shape.

My guess is that this blue box is drawn as a custom path with a hard-coded radius. Usually controls don’t resize with dynamic type (see the “GET” button as an example), so there’s something custom going on here.

Conclusions from dynamic type

Some apps simply don’t support dynamic type. Even if they do, they might not support the larger accessibility sizes.

When it works, dynamic type can stress-test layouts. Some of this information is viewable already with VoiceOver, but it can help to verify theories. Generally apps that support dynamic type have also tested dynamic type, which reduces the chance of revealing useful information.

Experiment #5: Airplane mode ✈️

Another simple test is to enable Airplane mode. Airplane mode disables Wi-Fi and cellular connection, which causes network requests to immediately fail. By disabling network connections in various situations, we can see how apps break.

In the Medium app, if you load the home page, turn on Airplane mode, and select a post, the post will still load. In fact, the entire post is still readable.

From this, we know that the app pulls the content for entire posts when it loads the previews (and does some caching).

The App Store app lazily loads images as well. Turning on Airplane mode after loading an app page and scrolling to the bottom reveals blank spaces where the loaded images belong.

Most modern apps depend heavily on network connections to download content and allow interactivity, so this will break most apps.

React Native and Non-Native Apps

Of the React Native apps I tested, most immediately responded to a lack of internet connection by removing all content on the screen and displaying a custom “no connection” message.

For webview-based apps, most didn’t respond. There was no indication that loading was occurring, or that it failed.

Conclusions from airplane mode

Unfortunately, airplane mode doesn’t give too many definitive answers on how the app is built, as most apps have some kind of fallback when no connection is available.

Want to dive deeper? You can learn a lot about other apps by observing their network traffic. Charles Proxy for iOS is a great way to get insight, but requires some knowledge of HTTP networking.

Takeaways

While it may seem impossible to determine how an app is built, there are some ways to make educated guesses. By studying edge cases, we can reveal the inner workings of the larger system.

Our learnings can inform the design and development of our own apps. Being aware of other approaches helps us make better decisions in the future.

In a world of closed-source apps with a limited ability to tinker, hopefully these techniques help some people discover (or rediscover) the joy of learning how things work.

Enjoyed the story? Leave some claps 👏👏👏 here on Medium and share it with your iOS design/dev friends. Want to stay up-to-date on the latest in mobile app design/dev? Follow me on Twitter: twitter.com/nathangitter

Thanks to David Okun for revising drafts of this post.

With the release of iOS 11, there was widespread concern that Apple’s software quality was declining. Many users experienced performance issues, software bugs, and visual glitches.

Here’s an example of a visual glitch in the Messages app, caused by force-touching to “pop” a message followed immediately by tapping the back button.

These kinds of visual errors are not new to iOS 11, mobile apps, or user interfaces. As apps grow in complexity and user expectations rise, these seemingly small bugs can have a large impact on the final product. They make apps feel janky.

What is Jank?

Jank refers to visual glitches that are unexpected and distracting. Usually they arise because of extra animations or missing animations.

An app can be “janky” or exhibit “jankiness” if it seems to be behaving incorrectly. Besides visual glitches, jankiness could refer to unresponsive buttons, inconsistent loading behavior, or awkward gestures.

In this post, I am going to focus solely on visual glitches.

Motivation

If you are a designer, you may not feel empowered to fix app jank—it’s a code problem, right?

Designers still play a critical role. Certain user interface elements are particularly janky, especially when pushed to their limits. If designers know which elements cause jank, and more importantly, the limitations of those elements, they can create designs that are less likely to result in janky apps.

We are going to discuss some common sources of jank in iOS apps and explore ways to design apps that can prevent these issues from arising althogether.

Navigation Transitions

Let’s start with a common user interface element: the navigation bar.

Here is a normal, happy navigation bar:

Here is a janky, sad navigation bar:

What’s wrong? Why is this navigation bar so janky?

In this case, the “Home” screen’s navigation bar is translucent, while the “New Screen”’s navigation bar is opaque.

The navigation bar provided by Apple is limited and volatile—only certain behaviors are supported. If a developer wants to modify the navigation bar in an unsupported way, there’s no guarantee that it will work correctly in all cases.

Navigation Transition Design Considerations

Many common navigation bar treatments are not fully supported: hiding the default 1px gray underline, hiding the back button text, adding extra views below the navigation bar, and allowing a back gesture from anywhere on the screen.

How can designers, who may not be familiar with the nuances of the UINavigationController API, design around these issues?

The main tip is to preserve design consistency across screens. If each screen has a new navigation bar style, you’re asking for trouble.

Keyboards

In my experience, keyboards are the most common source of jank. Both examples at the top of this post are keyboard-related.

Here’s another example. Notice how the circle animation works fine when picking images, but is incorrect when using the standard keyboard.

Keyboard Design Considerations

Anytime a keyboard is involved, you should keep the screen as simple as possible. Half of the screen real estate is gone anyway, so don’t pack the remaining space full of buttons.

Be wary of animations that occur alongside the keyboard animation, and don’t assume you have full control over the keyboard. Hiding the keyboard without an animation is possible, but might cause complications later down the road.

Also consider third-party and international keyboards. Just because your design works well with the standard English iOS keyboard doesn’t mean it will work for everyone. You should assume the height of the keyboard is unknown and may change at any time.

Multi-State Animations

I love multi-state animations. They are incredibly fun to design and build. However, animations that have many states tend to cause jank.

Here’s an example of a multi-state animation gone wrong:

This button has multiple states—it normally transforms into a spinner and animates to represent a download in progress.

From this, we can make an educated guess about where the spinning bug originated. Notice when the spinner first appears, but before the blue progress starts, the nearly-full gray circle is spinning in place. Due to some error in the code, the “open” button above thinks it’s in this intermediate spinning state.

The real issue here is too much state. When animations get into unintended states, they will exhibit jank.

Multi-State Animation Design Considerations

Multi-state animations increase complexity. If you are designing an element that animates between multiple states, make sure to consider all state transitions and edge cases. Something that seems simple on the surface might be much more complex than originally thought.

De-Janking a Design

Now that we know some common sources of jank in iOS apps, let’s use our new perspective to evaluate a design.

Here’s a rough and incomplete design I made a while ago. It was exploring the idea of a simple presentation app. The user could enter the “data” for each slide, and the presentation would be automatically rendered and themed.

The main focus is the middle screen, where the user can add new items, enter text, re-arrange slides, swipe horizontally between slides, and expand a preview of the rendered slide.

Looks pretty good, right? No. This design is a one-way ticket to Jankville.

Let’s count the potential sources of jank:

1. The varying navigation bars and transitions between them.
2. The slide preview which always stays above the keyboard.
3. The interactive and state-based animation of expanding the slide preview.
4. The scroll position and keyboard animations when the user adds many lines of text.
5. The state-based animation selecting the type of text (“Title”, “Subtitle”, “Bullet”, etc.)

Most importantly, these are not all independent—we would need to handle the side-effects of all possible combinations.

It’s absolutely possible to build this, but the developer would spend a sizable amount of time fixing animation glitches and state conflicts. This app will likely require an intense attention to detail, care, and ability to fix the issues that arise.

Here’s a new design I quickly mocked up:

The middle “My Presentation” screen has been expanded to three screens: the first for organizing slides, the second for organizing items, and the third for editing a single item.

This reduces possible sources of jank by leveraging default iOS elements and encapsulating potentially problematic elements. Instead of a custom expanding button animation to select the type of item, the user can select from a default picker. The keyboard is only used on the final screen, and never needs to hide since there’s only one text field.

This second design might not feel as unique, but it’s more likely to feel familiar and work as expected.

Note About Custom Designs

I don’t mean to discourage building custom user interfaces or pushing the boundaries of what’s possible. I love making experiences that feel fresh—it’s what makes iOS design and development fun.

But too often I seen custom designs that only make it 90% of the way to completion. Due to a variety of reasons, the last 10% falls short, and jankiness remains in otherwise well-designed apps.

If designers are aware of the most common pitfalls, they can help developers avoid them, which results in better experiences for everyone.

Takeaways

Designers can help prevent jank by knowing its causes and modifying designs accordingly.

Here are a few practical steps to reduce jank:

1. Get developer input early. An experienced iOS developer can quickly estimate the complexity of building a design and inform you about potential issues.
2. Simplify designs! It’s easy to hide complexity by assuming transitions and animations will work themselves out. By considering all possible cases and transitions, you will naturally move towards simpler solutions.

Hopefully you learned some of the reasons why some apps feel janky, and more importantly, feel empowered to solve jank through design!

Enjoyed the story? Leave some claps 👏👏👏 here on Medium and share it with your iOS design/dev friends. Want to stay up-to-date on the latest in mobile app design/dev? Follow me on Twitter here: https://twitter.com/nathangitter

Thanks to David Okun for revising drafts of this post.

Spot The Difference

Can you spot the differences between these two images?

If you look hard enough, you might notice a few subtle differences:

The image on the right:

1. Has a larger shadow.
2. Has a darker gradient.
3. Has the word “in” on the top line of the paragraph.

The image on the left is a screenshot from Sketch, and the image on the right is a reproduction on iOS. These differences arise when the graphics are rendered. They have the exact same font, line spacing, shadow radius, colors, and gradient attributes — all of the constants are identical.

As you can see, some aspects of the original design can be lost during the conversion from the design file to real code. We’re going to explore some of these details so you can know what to watch for and how to fix them.

Why We Care

Design is critical to a successful mobile app. Especially on iOS, users are accustomed to apps that work well and look good.

If you’re a mobile app designer or developer, you know how important small details are to the end user experience. High-quality software can only come from people who care deeply about their craft.

There are many reasons why apps might not look as good as their original designs. We’re going to investigate one of the more subtle reasons — differences in rendering between Sketch and iOS.

Lost in Translation

Certain types of user interface elements have noticeable differences between Sketch and iOS. We are going to explore the following elements:

1. Typography
2. Shadows
3. Gradients

1. Typography

Typography can be implemented in various ways, but for this test I am going to use labels (“Text” element in Sketch, UILabel in iOS).

Let’s look at some of the differences:

The biggest difference in the example above is the location of line breaks. The third grouping of text starting with “This text is SF Semibold” breaks after the word “25” in the design, but after the word “points” in the app. This same problem occurs with the paragraph of text—the line breaks are inconsistent.

Another smaller difference is that the leading (line spacing) and tracking (character spacing) are slightly larger in Sketch.

It’s easier to see these differences when they are directly overlaid:

What about other typefaces? Replacing San Francisco with Lato (a widely used free font), we get the following results:

Much better!

There are still some differences in leading and tracking, but these are generally small. Be careful though—if the text needs to align with other elements like background images, these small offsets can be noticeable.

How To Fix

Some of these issues are related to the default iOS font: San Francisco. When iOS renders the system font, it automatically includes tracking based on the point size. This automatically-applied tracking table is available on Apple’s website. There is a Sketch plugin called “SF Font Fixer” which reflects these values in Sketch. I highly recommend it if your design uses San Francisco.

(Side Note: Always remember to make the text box wrap tightly around text in Sketch. This can be done by selecting the text and toggling between “Fixed” and “Auto” alignment, then resetting the width of the text box. If there is any extra spacing, this can easily lead to incorrect values being entered into the layout.)

2. Shadows

Unlike typography which has universal layout rules, shadows are less well-defined.

As we can see in the image above, shadows in iOS are larger by default. In the examples above, this makes the most difference on the top edges of the rectangles.

Shadows are tricky because the parameters between Sketch and iOS are not the same. The biggest difference is that there is no concept of “spread” on a CALayer, although this can be overcome by increasing the size of the layer that contains the shadow.

Shadows can vary wildly in their difference between Sketch and iOS. I’ve seen some shadows with the exact same parameters look great in Sketch but be nearly invisible when running on a real device.

How To Fix

Shadows are tricky and require manual adjustment to match the original design. Oftentimes, the shadow radius will need to be lower and the opacity will need to be higher.

// old
layer.shadowColor = UIColor.black.cgColor
layer.shadowOpacity = 0.2
layer.shadowOffset = CGSize(width: 0, height: 4)
layer.shadowRadius = 10

// new
layer.shadowColor = UIColor.black.cgColor
layer.shadowOpacity = 0.3
layer.shadowOffset = CGSize(width: 0, height: 6)
layer.shadowRadius = 7

The required changes vary based on size, color, and shape — here, we only need a few minor adjustments.

3. Gradients

Gradients prove to be troublesome as well.

Of the three gradients, only the “orange” (top) and “blue” (bottom right) differ.

The orange gradient looks more horizontal in Sketch, but more vertical in iOS. As a result, the overall color of the gradient is darker in the final app than the design.

The difference is more noticeable in the blue gradient—the angle is more vertical in iOS. This gradient is defined by three colors: light blue in the bottom left corner, dark blue in the middle, and pink in the top right corner.

How To Fix

The start and ending points may need to be adjusted if the gradient is angled. Try offsetting the startPoint and endPoint of your CAGradientLayer slightly to account for these differences.

// old
layer.startPoint = CGPoint(x: 0, y: 1)
layer.endPoint = CGPoint(x: 1, y: 0)

// new
layer.startPoint = CGPoint(x: 0.2, y: 1)
layer.endPoint = CGPoint(x: 0.8, y: 0)

There’s no magic formula here*—the values need to be adjusted and iterated until the results visually match.

*Jirka Třečák posted an excellent response with links explaining how the gradient rendering works. Check it out if you want to dive deep into more code!

See For Yourself

I built a demo app to easily see these differences on a real device. It includes the examples above, along with source code and original Sketch file so you can tweak the constants to your heart’s content.

This is a great way to increase awareness within your team—just hand them your phone and they can see for themselves. Simply touch anywhere on the screen to toggle bewteen the images (similar to the gifs above).

Get the open-source demo app here: https://github.com/nathangitter/sketch-vs-ios

Takeaways

Don’t assume that equal values imply equal results. Even if the numbers match, the visual appearance may not.

At the end of the day, there needs to be iteration after any design is implemented. Good collaboration between design and engineering is crucial for a high-quality end product.

Enjoyed the story? Leave some claps 👏👏👏 here on Medium and share it with your iOS design/dev friends. Want to stay up-to-date on the latest in mobile app design/dev? Follow me on Twitter here: https://twitter.com/nathangitter

Thanks to Rick Messer and David Okun for revising drafts of this post.

But something odd happened when I pressed the app’s “share” button, which opened a default iOS activity view (aka “share sheet”). When I hit the “cancel” button to close the activity view, the home indicator animated to a dark gray color.

Even though the background color was exactly the same, the light-colored activity view passing underneath caused the home indicator to change color. The only way to get the home indicator back to its original color was to leave the app and come back.

I had never seen this before, and it prompted my curiosity.

What determines the color of the home indicator and why it does it behave like this? The answer is surprisingly complex. Let’s take a deep dive and see what we can learn!

Home Indicator Basics

In September 2017, Apple introduced its newest iteration of mobile phone: iPhone X. The new design replaced the iconic home button with on-screen gestures. To go home, the user simply swipes up from the bottom of the screen.

The Home Indicator’s Purpose

To create the affordance of being able to swipe up from the bottom of the screen, Apple added a small horizontal bar known as the home indicator. The home indicator is always present except for the home screen and in any apps that request it to be temporarily hidden (full-screen video, games, etc.).

The home indicator serves another purpose: protecting the bottom edge of the screen from conflicting user interface elements and gestures. Because the user needs to be able to swipe up from the bottom of the screen at any time, best practices now dictate that developers should avoid place conflicting gestures or buttons in the bottom edge of the display.

By placing a bar at the bottom, user interface elements in the same location look wrong—there’s a visual conflict between the bar and other elements. In this sense, the home indicator “protects” this region of the screen from designers or engineers that are unaware of the functionality of the iPhone X.

Now that we’re all on the same page, let’s get back to our original question: “What color is the home indicator?”

Part 1 — The Beginning

On September 13, 2017, I answered a Stack Overflow question asking how to change the color of the home indicator.

At the time, the iPhone X hadn’t been publicly released, but the latest version of Xcode included an iPhone X simulator. Running a simple test app in the simulator revealed that the home indicator’s color was based on the color of the content below it.

The new APIs for the iPhone X were released alongside this same version of Xcode, and there was no public API available to modify the color of the home indicator (which is still the case at the time of writing this post, and probably will always be the case).

This made my Stack Overflow answer simple and straightforward: it is not possible to modify the color, and you shouldn’t worry about it, since it’s out of your control and guaranteed to be visible.

Because I anticipated this to be a common question, I included some screenshots of the home indicator on top of various background colors.

This was good enough for me. The home indicator maintains its visibility by sampling the color of the view below it, and picking a gray color that provides sufficient contrast.

Part 2 — The Plot Thickens

It turns out the home indicator’s color is not that simple. Some further observations poked holes into my “solid-color function” theory.

Observation #1: Multiple Colors

The first observation is that the home indicator can have multiple colors, similar to a gradient. In the following example, the left side of the screen is black, and the right is white. The home indicator adjusts for this by adopting a lighter color over the dark background, and a darker color over the light background.

The home indicator can be multiple colors at the same time, and smoothly transitions between them. This smooth transition is updated in real time if any of the views behind the home indicator change.

In the example above, a small white view is moving back and forth behind the home indicator. The section of the home indicator that covers the white view becomes pure black and smoothly transitions to gray.

This behavior is similar to a UIVisualEffectView, which applies a blur over existing content. The home indicator is most likely taking a sample of the nearby colors in order to get the blend effect seen in the image above.

(Besides looking good, this functionality might help prevent burn-in on the OLED display.)

Observation #2: Same Background, Different Home Indicator Color

As I mentioned at the beginning of this post, I noticed an unusual behavior when a share sheet passed beneath the home indicator.

This was the most surprising observation — there is not a simple 1-to-1 mapping between background colors and home indicator colors. At this point I was determined to learn more via experimentation.

Part 3 — The Investigation Begins

My first order of business was to determine the formula for the home indicator color on the iOS simulator. From my previous observations, the iOS simulator’s behavior was more predictable than a real device.

I created a new iOS app as a laboratory for my future experiements. The app was simple—all I needed was an easy way to change the background color behind the home indicator. A slider and stepper control the background color’s gray value, which is displayed as a large number in the center of the screen.

My goal was to determine the home indicator color for every possible gray background color. I could graph this data and see if a formula applied to it. Since there were only 256 possibilities, I took the manual approach, using macOS’s built-in “Digital Color Meter” app to get the home indicator color for each value.

I graphed the results. It was not a linear function, an exponential function, or any kind of “nice” function you might see in math class.

The graph was … odd.

This was not what I was expecting.

It was a step function but with uneven steps. It had a few distinct sections: a period of (relatively) light gray, two big steps, a series of small steps, steps in the reverse direction, and a period of pure black.

The most unusual part was that the home indicator color was not always decreasing. There was a period (around rgb 170–190) where it became lighter as the background became lighter.

Why did the graph look like this? What would the same experiment have similar results on a real device? I needed to know.

Part 4 — The Investigation Continues

My next task was to perform the same experiment on a real device. It was immediately obvious that the results were going to be dramatically different.

To collect data on a real device, I used the same app from before. I streamed a live preview of the iPhone screen to my computer via QuickTime. This removed any discoloration from the True Tone display, as well as allowed me to use the Digital Color Meter app to easily inspect the colors.

Another factor added to the complexity on a real device—the red, green, and blue values were not always the same. On the simulator, the RGB values were identical, resulting in colors like RGB(54, 54, 54). On a real device, they were almost never the same, but were very close, resulting in colors like RGB(211, 209, 212). When recording the results, I took the average of the individual RGB values.

Here are the results, compared with the previous simulator data.

The colors on a real device (red line) follow a similar trend to those on the simulator (blue line), except offset by a significant margin. The simulator home indicator is always very dark, while the device home indicator is either very light or very dark.

The graph for the real device is noisy. Overall it follows a smooth trend, but jumps up and down and looks rough. This is more than just a side-effect of my averaging, and the noise is consistent. If the experiment is repeated, the noise follows the exact same pattern.

However, the graph above doesn’t tell the whole story.

The values presented above were gathered by starting the background completely black and incrementing the RGB values one at a time (going from 0 to 255). When the values are gathered in the opposite direction, the results are different.

At a certain point, the home indicator color “falls off the cliff” in its transition from light to dark or dark to light, and animates for a brief period of time, as shown in the previous gif with the purple background color. Depending on whether the background starts light or dark, the cliff occurs in a different place.

Let’s take a look at a new graph comparing the results from “going up” (black to white) and “going down” (white to black).

The blue line above is the same as the previous graph’s red line. Its data points were collected left to right (0 to 255, “going up”). The orange line is the same data, but collected in the opposite direction (255 to 0, “going down”). The red line represents the points where the home indicator and the view background are the same color.

The “going up” and “going down” lines follow a similar path, but have a different noise pattern. Interestingly, they have the exact same noise pattern in the darkest range (0–80).

From this graph we can tell that the “cliffs” occur when the color of the home indicator is coming too close to the color of the background. It even appears as if the “going up” and “going down” lines are being pushed away by the red line, actively trying to resist becoming exactly the same color as the background. At a certain point, the home indicator flips to being very dark or very light.

This explains the shift in color in the app with the purple background. The purple color must be in a region between the two cliffs. Based on the previous color of the home indicator, it could either be light or dark. When the white activity view animates behind the home indicator as it is dismissed, the home indicator transitions from its light state to its dark state, and re-settles at the dark-equivelevnt value for the purple background color.

Part 5 — The Investigation Becomes Colorful

All the tests up to this point have used grayscale backgrounds. How would the results differ if we used colored backgrounds instead?

I repeated the same experiment, but instead of modifying the gray color, I modified the hue on an HSB color scale. I kept the saturation (S) and brightness (B) at their maximum values to get the most vibrant and distinct colors. I only tested these colors “going up”, which in this case means from hue 0 (red) to hue 255 (red) in rainbow order.

The first observation is that there are two cliffs — once when the color becomes yellow, and again when the color becomes dark blue. This occurs because of the relative “brightness” of the colors.

The next observation is the difference between the simulator and a real device. The colors follow the same general trends, but the real device’s home indicator color is noisier and can reach brighter values.

These are fascinating findings so far. Aside from testing every possible background color, there’s not much else we can discover from observation alone. Now I was curious exactly how the home indicator is implemented—is it a UIView? CALayer? UIVisualEffectView? Something else? What is making it behave in this way?

Let’s find out.

Part 6 — We Need to Go Deeper!

At this point I turned to my friend and iOS expert Ian McDowell. He was able to point me in the right direction—using the iPhone X Simulator and Xcode’s debugging tools to find the home indicator.

The iOS “home screen” is actually an app called SpringBoard. We can attach a debugger to the Springboard app running in the iPhone X simulator and use the “Debug View Hierarchy” option in order to inspect the views that make up the home screen, including the home indicator.

If you want to follow along at home, here is the process:

1. Launch an iPhone X simulator.
2. In Xcode, select Debug > Attach to Process… > SpringBoard.
3. When SpringBoard is running, select the Debug View Heirarchy button.

Deep in the view hierarchy we find an MTLumaDodgePillView which is a subview of an SBHomeGrabberView. Sounds like we found the home indicator!

The name MTLumaDodgePillView makes sense. It confirms our observed behavior of the home indicator, that its color contrasts the background based on its current brightness.

Can we go deeper yet?

SpringBoard has another cool feature: a hidden debug menu. It turns out there’s an entire section for modifying properties of the home indicator. In this debug menu, the home indicator is called a “grabber”.

This debug menu mainly contains visual and animation settings. It is most likely used to collaborate between design and engineering within Apple. Engineering builds the home indicator, provides hooks to all the internal parameters, lets designers fiddle with them until they are content, and then engineers use the settings for the final product.

Luckily for us, we can access this menu and see the results in the simulator.

I first played around with the visual appearance of the home indicator. There are sliders for the width and height in various states.

The other settings are more difficult to test, as they don’t seem to apply to the simulator. There are settings for a “luma threshold” for light and dark, as well as parameters for the animation between states. This confirms the “cliffs” where the color would dramatically animate between light and dark—there are pre-defined thresholds based on the luminosity of the background.

I was unable to determine why the simulator behaves so differently from a real device. My guess is that the simulator is using a different combination of settings, or that certain settings only take effect on real hardware.

Want to learn more about reverse engineering on iOS? Sash Zats posted an amazing in-depth article about the home indicator. Check it out if you want to dive into more code!

This marks the end of the adventure of home indicator discovery. I hope it was as educational for you as it was for me!

High-level Takeaways

1. The home indicator’s color is determined by the system and cannot be modified directly.
2. The home indicator’s color is determined by the content underneath, and it is not always a solid color.
3. The home indicator on the simulator is not an accurate representation of the home indicator on a real device.
4. The home indicator animates to its new color(s) when the content underneath changes.
5. The home indicator is either in a “light” or “dark” state.

But… Why?

Why bother investigating the home indicator if its appearance is out of our control?

There is a practical application for these learnings: If a screen in your app has a background color in the middle range where the home indicator could be either light or dark, you may prefer one style over the other. If the status bar is white, for example, it may look more visually balanced if the home indicator is white as well. Being aware of the home indicator’s nuanced behavior can help ensure that it doesn’t accidentally animate between light and dark when it could be distracting to the user.

In a previous example, the white share sheet animating behind the home indicator was enough to change the home indicator’s style.

If I wanted to prevent this, I could pin a view behind the home indicator between the safe area and the bottom edge of the display. When the share sheet is dismissed, I could give it a darker background color (maybe black with 40% alpha) and add a fade animation so it’s less noticeable.

This same tactic could be used to set the color of the home indicator—forcing it over one of the “cliffs”. In the vast majority of cases, the home indicator should be left alone to do what it wants. Most iPhone X users have probably already forgotten it’s even there.

The Real Lesson

Hopefully this brief investigation into the color of the home indicator helps us appreciate the complexity of simple design. “It’s just a black/white bar!” is far from the truth. The amount of care and attention to detail that went into the home indicator is worth appreciating.

Taking something simple, investigating its internal complexities, and pondering its design helps us learn about the creative process. By combining design and engineering, we can make better products that are simple and delightful to use.

Enjoyed the story? Leave some claps 👏 here on Medium and share it with your iOS design/dev friends. Want to stay up-to-date on the latest in mobile app design/dev? Follow me on Twitter here: https://twitter.com/nathangitter

Thanks to Ian McDowell and David Okun for helping revise previous drafts of this post.

Swift is an incredibly expressive and powerful programming language. We’re going to explore some of Swift’s language features that can make your code easier to read.

Better Buttons

Let’s take a look at a common iOS pattern that prints a message when a button is pressed.

If you’ve done any iOS tutorial, it’s very likely you’ve seen this before. The selector pattern is used throughout UIKit, and it’s not necessarily bad practice. However, we can do better.

The issue arises when there is a lot of code between the selector declaration and the button’s action. If a developer is reading this for the first time, it’s quite common for them to lose track of what your functions do at a high level.

The two lines of code are loosely coupled. They require the reader to jump between them to fully understand the button.

Let’s try a new approach, using a closure to assign an action to the button.

Don’t worry — this isn’t possible with UIKit out of the box, but it’s easy to make a UIButton work like this.

In addition to containing the first snippet in one function, we’ve used a closure to more clearly communicate what happens when a button is tapped. This makes it easier to comprehend what this button does.

Implementing a closure for your button-tapped action is quite straightforward. Create a custom UIButton subclass with an action property, which is a closure. We hook up the button’s selectors internally, and execute the closure in the target function.

This solution can expand to include closures for a UIButton's other actions as well, such as touchDown, touchDragExit, and more.

Local Reasoning

Keeping relevant information together improves local reasoning. Local reasoning is the idea that the reader can make sense of the code directly in front of them, without going on a journey discovering how the code works.

At WWDC 2016, Apple engineers gave a great talk titled “Protocol and Value Oriented Programming in UIKit Apps”, where they discussed the concept of local reasoning. Their presentation covered protocols and how to leverage their benefits over traditional inheritance-based solutions.

It’s hard to call a code organization strategy invalid, as they often vary based on personal preference. However, I am proposing that the best form of code organization is the one that allows the reader to accurately reason about the code while minimizing the distance traveled through the codebase.

Lazy Closures

Let’s take a look at another common Swift design pattern that focuses on improving local reasoning.

A common practice is to perform setup work in the viewDidLoad function on a UIViewController subclass.

Like the previous button example, this works just fine.

Notice that we’re split between a stored property declaration and an overridden function. This is the issue we want to focus on — finding all the code related to the view often requires a search.

Instead, we can use a closure to initialize the view.

The closure is marked as lazy so self can be accessed within the closure. This allows the properties to reference any constants declared on self and set target actions for any controls.

This strategy works with storyboard outlets as well. Instead of using a closure, use the didSet property observer which is called when the outlet is set by the storyboard.

This is especially useful for view properties that cannot be set in the storyboard like corner radii, gradients, etc. It localizes our changes to the view itself.

Instead of spreading the code throughout our file, we can keep it together in one place.

Protocol Conformance Extensions

Protocols are used throughout the Swift Standard Library and Cocoa Touch API’s. They give a compile-time guarantee that an object has certain properties or functions.

Here is another common pattern, implementing a collection view’s delegate and data source in a view controller.

Once again, this works. However, delegate functions are often quite long, and tend to bloat the size of the controlling object implementing them. It’s hard to tell when a property or function is fulfilling protocol requirements, and which protocol it belongs to.

Instead, let’s declare protocol conformance in an extension to better group related code together.

This not only groups the code for each protocol, but also displays the name of the protocol directly above the implementations. At the type declaration, this decreases cognitive load, since the conformances no longer need to be written after the type name.

Protocol conformances that are not needed to understand what an object does (like CustomStringConvertible) can be placed after the type’s definition, where more important details about the type need to be understood first.

The implementation of the Swift Standard Library makes heavy use of protocol conformance in extensions since it’s easier to determine which functions belong to which protocol. Take a look at the open-source repo on GitHub and see for yourself.

Takeaways

We looked at three common patterns in Swift code and alternatives that leverage Swift’s features to improve local reasoning.

When writing code, it’s important to think from the perspective of the person reading it. This includes coworkers, teammates, and even your future self. Good local reasoning allows others to understand and modify code more easily, improving its maintainability and flexibility.

While many of these techniques could be considered “code style”, they serve a specific purpose to improve the quality of the code. There are some parallels to user experience design. In this case, the user interface is the text that comprises the code, and the user is the developer. If we take a user-centric approach to writing code, we can make it easier to understand and modify in the future.

Do you have any other places where you could give local reasoning a try in Swift? Let me know in the responses below!

Enjoyed this post? Give some claps for this story here on Medium and follow me on Twitter! https://twitter.com/nathangitter

Also thanks to @dokun24 for giving feedback on a draft of this post. You can follow him on Twitter here: https://twitter.com/dokun24

Animations are key to a quality user experience. They serve a wide variety of purposes, including directing user attention and connecting user actions to results on screen.

Animations make the experience of your app unique — they can enable a level of responsiveness and interactivity not possible in other mediums. To build better animations, they need to convey an improved sense of direct connection between user interaction and visual changes. One way to accomplish this is to make animations fully interactive.

Why Create Interactive Animations?

Interactive animations have been around since the introduction of the iPhone. The world’s first look at the original iPhone was the classic “slide to unlock” screen, where the user directly moved the slider to unlock the device. This interactive animation was immediately intuitive for those who had never used a multi-touch device before.

Interactive animations give the user more control over the user interface. Direct manipulation is a natural interaction model, especially on mobile devices. It connects their actions to on-screen animations and gives them full control over the completion or cancellation of their actions.

They also look great. Users often associate how an app looks with how well it works, so if it looks good, they are more likely to forgive other shortcomings.

In this tutorial, we will be building an interactive popup animation in Swift with UIViewPropertyAnimator.

Introduction to UIViewPropertyAnimator

UIViewPropertyAnimator was added to UIKit in iOS 10, and improved slightly in iOS 11. It provides a UIView-level object-oriented API to create animations.

Here is a simple example:

Using traditional UIView animations, you might write something like this:

UIView.animate(withDuration: 1, delay: 0, options: [.curveEaseOut], animations: {
    self.myView.transform = CGAffineTransform(translationX: 50, y: 0)
    self.myView.alpha = 0.5
}, completion: nil)

Using the new UIViewPropertyAnimator, you can write this instead:

let animator = UIViewPropertyAnimator(duration: 1, curve: .easeOut, animations: {
    self.myView.transform = CGAffineTransform(translationX: 50, y: 0)
    self.myView.alpha = 0.5 })
animator.startAnimations()

The code is very similar. With UIViewPropertyAnimator, you first create an animator object and then call startAnimation() instead of calling a static method on the UIView class.

UIViewPropertyAnimator becomes more useful as the animation increases in complexity. Let’s take a look at a more complex animation.

This animation begins when the view is panned, can be scrubbed in either direction, and animates to its final position once the pan is finished.

Before looking at the code, it’s important to understand the state machine backing UIViewPropertyAnimator.

An animator can be in one of three possible states: inactive, active, and stopped. An animator is initialized in an inactive state but moves to the active state when started or paused. When the animation is completed, it moves back to the inactive state. If an animation has been started, and is paused, it remains in the active state and does not undergo a state transition.

Let’s see how to use a UIPanGestureRecognizer alongside a UIViewPropertyAnimator to create the animation above.

var animator = UIViewPropertyAnimator()

private func handlePan(recognizer: UIPanGestureRecognizer) {
    switch recognizer.state {
    case .began:
        animator = UIViewPropertyAnimator(duration: 3, curve: .easeOut, animations: {
            myView.transform = CGAffineTransform(translationX: 275, y: 0) myView.alpha = 0 })
        animator.startAnimation()
        animator.pauseAnimation()
    case .changed:
        animator.fractionComplete = recognizer.translation(in: myView).x / 275
    case .ended:
        animator.continueAnimation(withTimingParameters: nil, durationFactor: 0)
    default:
        ()
    }
}

Note that pauseAnimation() is called immediately after startAnimation(). Because our animation begins on a pan gesture, the user is most likely to scrub the animation first before releasing their tap. When the animation is paused, set the fractionComplete property to move the view along with the user’s touch.

If we tried to do this with standard UIView animations, we would need a lot more logic than what is listed in the example above. UIView animations don’t provide an easy way to directly control the completion percentage of the animation, or allow us to easily pause and continue the animation to completion.

Let’s Build a Popup Menu!

We are going to build a fully interactive, interruptible, scrubbable, and reversible popup menu in 10 steps. (If you prefer to work backward from the final code instead, a link to the final repository is available at the end of this post.)

For simplicity, all views will be created and modified in code (not in storyboard, although this code would work just as well with views created in the storyboard). Also, all code will be placed in the ViewController.swift file.

Step #1: Tap to open and close.

First, let’s make our popup view animate between its open and closed state. No fancy tricks here, just the basics of UIViewPropertyAnimator we learned previously.

private enum State {
    case closed
    case open
}

extension State {
    var opposite: State {
        switch self {
        case .open:
            return .closed
        case .closed:
            return .open
        }
    }
}

class ViewController: UIViewController {

    private lazy var popupView: UIView = {
        let view = UIView()
        view.backgroundColor = .gray
        return view
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        layout()
        popupView.addGestureRecognizer(tapRecognizer)
    }

    private var bottomConstraint = NSLayoutConstraint()

    private func layout() {
        popupView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(popupView)
        popupView.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
        popupView.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true
        bottomConstraint = popupView.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: 440) bottomConstraint.isActive = true
        popupView.heightAnchor.constraint(equalToConstant: 500).isActive = true
    }

    private var currentState: State = .closed

    private lazy var tapRecognizer: UITapGestureRecognizer = {
        let recognizer = UITapGestureRecognizer()
        recognizer.addTarget(self, action: #selector(popupViewTapped(recognizer:)))
        return recognizer
    }()

    @objc private func popupViewTapped(recognizer: UITapGestureRecognizer) {
        let state = currentState.opposite
        let transitionAnimator = UIViewPropertyAnimator(duration: 1, dampingRatio: 1, animations: {
            switch state {
            case .open:
                self.bottomConstraint.constant = 0
            case .closed:
                self.bottomConstraint.constant = 440
            }
            self.view.layoutIfNeeded()
        })
        transitionAnimator.addCompletion { position in
            switch position {
            case .start:
                self.currentState = state.opposite
            case .end:
                self.currentState = state
            case .current:
                ()
            }
            switch self.currentState {
            case .open:
                self.bottomConstraint.constant = 0
            case .closed:
                self.bottomConstraint.constant = 440
            }
        }
        transitionAnimator.startAnimation()
    }
}

The relevant animation code is in the popupViewTapped function, which is called when the view is tapped. We simply create an animator, set its animations to modify the value of a constraint, and start the animator.

We introduce a State enum to indicate whether the popup is open or closed. It also has a computed opposite property, which returns the opposite of the current state. We could have implemented this with a boolean flag instead, but this is easier to reason about, especially once our animation code gets more complex.

One thing to point out — we are manually updating the value of the constraint when the animation is complete. This should be handled automatically by the animator, but explicitly setting them fixes some edge-case bugs.

Step #2: Add a pan gesture.

To make our animation interactive, we are going to introduce a second gesture recognizer, a pan gesture recognizer. This will allow the user to start and interrupt the animation by swiping on the popup view.

@objc private func popupViewPanned(recognizer: UIPanGestureRecognizer) {
    switch recognizer.state {
    case .began:
        animateTransitionIfNeeded(to: currentState.opposite, duration: 1.5)
        transitionAnimator.pauseAnimation()
    case .changed:
        let translation = recognizer.translation(in: popupView)
        var fraction = -translation.y / popupOffset
        if currentState == .open { fraction *= -1 }
        transitionAnimator.fractionComplete = fraction
    case .ended:
        transitionAnimator.continueAnimation(withTimingParameters: nil, durationFactor: 0)
    default:
        ()
    }
}

This code is very similar to the previous example, except that the animation can be interrupted. We have refactored our animation code into a function named animateTransitionIfNeeded, which runs all of the code that was previously inside our popupViewTapped function.

Step #3: Record the animation progress to fix the interruption offset.

One problem: when the animation is interrupted, it is offset from the user’s touch. This is due to the pan handler not considering the current progress of the animation. To fix this, we need to record the fractionComplete of the animator, and use this as our baseline when calculating a pan offset.

We will need a property to store the current progress of the animation:

private var animationProgress: CGFloat = 0

When the pan gesture is in its began state, we record the current progress of the animation:

animationProgress = transitionAnimator.fractionComplete

In the pan gesture’s changed state, we add the animation progress to the calculated fraction:

transitionAnimator.fractionComplete = fraction + animationProgress

Now the pan gesture works as expected, and tracks the users finger more naturally.

Step #4: Introduce a custom instant pan gesture.

The interruption behavior works, but is awkward. In order for the pan to be recognized, the user must tap on the screen and then move their finger in any direction. We would prefer the behavior to act like a scroll view, which allows the user to “catch” the view with only a touch down. Currently, the tap gesture and pan gesture are only fired on touch up and touches moved, respectively. In order to fire an event on touch down, we can create our own custom gesture recognizer.

class InstantPanGestureRecognizer: UIPanGestureRecognizer {
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent) {
        if (self.state == UIGestureRecognizerState.began) { return }
        super.touchesBegan(touches, with: event)
        self.state = UIGestureRecognizerState.began
    }
}

This pan gesture subclass enters the began state on touch down. It allows us to replace both of our previous gesture recognizers. The “tap” is now an “instant pan” that ends right after it begins. By using this custom gesture recognizer, we can improve the behavior of our previous tap/pan solution as well as simplify our logic.

Note: In order to subclass a UIGestureRecognizer, you’ll need to include this import at the top of the file:

import UIKit.UIGestureRecognizerSubclass

Step #5: Use the pan velocity to reverse animations.

One remaining problem is that the popup doesn’t respect which way the view is “thrown”. If we tap on the closed popup, catch it mid-animation, and swipe back down, it will continue to animate open.

To solve this, we can conditionally reverse the animator. This will be based on a few factors: the current state of our popup, whether the animator is currently reversed, and the velocity of the pan gesture.

The ended case of the pan gesture handler now looks like this:

let yVelocity = recognizer.velocity(in: popupView).y
let shouldClose = yVelocity > 0

if yVelocity == 0 {
    transitionAnimator.continueAnimation(withTimingParameters: nil, durationFactor: 0)
    break
}

switch currentState {
case .open:
    if !shouldClose && !transitionAnimator.isReversed {
        transitionAnimator.isReversed = !transitionAnimator.isReversed
    }
    if shouldClose && transitionAnimator.isReversed {
        transitionAnimator.isReversed = !transitionAnimator.isReversed
    }
case .closed:
    if shouldClose && !transitionAnimator.isReversed {
        transitionAnimator.isReversed = !transitionAnimator.isReversed
    }
    if !shouldClose && transitionAnimator.isReversed {
        transitionAnimator.isReversed = !transitionAnimator.isReversed
    }
}

transitionAnimator.continueAnimation(withTimingParameters: nil, durationFactor: 0)

This logic may seem complex at first, but it can be derived by considering all the possible cases.

In the changed case of the pan gesture handler, we need to respect the isReversed property of the animator:

let translation = recognizer.translation(in: popupView)
var fraction = -translation.y / popupOffset
if currentState == .open { fraction *= -1 }
if transitionAnimator.isReversed { fraction *= -1 }
transitionAnimator.fractionComplete = fraction + animationProgress

Now our animation can be reversed! If the user wants to close the popup mid-animation, it’s easy and intuitive for them to do so.

Step #6: Animate the corner radius.

In iOS 11, a CALayer's corner radius is animatable without the need for a CABasicAnimation. This means we can update a view’s corner radius in an animation block, and it will just work!

self.popupView.layer.cornerRadius = 20

We can also specify which corners to round. In this case, we only want the top left and top right corners to be rounded.

view.layer.maskedCorners = [.layerMaxXMinYCorner, .layerMinXMinYCorner]

Now the top two corners are animated alongside our original animation.

Step #7: Make it prettier!

Our gray popup view works well, but could use some visual improvements. Let’s add a background image, an overlay view, a title label, a subtle shadow, and some sample reviews.

This tutorial is not going to cover the implementation of these additional views. If you would like to see how they are created, check out the full source code at the bottom of the post.

Much nicer. 😎

Step #8: Animate the label.

The “Reviews” label looks great when the popup is closed, but when opened, it fails to stand out from the rest of the content. We would like to give the label a larger font size and darker color when the popup is open. This label transition needs to be animated since our popup is fully interactive and scrubbable.

There is no built-in way to animate a label’s color or font style. Our solution is a simple workaround: cross-fade the labels.

To smooth the animation, we need to animate the scale and translation of each label so they overlap perfectly during the entire length of their animation.

Inside of our animation block, we modify the label’s alpha and transform:

switch state {
case .open:
    // other animations here ...
    self.closedTitleLabel.transform = CGAffineTransform(scaleX: 1.6, y: 1.6).concatenating(CGAffineTransform(translationX: 0, y: 15))
    self.openTitleLabel.transform = .identity
    self.openTitleLabel.alpha = 1
    self.closedTitleLabel.alpha = 0
case .closed:
    // other animations here ...
    self.closedTitleLabel.transform = .identity
    self.openTitleLabel.transform = CGAffineTransform(scaleX: 0.65, y: 0.65).concatenating(CGAffineTransform(translationX: 0, y: -15))
    self.openTitleLabel.alpha = 0
    self.closedTitleLabel.alpha = 1
}

Now the labels appear as if they are morphing into each other. With the correct alignment, it looks like there is only a single label.

Step #9: Refactor for multiple animators.

The label animation works well, but the timing could be improved to smooth the transition further. In order to modify the timing curve of the label animations, we need additional animators. A UIViewPropertyAnimator can only have one timing curve, so in order to use multiple timing curves, we need to coordinate multiple animators.

We need to refactor our code a bit to support any number of animators. To do this we will create an array of animators.

private var runningAnimators = [UIViewPropertyAnimator]()

Whenever we create a new animator, we add it to the array of running animators.

runningAnimators.append(transitionAnimator)

Whenever an animation finishes, we will remove it from the array. To make the rest of the code work with multiple animators, anything applied to the transitionAnimator is applied to the entire array.

Step #10: Add new animators for the label alpha.

With our new infrastructure, we can create two new animators: one to animate the new label in, and another to animate the old label out. The benefit of using multiple animators is that each can have their own timing curve.

let inTitleAnimator = UIViewPropertyAnimator(duration: duration, curve: .easeIn, animations: {
    switch state {
    case .open:
        self.openTitleLabel.alpha = 1
    case .closed:
        self.closedTitleLabel.alpha = 1
    }
})
inTitleAnimator.scrubsLinearly = false

We set the animator’s scrubsLinearly property to false so that the fractionComplete of the animation gets mapped to the ease-in timing curve, instead of a linear timing curve. Generally animations that follow the user’s finger should follow a linear timing curve, which is why this property is true by default.

(Note: scrubsLinearly is only available on iOS 11+)

The difference is subtle but will allow the animation to be customized further in the future. Getting this transition exactly right is important when the user has full control over the animation and can scrub it to any point.

Here is our final animation! The user can start the animation with a tap or swipe, can interrupt the animation, and can reverse the animation. Pretty cool for a relatively small amount of code.

When should I use UIViewPropertyAnimator?

With so many animation API’s available in iOS, when is it best to use UIViewPropertyAnimator?

The differentiator is interruptibility. If you want to “catch” a view mid-flight, scrub it, and continue or reverse the animation, UIViewPropertyAnimator is the best option. Some other animation tactics are interruptible, such as animating views alongside a scroll view’s contentOffset property, but these animations are restricted to the timing curve of the scroll view.

Sometimes it doesn’t make sense for an animation to be interruptible. Only make an animation interruptible when the user can tap on the view during its animation. The animation should have a long enough duration that the user could react quickly enough to tap it, and the animated view should have a large tap target. The popup animation above is a perfect example of meeting these requirements.

Conclusion

Hopefully, you learned something new about interactive animations! The full source code for the popup animation is linked below.

When designing and building apps in the future, consider how interactive animations can improve the user experience. Instead of designing every screen to remain static and only respond to taps, think about ways to make the user interface animated and interactive.

Links and Resources

Full source code is available on GitHub:
https://github.com/nathangitter/interactive-animations

Great WWDC 2017 Presentation about interactive animations:
https://developer.apple.com/videos/play/wwdc2017/230/

Official UIViewPropertyAnimator Documentation:
https://developer.apple.com/documentation/uikit/uiviewpropertyanimator

About SwiftKick Mobile

SwiftKick Mobile is a mobile application design and development agency in Austin, TX. Need help with your next app? Reach out to hello@swiftkickmobile.com

Originally published at www.swiftkickmobile.com on September 11, 2017.

Building Better iOS App Animations was originally published in SwiftKick Mobile on Medium, where people are continuing the conversation by highlighting and responding to this story.