There are often more elements on the screen than what my screenshot shows, but I want to keep this demo simple. 😊

The most recent time I was building screens like that, I was testing how the layout responded to Dynamic Type (i.e. bigger/smaller device font size setting). And it was in that exact moment when I realized that the most important part of my layout was the copy being shown in the Text views and not the Image. Because the images－in my specific situation－did not provide any informational value to the user. And I really wanted the user to be able to focus on reading the text without having the image get in the way when using larger Dynamic Type sizes. With this realization, my brain immediately thought, "OK, what I need to do is leverage Dynamic Type to shrink the height of the image as the Dynamic Type size grows." I had actually never thought about doing this before, and I also don't think it's a documented approach in the HIG or anything, but it seemed to make sense in my situation at the time and I already knew the exact tools to use in SwiftUI to make it a reality. So I decided to go ahead with it. And that's the approach I wanted to explore in today's article!

In order to accomplish this, we only need to use 3 things:

1️⃣. The awesome Environment variable called dynamicTypeSize to access the user's current font size;

@Environment(\.dynamicTypeSize) private var currentDynamicTypeSize

(I love how easily we can access Dynamic Type information! 😃)

2️⃣. A @State property to hold a calculated image height－based on the currentDynamicTypeSize;

@State private var calculatedImageHeight: Double = .zero // arbitrary initial value

3️⃣. Somewhere to switch on the currentDynamicTypeSize, like the .onChange modifier or the .onAppear modifier (I chose .onChange, but you do you), where we can calculate and set the calculatedImageHeight.

.onChange(of: currentDynamicTypeSize, initial: true, { _, newValue in
    switch newValue {
        ...
        // case .small, .medium, .large － etc.
        // Calculate and set the image height here
    }
})

And with those 3 key things, all we have left to do is calculate a height based on the different Dynamic Type sizes and then use it on the Image! To do that, we can let Xcode auto-fill in all the cases in the switch statement so we can see all the possible Dynamic Type sizes, and then do a quick little multiplication arithmetic to come up with a value for calculatedImageHeight.

The end goal is to have the calculatedImageHeight be a certain percentage of a predetermined base image height. Let's choose 268 for this demo. (e.g. if we want the calculated height to be 75% of 268, that's 0.75 * 268) So, we can choose the Dynamic Type sizes that fit our particular situation, decide on a "scale factor" percentage for each case, then multiply baseImageHeight by the scaleFactor—and that's our calculatedImageHeight! Here's an example of how that could look:

.onChange(of: currentDynamicTypeSize, initial: true, { _, newValue in
    let scaleFactor: Double

    switch newValue {
    case .xSmall, .small, .medium, .large:
        scaleFactor = 1.0
    case .xLarge:
        scaleFactor = 0.9
    case .xxLarge:
        scaleFactor = 0.75
    case .xxxLarge:
        scaleFactor = 0.55
    default:
        scaleFactor = 0.3
    }

    let baseImageHeight = 268.0
    calculatedImageHeight = baseImageHeight * scaleFactor
})

Notice, as the Dynamic Type size gets bigger, we use smaller percentages: 90%, down to 75%, down to 55%, and then to 30%. For this demo, I decided to cap the scaling off after .xxxLarge by putting 30% into the default case. So in the end, any Dynamic Type size smaller than .xLarge uses 100% of the base image height; anything bigger than .xxxLarge uses 30% of the base image height; and a few other percentages for the cases in between.

Now we're ready to apply calculatedImageHeight to the Image and see what happens!

Image(.balloons)
    .resizable()
    .scaledToFit()
    .frame(maxHeight: calculatedImageHeight) // 🎉 ✅

And hey, it works! Here's the result as a GIF:

I understand that there's a chance another approach exists to achieve this exact same thing. 😄 I do think, though, that this approach is a fun way to leverage Dynamic Type to achieve a specific－and hopefully improved－user experience.

That's all! See ya later, rollerblader!

Come say "Hi!" on Twitter or Mastodon! Or don't. 😄

Come along if you'd like to see what I mean. 😊

Let's start with "this works" (and then we'll improve it)

(To be clear, the next few code snippets are not the final result. They'll be improved down below.) Here's an example "service" class whose job is to use APIs from AcmeSupport to implement customer support features directly in your app ("AcmeSupport" is a fake 3rd-party dependency name I thought of because I have Roadrunner cartoons on my mind).

import AcmeSupport

class AcmeSupportService {
    ...
    func fetchAcmeTickets() -> async [AcmeTicket] {
        // Call into the AcmeSupport API here
        ...
    }
}

As you can see, our method calls into Acme's API and returns an array of AcmeSupport's own type called AcmeTicket. It looks like we could use that type nicely, so we'll go ahead and use this service class in some other part of the app, like this:

import Foundation
import AcmeSupport

class DataLogicPlace {
    ...
    private let acmeService = AcmeSupportService()
    ...
    func loadAcmeTickets() async -> [AcmeTicket] {
        let acmeTickets = await acmeService.fetchAcmeTickets()
        // Here you can minpulate the `AcmeTicket` objects 
        // from the `acmeTickets` array
        ...
    }
    ...
}

It's possible you may want to do other things with the AcmeTicket type from the acmeTickets array result that could require you to import AcmeSupport. So the DataLogicPlace class imports it. And since we want to display these tickets in our UI, we can even use these AcmeTicket types right inside our View:

import SwiftUI
import AcmeSupport

struct AcmeSupportScreen: View {
    ...
    var body: some View {
        ...
        ForEach(acmeTickets) { acmeTicket in
            acmeTicketRowView(forAcmeTicket: acmeTicket)
        }
        ...
    }

    private func acmeTicketRowView(forAcmeTicket: AcmeTicket) -> some View {
        ...
    }
}

And for this View (i.e. "Screen" 😉), we have to import AcmeSupport so we can access its AcmeTicket type to use as the argument type in our acmeTicketRowView method.

All of this code may already look great to you. And that's totally OK. This works. As planned though, we'll improve it all by encapsulating and generalizing. Readysetgo.

Encapsulate

The goal here is to only import AcmeSupport once in the app so that there's only one file that depends on it, and the rest can compile happily without it. To do this, let's create our own version of AcmeSupport's type AcmeTicket and we'll name ours something generalized like "SupportTicket" (foreshadowing, anyone? 😄)

struct SupportTicket: Identifiable {
    ...
}

Cool! Let's use our new type right away so you can see the effect it will have!

import AcmeSupport

class AcmeSupportService {
    ...
    func fetchAcmeTickets() -> async [SupportTicket] { // 👀
        // Call into the AcmeSupport API here
        // ✅ THEN map THEIR type to our OWN type to return 😃
        ...
    }
}

Notice in the snippet that we're now returning an array of SupportTicket instead of AcmeSupport's type AcmeTicket. We do this by quickly mapping their type to our own type and walking away. This is really great, you know why? Because now all the other files in our app that were previously consuming an array of the AcmeTicket type will now be consuming an array of our very own SupportTicket type—which meeeeans all those files can immediately deleteimport AcmeSupport because they won't need to access AcmeSupport's AcmeTicket type anymore! And just like that, we've successfully encapsulated the AcmeSupport dependency and its API calls into one single place in our app. Party time? ...Yeah. Party time. 🥳

Generalize

Alright, in the original 3 code snippets, if you count the number of times the word "acme" appears in the code—excluding the import statements and the AcmeTicket type name—it comes out to around 15 times (and that's only in 3 tiny snippets representing 3 tiny files).

So the goal now is to generalize all of our naming (don't worry, I'm not talking about Swift generics 😅) so that it doesn't mention the name of the company, "Acme", anywhere. If we do this, the code instantly takes on a totally different feeling. Check it out:

import AcmeSupport // ⬅️ imported only once, right here

class SupportService {
    ...
    func fetchTickets() -> async [SupportTicket] {
        ...
    }
}

import Foundation

class DataLogicPlace {
    ...
    let service = SupportService()
    ...
    func loadTickets() async -> [SupportTicket] {
        let tickets = await service.fetchTickets()
        ...
    }
    ...
}

import SwiftUI

struct SupportScreen: View {
    ...
    var body: some View {
        ...
        ForEach(tickets) { ticket in
            rowView(forTicket: ticket)
        }
        ...
    }

    private func rowView(forTicket ticket: SupportTicket) -> some View {
        ...
    }
}

And would you look a that! We've successfully generalized our naming, bringing the number of times we see "acme" in our naming from ~15 all the way down to zero! All without compromising the readability of the code. In fact, I'd say the readability has improved! Mission: accomplished.

Is this really necessary?

You decide. Over the years, I've seen lots of code where devs tightly couple 3rd-party dependency names and their types to the rest of the codebase, making it unnecessarily intertwined and dependent on some other thing/company. And then the Product team asks the devs to a/b test 2 different dependencies/companies, or even completely replace a dependency with a different one that offers the same functionality as the original but perhaps at a better rate. Well, in these situations, if your code looks like the original 3 snippets in this article, then you'll have a lot of naming-refactoring ahead of you, and likely a lot of logic-refactoring, and also type-replacing, like in that original acmeTicketRowView method above that depended on the 3rd-party AcmeTicket type.

So if we thoughtfully encapsulate and generalize from the get-go, then our code can be a lot more pleasant to work with; scaling will be easier, and we'll be more likely to code more confidently when we need to do something drastic like completely replaceAcmeSupport with BeepBeepSupport.

"beep beep!"

Come say "Hi!" on Twitter or Mastodon! Or don't. 😄

As we continued to build, the number of SwiftUI files naturally grew in our new project and it became increasingly difficult to tell whether a SwiftUI file name corresponded to the actual full layout of a screen or to a single custom view or component we had created. Because every single SwiftUI file we created ended in View.swift, and there were a lot of files! After all, literally no one in the world had ever built a large-scale Production app in this new "SwiftUI" framework, so we were forging our own path coming up with our own naming conventions. (I mean, "View" isn't anything novel, but hopefully you get what I mean.)

Then suddenly, a seemingly simple naming solution dawned on me: if you're creating a new SwiftUI file whose layout is intended to represent an entire screen, then use the Screen suffix, e.g. SettingsScreen.swift; otherwise, use the View suffix, e.g. BasicRowView.swift. And boom! Just like that—the moment we started using this naming convention, the struggle to distinguish between subview files and full-screen layout files vanished!

Fast forward almost 5 years (2024), I'm still working full-time using SwiftUI, and I still follow the exact same naming convention. But something has changed. In those early days, we were extraction-happy: we extracted subviews out into their own files all over the place. And that's how we ended up with a lot of files. I'm not saying that's a bad thing though. The thing that has changed/evolved since then is my approach to view extraction. These days, the vast majority of my SwiftUI files are Screen files, with only someView files. Because I've become much more selective about what I extract out into its own View file. I'll explain.

Let's say your app has several screens that each list things out, and every screen uses the exact same UI for the rows. In this situation, since the row layout is used in more than one screen in the app, I would extract the row UI (which I would consider a "subview" of a "screen") into its own file using the View suffix, e.g. PrimaryRowView.swift and I would use it throughout the app. On the flip side, you might have a screen that uses a unique style for its rows and that particular screen is the only screen in the app that uses that unique style of row. Well, since that row style is only used in one single screen in the app, I would opt to create the row layout directly within the Screen file itself using a func (and/or computed property) returning some View like this:

private func cardRowView(title: String) -> some View {
    ...
}

If, at any point in time, that unique style ends up being used in more that one screen, then it's a pretty light lift to bust it out into its own file as a reusable component. No big deal.

It may be worth mentioning, some say breaking up complex views into smaller pieces that live in their own files may improve performance. I haven't measured this sort of thing myself, and my article today isn't about performance. Full stop 😅

So, hey, you've read an article about a naming convention. And it probably won't change the world. But it might change your world by making your code vastly easier to reason about. And if your code is easier to reason about, it'll be that much easier for you to change the world. ...what? Go to sleep.

That was way too serious.
kloveyoubye 👋🏼

P.S. Do you remember what it was like Googling something about SwiftUI in Summer 2019 and having it return 0 results? 😅

We can start by creating an @Observable class as a place to ultimately hold & update the current state of the app as it launches and as we're preparing to show the correct screen to the user. For this demo, let's name the class AppLauncher (I dunno, naming is tricky. Go with it. 😆)

import SwiftUI

@Observable
class AppLauncher {

}

Cool. Now, let's make use of my best friend, enum, to describe the different launch states we need to handle.

import SwiftUI

@Observable
class AppLauncher {
    enum LaunchState {
        case loading
        case pendingAuth
        case doneWithNothingPending
    }

    var launchState = LaunchState.loading

    // We'll do stuff right here in a minute...keep reading
}

Great! This is shaping up nicely! And since our class is @Observable we're already prepared to hook up the launchState variable to our @mainApp struct and start observing its changes! So let's do that now by, first, heading over to the App struct and adding a @State instance of AppLauncher. (And I'll name our demo app Milkshakes because I love milkshakes.)

import SwiftUI

@main
struct Milkshakes: App {

    @State private var launcher = AppLauncher()

    var body: some Scene {
        WindowGroup {
            Text("We'll do something right here next!")
        }
    }
}

Real quick, in order to keep the body property as concise as possible, we'll move the Text into a new bodyContentView method (passing in the launchState for later) and return it from there instead.

import SwiftUI

@main
struct Milkshakes: App {

    @State private var launcher = AppLauncher()

    var body: some Scene {
        WindowGroup {
            bodyContentView(launchState: launcher.launchState)
        }
    }

    @ViewBuilder 
    private func bodyContentView(launchState: AppLauncher.LaunchState) -> some View {
        // Get ready to rock!
        Text("This is where things get really exciting!")
    }
}

Alright, we're finally ready to rock! Let's spread the butter on this launchState bread using enum's partner in crime, the switch statement 🎉 (my other best friend). We'll delete the Text in the method and start typing switch launchState － and it's in this exact moment where we leverage Xcode's awesome auto-complete to get this output:

switch launchState {
case .loading:

case .pendingAuth:

case .doneWithNothingPending:

}

Love it! Exhaustivity for the win! Oh, and did you notice that I put @ViewBuilder on the bodyContentView(launchState:) method earlier? That sets us up perfectly to return a uniqueView in each case of the enum! 😍 So what are we waiting for?!

@ViewBuilder 
private func bodyContentView(launchState: AppLauncher.LaunchState) -> some View {
    switch launchState {
    case .loading:
        AppLaunchLoadingScreen()

    case .pendingAuth:
        AppIntroScreen()

    case .doneWithNothingPending:
        AppRootTabView()
    }
}

Boom, baby! With all this in place, our Milkshakes app successfully observes any changes to launchState and shows the appropriate View for each state! 🥳

Hold on though..! 😅 We still need to tell AppLauncher to start doing stuff so it can actually change the value of launchState from the default .loading state to something else. One way to do that is to create a method in AppLauncher to call from the App struct in an .onAppear modifier. Let's see what that looks like real quick.

import SwiftUI

@Observable
class AppLauncher {
    enum LaunchState {
        case loading
        case pendingAuth
        case doneWithNothingPending
    }

    var launchState = LaunchState.loading

    func load() {
        // Do whatever setup code you want
        ...

        // Update the launch state accordingly
        launchState = .doneWithNothingPending
    }
}

Meanwhile, in the App struct, we call the new load method in .onAppear:

WindowGroup {
    bodyContentView(launchState: launcher.launchState)
        .onAppear { launcher.load() }
}

And that's it! We're officially done!

If you're thirsty for a bonus addition to this code, keep reading. Otherwise, thank you for sticking around and I hope you found some value here!
K love you bye 👋🏽

Animate the State Changes

Consider slightly animating the launchState changes by adding an .animation modifier right under .onAppear. 👌🏼

.onAppear { launcher.load() }
.animation(.default, value: launcher.launchState)

P.S. I really love 🩷 enums in Swift!