Let’s start by going over a few terms and concepts in SwiftUI.


Views = Layers

The term “view” gets used a lot in describing SwiftUI and this can get quite confusing for designers (and writers). In Sketch and Figma, we use the term “layer” to name the individual elements (text, image, shapes) and artboards. So, Views = Layers.

You will find that individual elements are called views (text, image, etc), a common reusable UI component can be a view, a file will be called a view, and the entire screen is a view. Apple groups these view types as Control, Layout and Other views.


So views are our basic building blocks in SwiftUI, like elements in a design or tags in HTML. Some views a simple contains holding other views, while others need additional content to function. The most important view is View which is the wrapper for your view much like an artboard is the wrapper for your design. The views inside this View component rest between a set of {} curly braces/brackets. We’re going to see a number of views that behave this way. The curly braces form a group of sub-views. Besides View, we also have List, the stacks: VStack, HStack and Zstack.

The Stacks can also have settings or attributes that are optional. Unlike the Stacks, there are some views that must appear with the () parentheses after them, but some don’t always need content inside the (). The content inside brackets are the attributes, and they help tell the view what to show.

Attributes & Modifiers

In the case of the Text() view, there is one attribute, the text content. This can be edited in the Inspector panel text input field. It is easy to change the words on screen to “SwiftUI rocks!”, simply edit the input field text. Once you update the Text content, the code will automatically be updated. Other view elements have more attributes for finer control, and we’ll discuss those later.

As a rule of thumb, the attributes appear inside the () parentheses, and modifiers can appear inside the () or after the (). Modifiers start with a . character (period or full-stop). Some views require a default attribute, while others rely on modifiers. Text() needs text to work, but the Spacer() view can appear without an attribute (it has only one available attribute, minLength, which is a number telling SwiftUI what the minimum number of points will be used for either the height or width of the spacer). The Divider() view currently has no attributes.

We know the Text() view needs text as an attribute, and you can modify the text style by adding additional modifiers, each on its own line and beginning with a dot. For example you might wish to style the typeface of the Text() view by including the .font() modifier. The .font() modifier requires attributes, and some of the options already available in SwiftUI include Apple’s standard text styles which you also declare starting with a dot, for example .font(.largeTitle) sets the text to system default typeface in 34 points over 41 points of leading (in the Large (Default) type size. The HIG has a handy chart for all the built-in text styles based on the type size setting on the device.

Modifiers are more important for changing the look of our Text view. The Inspector panel contains controls for changing the Font (which is called the Text style in Figma), Weight, Color, Alignment, and other modifiers that affect the text shape of the Text view including padding and the frame size. We can also add more modifiers that aren’t yet visible on the Inspector panel, which is discussed below.

By default SwiftUI uses system fonts and colors which are detailed in the Human Interface Guidelines. We can customize these aspects later, but for now we’ll stick with the default HIG styling.

The Human Interface Guidelines are a valuable resource which should be required reading for mobile app designers. Right now I will focus on Typography and Color. To me the best part of each document is the reference table. 


When creating apps that adapt to the customer’s phone settings and needs, you want to stick to using Dynamic Type Sizes. Apple does also recommend the use of the “built-in text styles whenever possible”. The typefaces San Francisco (sans-serif UI font) & New York (serif font used in your iPhone Books app) were created to be most legible on Apple devices. And you can even soften the look of SF with SF Rounded. 

Of course your app will likely want to express its own visual style that fits your brand, and this is possible in SwiftUI, however some consideration is required to maintain the Dynamic Type Sizes. Once you use a custom typeface, you need to include a fixed font size, rendering what was a Dynamic Type size, non-dynamic. This matters for all people using Apple devices, no matter if they have increased their iPhone Text Size to xxxLarge or have turned on the larger accessibility type sizes. Fortunately I have a solution which we’ll explore much later.

In the real world you would not break the accessibility of your app, and you should avoid it in design too. However, for the purpose of a prototype, we may need to break a few rules, or hack SwiftUI to achieve the correct look & feel. Afterall, no one said we were making production-quality code.

Modifying Text

Returning to the modifiers, you can see from the Preview panel that I can pick a font, increase the weight and set the text color. You may have also noticed that each modifier gets added in the code editor. This allows us to explore what other options we have in Xcode before having to start typing code.

I can turn on the Padding and set a value—my Text view has grown bigger as a result. We need to be careful with the Frame sizing as this will create a fixed size. Leaving default values will allow the view to adjust to its contents. Also, you will find Padding and the Frame will mix oddly.

Add modifiers

The Add Modifier drop down allows us to add even more customization. The dropdown contains every modifier available, including ones not applicable to views like Text. We can experiment and see what works. For example we can add the background modifier. This will give us a dropdown of the default system colors, plus the ability to use a custom color.

Selecting this option will insert a piece of placeholder code in the editor, however selecting Custom a second time will bring up a color picker so you can manually pick a color or enter the RGB values. By default SwiftUI is declaring the RGB values between 0.0 and 1.0, translating 255 to equal 1.0. While you can set the values for the additional modifiers in the inspector panel, they remain highlighted in the code editor.

© 2024 SwitftUI Prototyping