Forem: Mateus Rodrigues

Note on SwiftUI Custom Font

Mateus Rodrigues — Fri, 18 Oct 2024 14:17:48 +0000

There's a very important information in Applying custom fonts to text that may go unnoticed:

When retrieving the font with custom(_:size:), match the name of the font with the font’s PostScript name. You can find the postscript name of a font by opening it with the Font Book app and selecting the Font Info tab.

This means that the font name is not necessarily the same as the font filename.

Consider, for example, the Bricolage Grotesque font. If you download it, you will have a file named BricolageGrotesque-VariableFont_opsz,wdth,wght.ttf, but the name that you will use in the code is actually Bricolage Grotesque.

Text("Hello, world!")
    .font(Font.custom("Bricolage Grotesque", size: 18))

You can even rename the file as you wish but you will always use "Bricolage Grotesque" to reference the font.

Understanding SwiftUI: Modifiers

Mateus Rodrigues — Sun, 11 Oct 2020 21:35:14 +0000

Views are lightweight structures that generally have only the body property and intrinsically necessary properties, such as alignment for VStack/HStack/ZStack and action for Button. They are not very customised by themselves and that is when View Modifiers comes into play.

An important thing to undestand is that when we apply a modifier to a View we are not directly modifying it. There is no properties to be really modified . Instead, when a modifier is applied a ModifiedContent is returned, which wrappers the View that we applied the modifier.

let view = Rectangle().frame(width: 100, height: 100)
type(of: view) // ModifiedContent<Rectangle, _FrameLayout>

ModifiedContent is another very simple struct that holds a Content and Modifier to be applied in runtime.

struct ModifiedContent<Content, Modifier> {

  var content: Content
  var modifier: Modifier

}

Note that Modified Content doesn't implement View protocol in its declaration. Instead, ModifiedContent implements different protocols based on the protocols implemented by the Content and Modifier generic properties. This approach keeps ModifiedContent itself as simple as possible while allow its to be extensible.

ModifiedContent implements View, for example, when Content and Modifier implement View and ViewModifier protocols, respectively.

extension ModifiedContent: View 
where Content: View, Modifier: ViewModifier 
{ ... }

ModifiedContent for Scene and Widget are also implemented in the same way, but using SceneModifier and WidgetModifier.

ViewModifer is a protocol which only requirement is a body function.

public protocol ViewModifier {
  associatedtype Body : SwiftUI.View
  func body(content: Self.Content) -> Self.Body
}

Just like Views, most built-in ViewModifiers actually return Never from body function because SwiftUI uses only its properties.

You can implement yourself this protocol to create custom modifiers.

struct CustomModifier: ViewModifier {
func body(content: Content) -> some View {
        content
            .padding()
            .background(Color.gray)
            .clipShape(RoundedRectangle(cornerRadius: 10))
    }
}

All SwiftUI modifiers are internally backed by a modifier function.

extension View {
  public func modifier<T>(_ modifier: T) -> SwiftUI.ModifiedContent<Self, T> {
        return .init(content: self, modifier: modifier)
    }
}

This function is the one that you should use to apply a custom modifier.

Rectangle().modifier(CustomModifier())

Regardless the built-in modifiers, it's worth to mention that although the following pieces of code are equivalent you won't be able to use the last two because _FrameLayout has an internal initialiser.


Rectangle().frame(width: 100, height: 100)

Rectangle().modifier(_FrameLayout(width: 100, height: 100))

ModifedContent(content: Rectangle(), modifier: _FrameLayout(width: 100, height: 100))

There are some ViewModifiers that for some reason have a public initializer, _PaddingLayout for example, but they are not mean to be used directly and there is no guarantee that they will remain accessible in future versions of SwifUI.

Functional Approach

Modifiers and Stacks are similar in the sense that they both wrap some content. Stacks wrap their content using a closure so you may wonder why not use this same approach for modifiers.

FrameLayout(width: 100, height: 100) {
    Rectangle()
}

I personally think that this approach makes it a little easier in some cases to understand what is going on when we apply a modifier. The problem is that as soon as you start applying multiple modifiers it quickly becomes a Pyramid of Doom. It does not escalate well.

CornerRadius(5) {
    Background(Color.red) {
        Padding(10) {
            FrameLayout(width: 100, height: 100) {
                Rectangle()
            }
        }
    }
}

The functional approach chosen is much more scalable and cleaner and once you get used it becomes clear that it's the right choice.

Rectangle()
    .frame(width: 100, height: 100)
    .padding(10)
    .background(Color.red)
    .cornerRadius(5)

Conclusion

Modifiers are as essential as Views in SwiftUI and allows us to customize Views as much as necessary while keeping a clean code, thanks to its wisely chosen functional approach.

Understanding SwiftUI: View

Mateus Rodrigues — Sun, 12 Jul 2020 18:54:46 +0000

You'll hear a lot of "Everything is a View" when diving into the SwiftUI world and, in fact, practically everything we deal with it is a View, even things you wouldn't expect as a Color. So, what is a View? What's so special about it?

The Protocol

A View is actually a quite simple protocol with only one required body property whose type also implements the View protocol, and that's it.

protocol View {
    associatedtype Body: View
    var body: Self.Body { get }
}

The body declares the content and behaviour of a View and that's where we code what we want to be display when it's rendered.

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
    }
}

Opaque Type

The some keyword in the body property is very important. It's a feature called Opaque Type and it's designed to hide a concrete type that implements a given protocol. It's actually a sort of compile magic and the same code can be translated to the following one:

struct ContentView: View {
    var body: Text {
        Text("Hello, World!")
    }
}

