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.