Apple always has, through every one of its systems and platforms, made a major focus on interface design and user experience, and its users have come to expect it. So, if you want your Apps to succeed in the App Store or just make a great iOS App in general, this definitely is one of the key areas to concentrate on. Luckily, Apple has provided some general guidelines on how to design a good interface, and here we will go over the most important of them and provide some examples at the end to complete this post. Everything goes with the principle of “simple is better” and being minimalist, so even if some things seem kinda evident, remember that the secret is in the basics.

General design

There are a couple aspects of an App that any mobile developer should know before starting to even think about coding and designing. Users will most likely decide if they like your App or not after just a couple seconds, and every little visual aspect will influence this decision. Mobile users are usually really temperamental with the Apps they try out, uninstalling them just according to their first impression, so you need to make it count.

Knowing this, the first screen is usually one of the key points in your App you want to focus on. As a general rule, the home screen should guide the user to how he should use the App, showing the most important information and giving the user options to go to almost anywhere in your App in an instant. Following this, intro screens that just serve as a purpose to say what the App name and provide a button to continue do not follow Apple good practices. The user already knows which App is the one they opened, and just giving them the obligation to go through one more screen and one more button press to just start using the Application is not a good idea. Remember that they will see this screen every time they open it, specially the first one, and you do not want their first opinion to be “how annoying this is”.

Another aspect of design that has to be kept in mind is how or if you should prompt the user to rate your App. As a general rule, prompting the user to rate your App is a bad idea. Developers usually do this on impulse, since if you ask the user to do it you will most likely get more rates on the store, and this can in turn improve its position, but that is just one side of the coin. Remember that your user first wants to use your App for one purpose, and that is not to rate it. If the user is constantly asked to rate an Application, he will most likely start getting angry with this message, or just ignoring it completely depending on how intrusive it is. And, in the worst case, you do not want an angry user to be the one that reviews your App. 

Stylish choices are good (and sometimes necessary) for some Apps, but remember that it should not in any way hinder the core purpose of your App. If you do “something” that makes your App look a little bit nicer, but it makes the App a little harder to use or a little more frustrating, it probably is not the best of ideas. 

Another aspect of general design is to adjust to as many conventions as possible, especially when related with functionality. Apple provides many types of buttons and button images to guide the user to what each button does, and developers should really try to adjust to this. For example if the users sees a trash icon, he will assume this is for a delete functionality, as well as if he sees a curved arrow pointing to the left it most likely that corresponds to a “reply” action. UI is the best way to guide the user in your App, and a UI design that does this in the best way is one that follows UI conventions.


Chances are you will want to show many options, test, or possible actions in one screen. However, this can potentially be confusing for your final user if it is not organized properly. Luckily for us, Apple already fixes some of this issues by providing controllers and some minor restrictions to UI elements (like how the Tab Bar is at the bottom), ensuring they are used in a common and structured way.

However, many other options are left for us developers and designers, and a little thinking on the general layout and positioning of elements can go a long way.


To start with layout, it is important to understand that screen space is one of the most important assets the UI designer has, and should be used thoughtfully. This does not mean you should just fill the entire screen or leave everything in one corner. Empty or background space is an indispensable tool on design, and almost a necessity for the user to not be overwhelmed with information. 

Following this concept, things that just take up space for the sake of being there (like borders to your application) should be avoided. There may be some exceptions to this general rule, but unless you have a really good reason you should follow it. Although users like to see an appealing design and feel comfortable, it can annoy them to focus on a smaller screen that the one they could use if that border was not there. A clean appearance is usually the best appearance. 

Another aspect that should be considered is where the different elements are positioned inside the screen. The first rule here is a somewhat easy one, but sometimes forgotten in favor of stylish design. Always remember to highlight the most important functionality. When a user reaches a screen in your App, chances are you have a pretty good idea as the designer to what he wants to do or where he wants to go next. As such, the thing that is most likely to be needed should be at the top and highlighted with some color, image or with another method.

Imagine you have a really long scroll screen, and the option you almost always want to press is at the bottom. The first time you see this screen you will need to read everything before finding what you were looking for, and all the following times you need to keep scrolling to the bottom even if you know exactly what you want. Design should follow the desired functionality, and not the other way round.


