Create your own UI? Things you need to know when customing UI in iOS

Tram Ho

Hi everyone, thanks for visiting this article. I’m Huy, an iOS developer.

This article was written with the purpose of sharing my experiences and opinions on a very familiar topic that probably every iOS developer has been and will have to do, which is custom UI.

We programmers often see this as a basic problem and everyone can do it. But in real life, I find that people encounter a lot of problems with custom UI. I myself have not eaten many times because of it.

The following article provides my views and some tips on this issue, to help you navigate the complex UI.

What is a custom UI?

First, I need to make it clear to you what custom UI is all about.

The custom UI that I mentioned in this article is that we inherit Apple’s existing UI classes to be able to refine and add to the capabilities we desire. From there create a new UI class that we can reuse elsewhere.

I want to make this clear because the actual “custom UI” sounded a bit misleading, and some would argue that the build of the screens is also custom UI. Although it is somewhat true but I do not mean that. First is that!

When do I need the custom UI?

Obviously, if our problem only needs to use the UIKit default UI to solve the whole problem, then we do not need to go custom UI to make it tired. In fact, UIKit UI classes have already given us the ability to customize a lot of things already. So when do we need to go custom UI?


This is the most common reason when we choose custom UI. Because almost every app will have similar UI elements.

You could say, “I need a custom UI because I want to add this feature and that, build a complex UI and all that,” but in general, we all do that because we want to reuse it.

If created without or cannot be reused, it is meaningless to customize your UI. Because in fact, all the logic you create for that custom UI can be handled in ViewController. Except for the second reason I mentioned below.

Catch View’s Life Cycle events

If using Auto Layout, I think we all have at least once wondered when the layout will be finished? Because we need multi-screen processing, we need to corner based on the final height of the view, we need to calculate the length of the cells with dynamic height, …

Someone waits for viewDidAppear() before starting to process the logic, someone calls view.layoutIfNeed() right in viewDidLoad() … All are wrong views, view.layoutIfNeed() and easy to cause Unwanted side effect.

In fact, there is no time in UIViewController’s Life Cycle that the entire View has been laid out. If you use UITableView with dynamic cell height, where the tableview scrolls, everything is laid out there.

Therefore, the only logical and radical thing you can do is create a class that inherits UITableView, UIView, … and then overrides its layoutSubViews() function. This function will be called many times, and after each call, everything has been redesigned.

Or you need to catch events related to init , deinit , didMoveToSuperview , … of the view. Then it’s time you need your custom UI.

How is Custom UI?

Vegetarian code

If you need a custom UI with lots of subviews and complex layouts, this is an option I don’t recommend.

But if we only need to intervene to tweak the UI, this is a standard way of doing it, we do not need to create more XIB to do for the headache. Try looking at the following examples:

An ImageView with the ability to round itself to any size, we need to customize the UI because we need to intervene at the moment this view is finished layout.

A UITextView cannot be used normally but must be adjusted to the height of the editing cursor. We need to intervene in the View’s Life Cycle and cannot do this just within the ViewController.


This is a great choice when you have a lot of subview with complex layout. Unlike subclassing UIKit classes to refine the UI, this is a way for us to build and combine subview, thereby creating a new view on demand.

Implementation is also quite simple. I have an example of a MiniPlayerView as follows for your easy visualization.

We created 2 corresponding files, swift file is inherited class UIView and xib file is also view xib format.

Next, we set File’s Owner to the xib file as the corresponding swift file.

In the file MiniPlayerView.swift we implement some necessary code:

The next thing is to drag the UI, constraint the XIB file, and attach the events to its File’s Owner, hehe 😌

Next is bringing events outside of ViewController, but there are many ways but I usually use delegate mechanism

What do you need to keep in mind?

Reading is one thing, doing it is another. Before you implement the custom UI, you should know two things below

Understand how parent classes work

When you plan to refine a parent class such as UIButton, UITableView, … You need to understand how these classes work. Because unlike a pure UIView, these are classes that have been put in a lot of complex logic and whether we override or set state can affect the parent class’s parent operation.

However, in reality, UIKit is a closed platform, docs is available but cannot cover all cases. Therefore, the study of parent class activity is completely dependent and tested, improvised and personal experience. So this problem he did much more wise, less buggy, less side effects, less crash.

Do a lot and try on yourselves.

Understand how View’s life cycle works

In this section, Apple has a fairly long page for us to read and research: UIView

Just like understanding the operation of the parent class. Knowing how the View’s life cycle works is essentially understanding the basic operation of UIView, how overriding basic functions and properties will affect UIView, …

Remember to carefully read the above document because one thing is very practical that doing iOS, the biggest job is to assemble the logic associated with View smoothly.


Hopefully the article has brought you useful knowledge, if you find it interesting, upvote and follow your channel to not miss the great posts!

Share the news now

Source : Viblo