Opaque types really shine when dealing with mores complex views. Because of the compositional nature of SwiftUI, the complexity of the body type scales very quickly, but it goes unnoticed thanks to the opaque type.

struct ContentView: View {
    var body: some View {
        HStack {
            Rectangle().fill(Color.green)
            Rectangle().fill(Color.white)
            Rectangle().fill(Color.orange)
        }
        .frame(width: 300, height: 300)
        .border(Color.black)
    }
}

Swift requires an explicit type for computed properties an without this ability to hide concrete types, it would be virtually impossible to write SwiftUI code in a practical way.

struct ContentView: View {
    var body: ModifiedContent<ModifiedContent<HStack<TupleView<(_ShapeView<Rectangle, Color>, _ShapeView<Rectangle, Color>, _ShapeView<Rectangle, Color>)>>, _FrameLayout>, _OverlayModifier<_ShapeView<_StrokedShape<_Inset>, Color>>> {
        HStack {
            Rectangle().fill(Color.green)
            Rectangle().fill(Color.white)
            Rectangle().fill(Color.orange)
        }
        .frame(width: 300, height: 300)
        .border(Color.black)
    }
}

Associated Type

This problem that opaque types solve raises the question of why to use an associated type in the first place. SwiftUI engineers could have chosen a slightly different and simple approach for the View protocol, defining the body property as a simple View.

protocol View {
    var body: View { get }
}

This approach would allow declaring the body type as View, without the need of opaque type, regardless of its complexity.

struct ContentView: View {
    var body: View {
        HStack {
            Rectangle().fill(Color.green)
            Rectangle().fill(Color.white)
            Rectangle().fill(Color.orange)
        }
        .frame(width: 300, height: 300)
        .border(Color.black)
    }
}

The downside of this approach is that SwiftUI relies on static types to optimize the updates. Consider the following example.

struct ContentView: View {

    @State var b: Bool

    var body: some View {
        VStack {
            Text("...")
            Rectangle()
                .fill(b ? Color.red : Color.green)
        }
    }
}

The body property has a concrete type, hidden by the opaque type. You can check this type by accessing the associated type Body.

print(ContentView.Body.self)
// VStack<TupleView<(Text, _ShapeView<Rectangle, Color>)>>

Swift's type system ensures that the type is the same every time the body is computed. This makes it possible to check changes on an individual basis and update only what is needed.

Giving up the concrete type and using only protocol would mean losing the static type and allowing to return anything as long as it conforms to View. The consequence of this is that it would be necessary to redraw the entire screen with each change or perform a much more complicated operation to detect changes in order to update only what is necessary.

You might think that a body with a static type reduces flexibility but SwiftUI provides ways to define optional or conditional views while keeping it statically typed.

struct ContentView: View {

    @State var b1: Bool
    @State var b2: Bool

    var body: some View {
        VStack {
            if b1 {
                Rectangle()
            }
            if b2 {
                Text("...")
            } else {
                Image("...")
            }
        }
    }
}

Although the result on the screen is variable, its type will always be the same and SwiftUI knows the possible outcomes.

print(ContentView.Body.self)
// VStack<TupleView<(Optional<Rectangle>, _ConditionalContent<Text, Image>)>>

The Infinity Recursion Problem

Any implementation of the View protocol will have the same basic structure.

struct ContentView: View {
    var body: some View {
        ...
    }
}

If you think about it, whatever View returned from the body property has its own body, which is also a View and therefore has a body itself and then we end up with an apparently infinity recursion problem.

+--------+   body   +--------+   body   +--------+
|  View  | +------> |  View  | +------> |  View  | . . .
+--------+          +--------+          +--------+

There must be some way to stop this. There is indeed and most SwiftUI built-in View implementations, such as Text, have a special way of stopping this recursion. How? By literally returning Never from the body!

"Never is a proposition that an event doesn’t occur at any time in the past or future. It’s logical impossibility with a time axis; nothingness stretching out in all directions, forever."
(Mattt Thompson)

Never is a so-called uninhabited type, which means that it has no values and can't be constructed. It's mostly used in Swift functions that stop execution such as fatalError(_:file:line:) and its implementation is as simple as possible.

enum Never { }

Extending Never to the implement the View protocol makes it possible to use this type to define a View whose body should never return anything.

extension Never: View {
    typealias Body = Never
    var body: Never { fatalError() }
}

For most of the basic types defined in SwiftUI there is no point in looking at the body property because the type itself and its other properties provide enough information. Text, for example, has a property to store the content to be displayed and that is all the framework needs to know. For types like that, it makes sense that nothing is returned from the body.

extension Text: View {
    public typealias Body = Swift.Never
}

Finally, whenever SwiftUI run into a View with a Never body, it knows when to stop, breaking the recursion in a very simple and clever way.

struct ContentView: View {
    var body: some Text {
        Text("Hello, World!")
    }
}

+---------------+   body   +--------+   body   +---------+
|  ContentView  | +------> |  Text  | +------> |  Never  |
+---------------+          +--------+          +---------+

Text body property hasn't a public access level, but if you try the following code you will get an error.

ContentView().body.body
// Fatal error: body() should not be called on Text

This makes it clear that SwiftUI doesn't actually try to access the body property in cases like this and instead it just type check it.

Conclusion

Being widely used in SwiftUI as it is, View would be expected to be something complicated but as you can see it is actually very simple. It shows how protocols can be powerful and it is a remarkable example of protocol-oriented programming.

Forem: Mateus Rodrigues

Note on SwiftUI Custom Font

Understanding SwiftUI: Modifiers

Functional Approach

Conclusion

Understanding SwiftUI: View

The Protocol

Opaque Type

Associated Type

The Infinity Recursion Problem

Conclusion

Recommended Readings