Let’s stop a little bit know with one of the most common elements in UI, buttons. Buttons are almost a necessity for development if we want the user to select when he is ready to perform a certain action or follow a determined flow. How the buttons are visually can vary from App to App, maintaining the general Application aesthetic, but the important part is that it needs to be focused on its purpose. Buttons are for being pressed, and therefore should be easy to press. This section also applies to any other UI element that is meant to be pressed.

In order to achieve this, there are a couple of basic rules that should be followed:

  • Buttons should be big enough for the user to press them without missing. Buttons that are too small tend to confuse the user after they try to press them and miss them, not knowing if their touch registered.
  • Make sure buttons have some distance between themselves. Having many buttons next to each other can generate problems if the user misses, forcing the App to do something other than what the user intended.
  • Buttons need to be evident. If you make a custom button and the user does not recognize it is a button, it was definitely not a good design choice.


Text is likely to be prominent in your App, since it is one of the most effective tools a designer has to convey meaning and guiding the user through all options and information. Being such a vital (and somewhat simple) tool, it is important it is as refined as possible.

Some key aspects to keep in mind about fonts are the following:

  • Think about the size of the text in your App. Too small font sizes should be avoided, to make sure the user is able to read all text comfortably (Apple suggests a size of at least 11px).
  • Be careful when considering font color. A key color is recommended, used in your App to draw attention to certain areas. If too many are used the user may be overwhelmed and the attention will be divided in many different areas instead of focused on one thing, which would be the thing the user wants to see.
  • Do not use many types of fonts in any App, except for very specific reasons. Using many types of fonts will confuse the user, and direct his attention almost randomly through each screen. Also the user will need to adjust every time the font changes to understand it. This is likely to cause frustration and rejection towards the App.

If the user feels comfortable reading what you have to say in your App, it is much more likely he will keep using it for longer. Obviously no one is going to use an Application just because it has some nice fonts, but someone can easily uninstall it if he finds the visually shocking. Remember that mobile users are prone to delete an App after just a couple of seconds if they do not find it nice.


The last aspect we will cover in this post is the importance of notifying the user about what the Application is doing in the background. Mobile applications have many reasons to take some time before finishing a process. Motives can range from fetching data remotely to heavy algorithms run on not so powerful devices. This cannot be always avoided, but it may not be so bad for the final user if done correctly.

The first thing is knowing approximately how much time a given process will take. If it is an immediate action, and the user will be immediately informed that the action ended (like with navigating to another screen or removing a field) this is not so important. In fact informing him something more in this cases can be actually confusing for them. However, if the action is quick but does not give the user feedback in itself (like adding data internally), the user should be informed in some way, like with a message, that the action has been completed. If not, the user may try doing the same action again, maybe giving more problems than intended in the long run.

On other actions that take a couple more seconds, a little more planning is in order. Hiding buttons after the user has clicked them is a common strategy, as well as showing the default Activity Indicator from Apple. This informs the user immediately that the App has received his input, and is working accordingly. The animation of the Activity Indicator (or any other indication you wish to give them) is key here, since otherwise the user may think the App has frozen.

If the wait for the user is specially long, more powerful actions should be taken. Leaving space for progress bars and finding a way to inform the user before he starts the lengthy process is vital. The user wants to be informed that he will have to wait in order to decide if he wants to do what the App allows him to. If this is not the case, you run the risk of the user closing the Application, maybe even thinking that the App is broken or buggy.

One other aspect that is important to mention when talking about how to give feedback to the user, is that feedback should not only be given on this kind of processes. A way to clearly indicate the user that an option has been selected or that certain mode is in effect is also a necessity. A good example of this is the tab bars that come natively with iOS, since they have a different color and icons for when they are selected as opposed to when they are not.


This were just some of the many recommendations Apple provides for designers, but some of the most important of them. Many of them may be evident to designers, especially to designers with experience, but can be really disastrous if not applied correctly. If you want to see the difference that it makes to follow these or nor, please check our GitHub repository for iOS UI Best Practices.


iOS Design guidelines: UI Design Do’s and Don’ts
Our post of Mobile Best Practices
GitHub link: iOS best practices
Example code: iOS-UI-best-practices on our GitHub