Hallo collega’s, Leo Hier. Building user interfaces in iOS with Swift is a great theme, and today we will have a long discussion about it.
This is the third part of my series “How to start iOS Development Career”. If you didn’t read the introduction and part 2, I would strongly suggest doing so.
The journey I’m telling in this series is progressing toward being a junior iOS developer. My goal was to begin a career as an iOS developer and this was my third step.
If you got here, keep in mind that a really hard chunk of your problems is already solved. This means that you can with some fluency read any Swift code you find on the internet, which enables you to see most of the solutions for your following problems by yourself.
So today I will describe my process of learning how to build interfaces in iOS. No more talking and let’s go! But first…
Painting of The Day
Today I chose a 1918 masterpiece called Harlequin from the legendary Spanish Master Pablo Picasso. He was a Spanish painter, sculptor, printmaker, ceramicist, stage designer, poet, and playwright who spent most of his adult life in France. Regarded as one of the most influential artists of the 20th century, he is known for co-founding the Cubist movement, the invention of constructed sculpture, the co-invention of collage, and the wide variety of styles that he helped develop and explore.
Cubism is an early-20th-century art movement that brought European painting and sculpture historically forward toward 20th-century Modern art and its various forms inspired related movements in music, literature, and architecture. This movement has been considered to be among the most influential art movements of the 20th century.
I chose this painting because I think Apple UIKit developers are cubists, I mean… All views have a rectangular frame.
The Problem – Building User Interfaces in iOS
You know how Swift language work and now it’s time to learn how to build a screen.
At the time I started my journey to be an iOS developer, I was working as a service delivery manager in a fintech company. In my team, I had a lot of iOS developers to talk and one of the questions I made to them was: “How can I build interfaces in iOS?”. They promptly answered a lot of o things but one stuck in my head – You should learn view code.
Ok… So they are saying that I should learn `view code` but what is that? Is it a framework? A lib? A technique?
Right, I need a plan. The first thing I thought of was to learn “how to build one screen” and then I would need to learn what I called at the time “How to connect screens”, but now I know that was just “How to navigate through the app’s screens”.
Nowadays, there are many different ways you can build a view, they are split into two big groups:
- Using Interface Builder
- Build programmatically
Next, we will deep dive into each of those groups.
Building Interfaces using Interface Builder
This is the most “user-friendly” experience building interfaces. To build your interfaces you use the interface builder that has a lot of visual tools. The interface builder has a lot of pre-made components that you can just drag and drop into your views and everything simply works. The main approaches to using Interface builder are using storyboards and XIBs.
Storyboards, usually, have all the flow of your app in one single file. I know that you can have multiple storyboards but when you do that you are closer to the XIB solution than the storyboard one. It’s good because you can have a bigger picture of all of your app screens but it is bad because it is slow when became big and it is virtually impossible to work in a team using it because of merge conflicts.
On the other hand, you can have XIBs which are XML Interface Builder files. In this technique, each of your screens will have a XIB file that describes it. I already heard from developers that this is the best of both worlds – is the best for beginners and also has a relatively low maintenance cost.
The advantages are: Creating views and flows like this enables the developer to quickly check what the screen looks like not only on one device but you can create an interface on iPad and iPhone with really ease. The learning curve is not steep and it’s really amateur friendly.
The disadvantages of this approach start when you begin to work with teams. Storyboards are not a friend with git, the simple act of opening it in Xcode changes the code and the merges are virtually impossible. When you use XIBs the merging problems are mitigated.
Building Interfaces Programmatically – View Code
Here is where things start to be less beginner-friendly. When you build your layout entirely from code, you must already have some knowledge of what each of the UIKit objects is because you don’t have a native way to show the screen you are building on the project. With some UIViewControllerRepresentable and SwiftUI we could check what UIKit is building but you know what I mean also there are other external tools that enable live preview for UIKit but are not the scope of this article.
Building interfaces programmatically is what my friends from work called “view code“. Because all the views would be in the swift code not in an Apple-generated XML like the storyboards.
To build interfaces programmatically you have plenty of options. They also split into two big groups: UIKit and SwiftUI. Let’s enumerate how you can build your layout with UIKit:
- You can use the old school visual format language . Don’t waste your time with this nowadays.
- Using Auto Layout constraints
- Building Auto Layout without constraints, yes that exists.
- Using Frame-Based layout.
- Use Metal Framework to build your interface (mostly for games).
All the alternatives above are imperative programming techniques and it is not the scope of this article to explain each one of those.
Imperative programming means you are always telling the Views how you want them to behave on the screen, this way you have total control over your layout. Almost everything that you can do with “view code” you can also do with XIBs but when using programmatically UI you can work in a big team that merges conflicts that are possible to handle.
The swift files are faster to open compared to the storyboard ones this way the maintenance can be less stressful for the developers. Imagine each time you need to open the storyboard file it takes 8 seconds to open, it is not a great developer experience.
Animations can only be implemented in code. If you ever want to your code be animated, you will need some sort of view code even using storyboards/XIB solutions. I like animations so this was one of the selling points for view code to me.
The disadvantages are that you cannot easily see the result of your interface and has a steeper learning curve for beginners.
I would say that programmatically interfaces for me were easier to learn than using interface builder because I was a java developer before getting into iOS development.
A new challenger appears: SwiftUI
On the other hand, you have the shiny new SwiftUI. As Apple puts it: SwiftUI uses a declarative syntax, so you can simply state what your user interface should do. For example, you can write that you want a list of items consisting of text fields, then describe the alignment, font, and color for each field. Your code is simpler and easier to read than ever before, saving you time and maintenance.
I can agree with all that definition. Being a declarative syntax helps beginners and even people that are not developers to easily build their interfaces and get fast prototypes up and running. Worth mentioning that as this is the new way Apple going in the building interfaces area so is expected to be the norm in the future. If you are looking for something like that, go for it.
The disadvantage of SwiftUI is how new is it. You don’t have everything available right away, and sometimes you will need to use UIViewRepresentable to express something that you only can do in UIKit. I don’t think that is a big problem but is something you should keep in mind.
To compare a code in UIKit and SwiftUI. See below a how-to you can list things in UIKit:
final class MyListViewController: UIViewController, UITableViewDataSource {
private let numbersList = ["1","2","3","4"]
private let tableView = UITableView()
override func loadView() {
view = tableView
tableView.register(UITableViewCell.self), forCellReuseIdentifier: String(describing:UITableViewCell.self))
tableView.dataSource = self
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
numbersList.count
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
guard let cell = tableView.dequeueReusableCell(withIdentifier: String(describing: UITableView.self)) else { return UITableViewCell() }
cell.textLabel?.text = numbersList[indexPath.row]
return cell
}
}
And this is the same code in SwiftUI:
struct ListContentView: View {
private let numbersList = ["1", "2", "3", "4"]
var body: some View {
List(strings, id: \.self) {
Text(string)
}
}
}See the blatant difference? On UIKit you have to specify everything that is going on on the screen, on SwiftUI you just say: show this list with this text.
UIKit or SwiftUI?
Now you know all the ways you can build a screen with Apple platforms, what to choose? Should you learn SwiftUI or UIKit?
In my honest opinion, it doesn’t matter. I see a lot in the community saying: I made this thing with SwiftUI or I don’t use storyboard in my app, for me the thing you are using to build the UI is completely irrelevant.
Here we should think again about our goal. Our goal in this step is: to learn how to build the App interface. If it will be a storyboard, view code, or SwiftUI in the end what matters is if your app is good for your user. Do you think the user is impacted if you use SwiftUI over UIKit? Of course not.
Now you could be thinking: “I want to work as soon as possible, so I’ll study UIKit because it is easier to get a job!”, well that’s not true. I bet with you that if you have solid basic knowledge of any iOS UI building paradigm you will for sure get a job. You need to have good basic knowledge and be smart and honest in your interviews about what you know and what you don’t know.
Whatever you chose, go for it with all your power that is what really matters. In the future, when you have more experience as a developer you can learn new UI paradigms, and I assure you that will be easier than learning for the first time.
In the end, this is totally up to you to decide. If you want to work with UIKit, study UIKit. If you want to work with SwiftUI, study SwiftUI (and a little bit UIKit too). I don’t think I could recommend studying one over another because at the time I’m writing this both are valid answers and I can see myself writing code for both in the future.
My final advice between this fight is, if you have time, study both but chose one to master. This decision is only relevant because depending on what you decide you will change the learning resources, which is the next topic of this article.
Resources I used to Learn Building User Interfaces
Again I’ll recommend free sources and say what I did to get the knowledge into my head.
If you want to go with UIKit/Storyboards, I recommend the Paul Hudson’s 100 days of Swift. It’s a great overview for all amateur iOS developers. Just do it all and for sure you will have a really good take on how to build interfaces with UIKit and storyboards.
After you did the 100 days of Swift, I would recommend you the Sean Allen’s course Take-Home project. I took his course and was great for me at the time. I learned a lot of view code, his didactic is amazing and got my head into view code. And extra points to help me organize my take-home project.
That is, I use those two to learn interfaces. But what if you want to learn SwiftUI?
Well, when I will begin to learn SwiftUI in the right way my path should be:
1. Complete the 100 days of SwiftUI, another free course by Paul Hudson.
2. And the deep dive with Thinking in SwiftUI by the brilliants Chris Eidhof and Florian Kugler.
Can you spot the pattern here: first I always search for a really good free resource for the knowledge I’m seeking, after that, I can buy something because I’ll already have a good base on that subject and I can make more dollars for my cents. I never bought a course that I hadn’t already had a good ground knowledge about the subject.
Let’s move to the second question about creating interfaces. Changing from one screen to another.
Creating a Navigation Flow
Now you know how to do one screen, but how to create a navigation flow between them? Well again here you have some options. Although one could argue that you can do everything in one ViewController, just changing the root view for new screens, we must agree that this is not the best user interaction and easy to maintain a flow that exists.
The resource that I used to learn is also the Paul Hudson’s 100 days of Swift. In the course, you learn how to present views as modals, how to push views from view controllers, how to navigate to the root view, and so on. The course is everything that you need to learn about basic app navigation.
Learning how to present or push views on the screen is the initial part of your path to master flows. Later you could learn Router patterns or Coordinator patterns to extract that behavior of your ViewControllers and put them where you can organize them well.
Although is very cool to present and push news views to the user, making another view appear isn’t enough, you need to know how to pass data to new screens in the flow.
Sharing Data Between Screens
To share information between views you will need to learn a pattern. You will pass by initialization of the objects, or by delegation, or by dependency injection frameworks or doing your own dependecy injection solutions.
All of those techniques have been used in specific cases, so be careful to not be overwhelmed with a lot of information. The main thing I would aim for would be: how to make a to-do list app. If you can understand that app, probably you have all you need from the sharing data between screens that you need.
You will need to learn to pass data from one screen, this is a non-optional skill. Don’t need to worry to learn very deeply but you need to learn the basics.
Practice Building Screens
Is no secret that you will need to have muscle memory for a lot of things in iOS. For that especially, in the beginning, is important to practice as much as you can building screens. Pick up simple designs and try to recreate them with your recently achieved interface skills. Some suggestions for practicing:
- Login screen
- List screen that opens details of each item.
- Collection of photos from the camera.
- App with three tabs
- Image with a button at the bottom that opens another screen.
Use your imagination to practice. At the time, I was practicing at least trying to do 1 UIView per day. If that is too much, try at least do one per 3~5 days so you don’t forget the basics you learned.
Summary – Building User Interfaces
In the article today we dedicated time to explaining all the types of UI you can make using Swift at the time I write this article. Remember that all information here is just the tip of the iceberg of information that one needs to really be a master screen creator. This was my process and maybe helps you either.
I hope I was clear about the discussion UIKit vs SwiftUI and why that is not relevant in the bigger picture. The most important is you being comfortable building new screens, that being on UIKit, SwiftUI, or whatever Apple brings up in the future.
That’s all my people, I hope you liked reading this article as much as I enjoyed writing it. If you want to support this blog you can Buy Me a Coffee or leave a comment saying hello. You can also sponsor posts and I’m open to freelance writing! You can reach me on LinkedIn or Twitter and send me an e-mail through the contact page.
Thanks for reading and… That’s all folks.
Credits:
