Your First iOS & SwiftUI App: An App from Scratch

Feb 13 2023 · Swift 5.7, iOS 16, Xcode 14

Part 1: Getting Started with SwiftUI

06. SwiftUI View Modifiers

Episode complete

Play next episode

Next
About this episode

Leave a rating/review

See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 05. SwiftUI Views Next episode: 07. Objects, Data & Methods

Get immediate access to this and 4,000+ other videos and books.

Take your career further with a Kodeco Personal Plan. With unlimited access to over 40+ books and 4,000+ professional videos in a single subscription, it's simply the best investment you can make in your development career.

Learn more Already a subscriber? Sign in.

Notes: 06. SwiftUI View Modifiers

Apple’s Human Interface Guidelines

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

All right, at this point, we've created the bones of our user interface. Right now we're using the default style for our SwiftUI views, which is quite plain and that's a great starting point but this doesn't look very much like Luke's design so far, does it? What we want to do is modify our SwiftUI views so that they look more like Luke's design. And you can do that through, you guessed it, SwiftUI view modifiers. SwiftUI has a bunch of built-in view modifiers you can use in your apps to modify the style of your views. For example, there are view modifiers to add a shadow, a corner radius or a border to your view. Here's an example of a view modifier that sets the opacity of a view. If opacity is zero, that means a view is fully transparent and if it's one, that means a view is opaque. A setting of 0.5, like you're seeing here is partially transparent. Every time you apply a view modifier like this behind the scene, SwiftUI is creating a new modified version of the original view. You can visualize it like this. First, SwiftUI creates the original text view. Then when you apply the opacity modifier, it creates a new view that is a version of the previous view that is now partially transparent. This is important to understand because you can apply multiple view modifiers in a row like this. Here we've added a second view modifier that adds a red border to the previous view. Now I want you to ask yourself this question, what do you think the border will look like here? Option A is that the border will be opaque, which means it's not transparent at all. Option B is that the border will be partially transparent. Got your best guess? The answer is option A. The border will be opaque. Think back to the rule we discussed earlier. Every time you apply a modifier behind the scenes, SwiftUI is creating a new modified version of the original view. Let's see how this works. First, SwiftUI creates the original text view. Second, SwiftUI returns a new view, that's the original text view but now partially transparent. And third, SwiftUI takes that partially transparent view and now adds a red border to it. The border is not transparent because the border modifier is just adding a red border on top of some transparent text. So order matters. If you did want the border transparent, you should swap the order like this. This time we've applied the border view modifier first, then the opacity view modifier. The result is this time the border is partially transparent. This is because we take some text, apply a red border to it and then make the entire set of text plus border transparent. In this episode, we're going to try out some view modifiers that are particularly helpful for styling text views, kerning, bold, font, line spacing and multi-line text alignment. Here we have Bullseye where we left off in the previous episode and we have the default styling of all of these views in our app. I want to start styling them up, starting with this first text label up here that says put the bullseye as close as you can to. And the first thing we notice about this is that it's bold. So let's go back and add a bold view modifier to this text field. And one way to do this is to click the plus button to get back to the object library and click to the tab where it says Modifiers. And there's a ton of modifiers here. We're modifying the text itself. So we wanna scroll all the way down, and I know this is a long list, until we see the text category and we can find one for bold and then just drag that down to the right after the end of the parentheses for text, and it'll add .bold. I like to put each view modifier on a new line. So press return here to put it on a new line and the preview is already updated to show us the text in bold. So that's looking good. Looking back at Luke's design, you can see that the text is centered whereas all of our text is justified to the left. We can fix this by changing the alignment. So I'm gonna click plus again, scroll down to text and see if there's a modifier that can help. And there's one here that says multi-line text alignment. Again, we can drag this on right after the bold modifier. The default alignment is leading. I'm going to delete that and hit dot instead. And this will show us the different options we can use here. We want center. So with center highlighted, you can press return to select that option. And check it out. Our text is now centered. All right, let's go back to our design. And you can see here there's a little bit more spacing between the lines, a little more than we have right now. So let's see how we can do that. Open the library, scroll down to the text section again and let's choose line spacing. Drag that in under the text alignment. I'll try 10 first, which looks a little too much compared to Luke's design. So let's adjust it and try four. And that seems about right. What about font size? Looking at the Figma file, if we inspect this text, Luke actually used two different sizes here, 24 for the emoji, and then 13 for the text. But I'm gonna break from the design and go with 13 for all of the text here. So let's find a font modifier in the library and add that to the text. Now, you'll notice here that rather than setting this to a hard coded font size like 12 or 14, it's asking us to choose a preset font size like title. This leads me to a discussion of how font sizing works in iOS. You may not know this, but iOS has a system-wide setting called dynamic type that lets you increase or decrease the font size in all of the apps on your device. However, if the app developer, in this case you, chooses a hard-coded font size for text, like say 12 points, then the app won't respect system-wide setting. That can be super frustrating for a user. So instead of hard coding a font size, Apple encourages you to use built-in text styles that they provide, like the title text style you just saw. To help you choose the proper built-in text style, we'll look at Apple's Human Interface Guidelines or for short HIG. You can always get there right from Xcode's help menu. There is even a keyboard shortcut. There's tons of great information for you in here about how to make your apps look and feel native to iOS. It's a great resource, but we're looking for something specific about dynamic type sizes, which we can find under Foundations, Typography and then on the right, Specifications. And there's the chart for dynamic type sizes. You can flip between the various settings a user can pick from up top. So I'm going to pick the text style that is the closest to Luke's design when a user is using the default dynamic text size, which is large. According to the chart, the closest size to 13 pixels that Luke wants is the footnote style. So we'll use that and now we have the proper size based on Luke's design. And this text will resize itself based on a user's preferences. One of the nice things about SwiftUI is you can actually get a preview of what your app would look like if the user selects a different size for the dynamic type size. You can actually preview more than one size at the same time, similar to how you previewed multiple orientations. Click the variance button and then select Dynamic Type. This is a great way to check that your app will still be accessible for folks with visual impairments or people who just prefer larger or smaller text. To get a closer look at any of the previews again, just click on it. Okay, it's looking pretty close to Luke's design at this point but there's something that doesn't look quite right and it's pretty subtle. Do you notice what it is? If you look carefully, the spacing between the characters doesn't match Luke's design. Luke has them spaced out more. If you click on this first text field, you'll see the letter spacing is set to two pixels. Back in Xcode, open the Optic library again with the plus button and there isn't a modifier called letter spacing. Traditionally, in type design, there are two terms to describe the space between characters and SwiftUI has a modifier for both of them. Kerning and tracking. The difference is subtle and honestly, won't matter much in most cases. It will be most noticeable when there are ligatures in the text. If you get into using different fonts or working with a lot of text or translating to different languages, you should look more into the difference. But in our particular use case, Kerning will work just fine. You can search for it in the library just like this by typing kerning into the field at the top and then drag it right into the code. And I'm going to change this from one to two. And we see some nice spacing between our characters now.