2. UI Styles for UI 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
4. UI Styles implementation
The best 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 components only 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 Run time 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 over Frame-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 UIAppearance for 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 IBActions should 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
Try to 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 by Apple 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 private Apple 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"
