Introduction

Image(systemName:) in SwiftUI renders symbols from Apple's SF Symbols library. The confusing part is that the valid names do not live in your project as image files, so developers often ask where the full list comes from and how to know whether a symbol is available on the current OS. The practical answer is to browse the catalog in Apple's SF Symbols app and then use code to validate or fall back for the names you actually ship.

Where the Symbol Names Come From

Apple's symbol images are identified by string names such as house.fill, bolt.circle, and wifi.exclamationmark. The authoritative catalog is the SF Symbols app that Apple provides for macOS. Apple's UIImage(systemName:...) documentation explicitly points developers to the SF Symbols app to look up symbol names.

That app is useful because it shows more than the raw name:

• symbol variants such as filled or slashed versions
• rendering support such as monochrome, hierarchical, palette, or multicolor
• platform and OS availability
• categories for browsing instead of memorizing strings

In other words, if you want "all available images," the place to browse them is the SF Symbols app, not a SwiftUI runtime API.

Using Image(systemName:) in SwiftUI

Once you know the symbol name, using it is straightforward:

1import SwiftUI
2
3struct ToolbarExample: View {
4    var body: some View {
5        HStack(spacing: 24) {
6            Image(systemName: "tray.full")
7            Image(systemName: "paperplane.fill")
8            Image(systemName: "person.crop.circle")
9        }
10        .font(.title2)
11        .foregroundStyle(.blue)
12        .padding()
13    }
14}

Because these are symbols rather than bitmap assets, they scale with text, adapt to weights, and work well inside controls such as Label, Button, and ToolbarItem.

Checking Availability and Falling Back

The catalog changes over time, and some symbols are only available on newer OS releases. SwiftUI does not give you a built-in method that enumerates the entire symbol library for you. In practice, you keep a curated set of names and validate them when necessary.

This helper checks whether the current device can load a symbol and falls back if it cannot:

1import SwiftUI
2import UIKit
3
4func supportedSymbolName(_ preferred: String,
5                         fallback: String = "questionmark.circle") -> String {
6    if UIImage(systemName: preferred) != nil {
7        return preferred
8    }
9    return fallback
10}
11
12struct SymbolRow: View {
13    let preferredName: String
14
15    var body: some View {
16        let actualName = supportedSymbolName(preferredName)
17
18        Label(preferredName, systemImage: actualName)
19            .font(.body)
20    }
21}

That pattern is especially useful when:

• you support more than one iOS version
• design picked a newer symbol and you need a graceful fallback
• you are building an in-app picker from your own approved list

If you want to show users a searchable symbol palette inside your app, create your own array of allowed names rather than trying to discover the whole system catalog dynamically.

1import SwiftUI
2import UIKit
3
4struct SymbolCatalogView: View {
5    let candidates = [
6        "house",
7        "folder",
8        "tray.full",
9        "wifi",
10        "battery.100",
11        "calendar"
12    ]
13
14    var body: some View {
15        List(candidates.filter { UIImage(systemName: $0) != nil }, id: \.self) { name in
16            Label(name, systemImage: name)
17        }
18    }
19}

This does not discover every possible SF Symbol. It validates a list you provide, which is the safer pattern for production code.

Choosing the Right Symbol

The technical part is only half the job. You also need to choose symbols that communicate clearly. Prefer familiar symbols for common actions and avoid treating every noun as an icon problem. If users have to guess what the symbol means, pair it with text using Label.

Also pay attention to rendering. A symbol that looks great in monochrome may lose clarity in palette mode or at small sizes. The SF Symbols app is helpful here because it lets you preview weights, scales, and rendering modes before you commit to a name in code.

Common Pitfalls

• Expecting a runtime API to dump the full symbol list. In practice, developers browse the SF Symbols app and store the names they care about.
• Using symbols that are newer than the minimum OS version. Always check availability and keep a fallback.
• Typos in symbol names. Image(systemName:) fails silently enough that a misspelling can look like a layout bug.
• Over-customizing with fixed frames before checking legibility. Symbols are designed to work with text metrics first.
• Assuming all symbols support the same rendering modes. Some look better in palette or multicolor, while others are intended for monochrome use.

Summary

• The complete catalog for Image(systemName:) comes from Apple's SF Symbols app.
• Symbol names are strings such as house.fill and paperplane.
• Use Image(systemName:) directly once you know the name.
• For production apps, validate preferred names and provide fallbacks for older OS versions.
• If you need an in-app picker, maintain your own curated list instead of trying to enumerate every system symbol dynamically.