iOS UI best practices

iOS UI best practices

• 1.
  UI Best practicesin iOS
• 2.
  UI Styles forUI Elements with Designers The best way to start a new project is to establish styles and components with UI Designers, which would be the same on both platforms and Design. It means that UI Designer won't add a new label with a slightly different grey shade into the new screen. All the components he can use should be from UI Styles. If there is a necessity to add a new component, he will need to notify the developers, so they will add this component into UI Styles in the project. Advantages: • This will save the developer from wasting time on UI details because he will use pre-created UI Components • All screens will be consistent. All buttons of one type will have the same corners, press states, and title colors • If the designer makes a decision to make a change in one of the components, it can be done by simply changing a couple of lines in the code in one place
• 3.
  UI Styles example
• 4.
  UI Styles implementation Thebest way to implement UI Styles is by creating UI Style Classes for each of the components, which can then be set in .storyboard or created in code. Try to avoid changing styles outside those subclasses, including .storyboards and .xibs. This approach will help keep all of the styles in one place and provide a quick change of the same component all over the project.
• 5.
  Reuse UI componentsonly if they are identical If you have two components that look similar but have slight differences, for example, text color or additional image, it’s better to create separated components. This will help to ensure that if you change something in one component, the same component with a slight difference won't be broken in another place. UIView1 UIView2
• 6.
  Don't use Runtime attributes in interface builder Run time attributes advantage is that you can set some properties in interface builder rather than in code. The problem with this approach is that if you change the name or the type of a property you use as the Run time attribute, and you forget to change it in interface builder, you will never know in a build time that something is wrong. You will have a crash on a screen you use it. The best place for UI attributes are Subclasses for UIComponents.
• 7.
  Auto Layout overFrame-based layout Try to avoid the calculation of the frame in code. Even though Frame-based layout works faster than Auto Layout, eventually, you will have problems with the broken layout if you have frame calculation in code. It is a rule for table views as well. Use UITableView automaticDimension for tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) method over precalculates size.
• 8.
  Use UIAppearance Use UIAppearancefor general styles, like brand colours for navigation bar and UI controls. UIAppearance allows the appearance of views and controls to be consistently defined across the entire application.
• 9.
  IBOutlets and IBActionsshould be private When you add a new UIView or UIViewController, all @IBActions and @IBOutlets should be private, so you won't be able to change them from outside. This approach will reduce the number of unexpected behaviors like someone changed the style or the text of a Label from outside the view, and you can't find where or who did it. Also, this approach will reduce build time for the file in swift. Use setup() or config() functions with all parameters you need for this UIView.
• 10.
  Avoid magic numbers Tryto avoid direct usage of a number in the code, because after some time you could forget what this number means. The best solution is to set a private constant in a class with nice name, which will explain what this constant will be used for.
• 11.
  Use provided byApple API only to change Apple UI components If you want to customize Apple's UI component, but you don't have API for that, you should create a custom UI component. It is bad practice to iterate through Apple UI components' subviews to make a change for one of them. The structure of UI elements provided by Apple can be different in different iOS versions. For example, if you have UISlider and you want to add dots to it to indicate exact values, you shouldn't change UISlider, as Apple doesn't provide API for that. You should create a custom UI component for that use. The problem with changing UISlider is that hierarchy of a UISlider can be changed in future iOS versions, and your component will work unexpectedly. iOS 13 iOS 14
• 12.
  Don't use privateApple API for UI Changes This is another way to making changes to Apple UI components without public API for that. Using Apple private API can lead to rejecting the app from the store. Also, the private API can be different in different iOS versions, so your application may crash when a new iOS version is released. As an example, on iOS 11 and earlier, if was a problem to change placeholder color for UITextField, so developers used private Api using KVC for that. setValue UIColor black “_placeholderLabel.textColor"