I can teach you the basics of UIKit in 2 hours 👩🏽‍🎓👨🏻‍🎓

Hi 👋

If you’ve picked up iOS programming in the last couple of years, it’s possible that you’ve only ever worked on projects that used SwiftUI.

And now that you’ve reached a good level of proficiency with SwiftUI, you might be wondering:

Is it time for me to deep dive into UIKit, to increase my iOS skillset?

Personally, unless you know that you’re going to need to use UIKit in the near future, I wouldn’t recommend that you spend countless hours to deep dive into every details of the framework.

Our time, energy and focus are limited resources, so spending them to acquire skills that we don’t really need right now is a risky choice.

However, I do think that it makes a lot of sense to spend a couple hours in order to learn the basics of UIKit: this way, the day you actually need to dive deeper you will already have some initial knowledge 😌

And that’s why last week I did a livestream with this exact goal in mind!

So how about I walk you through what this livestream will teach you?

#01 – The structure of a UIKit project

The first time that you create a UIKit project in Xcode, you’ll notice that the files it contains are quite different from what you would get with SwiftUI.

You’re suddenly faced with an AppDelegate, a SceneDelegate, a ViewController and a couple of .storyboard files.

While they can seem daunting at first, each of these files actually have their SwiftUI counterpart.

So we’ll go over them one-by-one, to understand what each of them does and what’s their equivalent in the SwiftUI realm.

#02 – Implementing a screen with a Storyboard

UIKit is, as its name does suggest, a UI framework: so how about we use it to implement our first screen?

We’ll start with something basic and implement a simple list that fetches and displays data from an API.

And we’ll do it using what’s called a .storyboard: a special kind of file that allows us to define our UI using a tool called Interface Builder.

#03 – Implementing a screen programmatically

Now that we’ve learned the basics of implementing a screen using UIKit, we’re going to increase the difficulty a little bit!

This time we’re going to implement a second screen that also displays data from an API, but this time we’re not going to use Interface Builder.

Instead, we’re going to define our entire UI, including the constraints that layout our views, entirely in code.

And we’ll see what are the drawbacks and the benefits of this approach, compared to using Interface Builder and a .storyboard file.

#04 – Customizing the launch of the app

When you create your first UIKit app, Xcode puts in place some nice mechanisms that automate the way the app launches.

While these mechanisms are useful, they can also become quite limiting when you want to have full control over the architecture of your app!

So to conclude this discovery tour of UIKit, we’ll see how to disable these mechanisms and gain full control over our app’s launch process 👌


And that’s it! Once you’ve covered these 4 chapters, I think it’s fair to say that you’ve gained a pretty strong knowledge over the basics of UIKit.

But if you’re still curious and you’d like to keep learning more about UIKit, don’t worry I’ve also got you covered!

I can recommend that you watch this other livestream, which reuses the same codebase to discuss architecture best practices in UIKit apps 😌


That’s all for this email, thanks for reading it!

If you’ve enjoyed it, feel free to forward it
to your friends and colleagues 🙌

I wish you an amazing week!

❤️

Previous
Previous

Do you know what .layoutIfNeeded() actually does?

Next
Next

Be careful when using .onTapGesture()