iOS Application design from developer’s perspective.

Andrej Malyhin
2 min readAug 23, 2016

--

One experienced designer once told me that UI is more of a process rather that still structure. It’s always changing. It’’s naturally inconsistent. And it is complicated to make. So UI seems to be a natural enemy of clean and structured code.

If you are good iOS developer you designing code that easy to change. It means that if you need to change something that appears in many places in your app you will change it in one place in your code. What tools do we have to make it happen?

First of all we have UIAppearence which is an ultimate yet not flexible tool. It works best for some UI elements that don’t have more than one style like UINavigationBar or UITabBar. But still if you need to change the color of your navigation bar in just one controller (some modal view, perhaps) you need to override this directly in UIViewController. Little by little your code will be populated with this small hacks which make it painful to maintain and change quickly. It is also leads to various bugs.

Since we know that UI elements in applications belongs to groups with identical appearance (let’s say all UISwitches) we can make some use of it. Probably we can create some library of UI controls that are used in our application. UIButton subclasses for similar buttons and reused UITableViewCell’s siblings. As long as you can do it without inheritance and complex hierarchies of classes it works fine. (You know that inheritance could be your worst nightmare, don’t you?). But that’s a lot of code.

So we decided to spend some time on creating something that:

  1. will allow us to use system classes (so we don’t have to keep a lot of things in mind).
  2. will require less code.
  3. and will be simple.

After spending some time with my colleague we came up with idea of applying styles for UI elements. Each system class will have a predefined set of styles and all you have to do in your UIViewController is apply it. If we need to add another style it won’t affect any other elements, and changing styles happens in one place.

Let’s dig into some code shall we?

As long as we are writing in Swift and following Apple’s advice on protocol-oriented programming we start with a protocol.

Pretty simple. It’ only defines a function that performs styling. So we decided to add another protocol and extension to it with default implementation. All UI elements that need to be styled (we don’t have to style everything of source) will adopt that protocol.

We hope this makes sense to you.

Here is an example of UILabel styling:

And using it in your code is really simple and doesn’t take a lot of time:

If you find this approach useful give your credits to my awesome colleague @EdPanasiuk who made this workable and me @ankoma22. Reach us on twitter for questions.

--

--