Successful iOS Design | UXPUB

Guidelines to help designers create more realistic designs from a development perspective when working on iOS projects

When iOS developers partner with designers, we work together to make the final product. The design team is ahead of the development team – which means that when the iOS development team comes in to give an estimate, there might be some surprises in terms of cost. This is because design work is not always realistic in terms of budget and lead time.

When working on a new product, there are some simple guidelines for designers to help align the work of the designer, iOS developer, and client.

Never Think Code Design Is Easy

IOS developers often ask why a simple web page design takes so long to port to native development. Therefore, it is important to understand the fundamental difference between web development and native development.

Imagine you want to display the top of the periodic table:

Successful iOS design

Periodic table of elements [Источник]

In a web document, you describe the content. You indicate that you want a 7×18 table with a solid black border. Then you put the letter “H” in the first cell and give it a green background.

In native development, however, you need to provide a recipe for drawing this table to the screen:

  1. Draw a solid green X-sized square starting at points (Y, Z).
  2. Draw a Q letter “H” at the W point, which should be in the center of the square.
  3. Draw one black line below the square that is the bottom border of the first cell.

The web browser is responsible for this recipe. You tell the browser what to display, and it will take care of displaying it well. From this point of view, developing a native iOS app is like implementing a web browser, not a web page.

Custom design problems

Most custom designs have a few common problems. Since these problems add up to a total during the development phase, it makes sense to try to fix them early in the development phase.

Design for different screen sizes

At the time of writing, the latest version of iOS 12 supports phones with screen sizes from the iPhone SE (568x320 pts) to iPhone Xs Max (896x414 pts). However, iPhone-exclusive apps can also be opened on iPad in iPhone compatibility mode.

Successful iOS design

IPhone app in compatibility mode on iPad [источник]

In compatibility mode, the app is displayed with the iPhone 4 screen size (480x320 pts). Unfortunately, this is not an isolated case, it is more common than you might think.

Most App Store reviewers deliberately use the iPad to review iPhone applications. If the app design is not fully functional on such a tiny screen, the application to add the app to the store will be rejected immediately. A good example would be a registration button that does not appear on a small screen, preventing the user from completing the registration process.

Comparing the two extreme screen sizes, you can tell that when using components of the same size, more than half of the iPhone Xs Max screen will be blank. This never happens in real projects.

However, it is common to see custom (non-standard) designs prepared for the largest screen size without resizing attributes. This shifts the responsibility for defining the sizing rules to the developers, which unnecessarily lengthens the development time.

Conclusion number 1: Design for at least 2 extreme screen sizes and use resizable components.


Animations are very difficult to get right. Most of the custom animations featured in the best shots from Dribbble are usually:

  • are interactive (animation playback is controlled by the user s gesture),
  • provide transition between screens,
  • redefine the existing system-wide solution.

This makes them expensive to implement. Why? Let s find the answer based on one of the Dribbble shots from the Popular section.

Successful iOS design

Beautifully animated transitions between screens [источник]

This shot has two different animations. First, rotate the tile when swiping left and right. Secondly, the sliding transition between screens. The latter is especially troublesome.

To understand the issue, let s take a quick tour of navigating native iOS apps as described in Human Interface Guidelines from Apple:

Whenever possible, use standard navigation controls such as page controls, tab bars, sharded controls, table views, collection views, and split views. Users are already familiar with these controls and will intuitively know how to operate in your application.

And specifically for hierarchical data:

Use the navigation bar to navigate the data hierarchy. The title of the navigation bar can display the current position in the hierarchy, and the back button makes it easy to return to a previous location.

Successful iOS design

The navigation bar is a simple concept familiar to iOS users [источник]

Since the back button is located in the upper left corner, it cannot be reached with one hand on a large device. This is why iOS has a built-in interactive gesture that allows the user to go back without pressing a button.

Successful iOS design

Interactive left-to-right swipe is built into the native navigation bar [источник]

How does the navigation bar relate to the custom animation from the above shot? Because it overrides how the new screen is presented, it makes it the responsibility of the developer to reimplement the default interactive gesture.

To achieve this, the designer must provide mathematical equations that control the position of each element on the screen in relation to time. And it takes a lot of time.

To make matters worse, the detailed screen displays category images and recent searches that are retrieved from the web server. To make the animation look pretty, we need to preload these images for all power options when displaying tiles. It may take a few minutes for the list to be displayed on a weak 3G connection! On the other hand, without preloading, we can only animate empty placeholders, which will kill all the beauty.

Conclusion number 2: do not animate transitions between different screens or interrupted actions.

Best Animation Since Lottie

A much better approach to native animation is to use Lottie… Lottie imports and plays animations exported from After Effects using a plugin Bodymovin… It comes free for iOS as well as Android and web.

From a native developer s point of view, Lottie is a virtually no-cost solution. It also helps to avoid mistakes when creating animations. To create an interactive transitive animation, you will need to include the entire application interface in the export, which doesn t sound right from the start.

You can see Lottie in action by viewing the repository lottie files… If you get stuck when you start using Lottie, you can read more on how to overcome some of the limitations of this tool

Conclusion number 3: Make Lottie your native animation tool.

Data accounting

Native apps, by their very nature, need to fit the content across the width of the screen. This is why it is important to consider long and odd data when designing a user interface. It is still common to see a custom design that cannot accommodate the data it was intended for.

In the shot below, we have popular exercise courses with short titles. However, if the After running tensile course were popular, there would be no way to write its name on the tile. There is no room for an extra line of text, and if truncated, “After runn …” has zero meaning to the user.

Successful iOS design

Exercise app has little space for popular course titles [источник]

This is not immediately clear, but the same problem can be applied to user-generated images. Let s take a look at an example snapshot that represents a user profile with a collapsible profile bar.

An example of a social application with user photos displayed in a non-fixed aspect ratio [источник]

To understand a potential problem, imagine you are uploading a profile photo to your favorite social networking application. The app will most likely allow you to crop your image to fit well with your design.

Unfortunately, the presented user interface changes the aspect ratio of the photo depending on the height of the device. A photo that might work great for your iPhone SE might not crop well on your friend s iPhone 8 Plus.

Conclusion number 4: Experiment with odd and long data and don t let it break your design.

“Endless Shows”

Imagine a list of items displayed in a native app. This could be the Settings app on your iPhone. We know that there are only 5 types of settings for all users, and this will never change with any action.

However, the list can be, for example, a contact list. In this case, we do not know the number of items in advance. It changes over time and is different for each user. We can potentially have an infinite number of contacts, so let s call this kind of list an “infinite view”.

Infinite View looks standard, but the iOS developer has to code it differently. Although it can have thousands of list items at any scroll position, the number of items that can be displayed at one time is limited. This is why reusable views are used for performance.

Successful iOS design

Reusing cells in iOS [source]

The problem with infinite views is that interactions are even more complex and more limited. They also take up all of the scrollable space, so it s best to isolate them on separate screens.

Consider the shot below. It has two “infinite views” side by side, which is nice, but it also shows drag and drop animations between them. Its implementation can take much longer due to “endless representations”.

Drag and drop between two “endless views” [источник]

Conclusion number 5: Isolate potential “endless views” on separate screens. When in doubt, always try to check with the developer first.

Design you can bring to life

You, as a designer, should make it easier for iOS developers to implement your projects. The easier it is to develop, the faster the app will get into the AppStore, which will make your client happy.

What s more, by following these guidelines, you can spot potential interface pitfalls, saving you the trouble of redoing the same design over and over again.

If you are wondering how expensive design errors can be, take a look at the second part of this post, where I provide estimate real costs for a range of designs with Dribbble!

about the author
Jakub is an iOS architect at EL Passion. You can reach him at Github, Twitter or in his blog

Official Pages EL Passion in Facebook, Twitter and Instagram

Thanks to Sona Kerim.

Leave a Reply

Your email address will not be published. Required fields are marked *