Navigation Transitions

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

Here is a normal, happy navigation bar:

Smooth transition when tapping the back button and when driven interactively.

Here is a janky, sad navigation bar:

Extra animation of black region on the right side; lack of animation when the back button is pressed.

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-related jank in Snapchat.

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:

App Store button with an unintended animation.

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

Even the “normal” behavior can be janky. (recorded in the TestFlight app)

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.