Step-by-step guide to exporting an SF Symbol template, drawing your own custom symbol that matches Apple's system style, and using it in SwiftUI and UIKit.
Apple's library is large, but it cannot cover every brand mark or domain-specific concept. When you need a logo glyph or a niche icon, a custom symbol lets your artwork behave exactly like a system symbol.
That means your custom icon inherits weight, scale, and alignment with text, just like `star.fill` does. It sits cleanly next to labels and respects Dynamic Type.
The trick is to start from Apple's official template rather than drawing from scratch. The template encodes the precise metrics that make a symbol feel native.
This guide walks through exporting that template, editing it, and wiring it into your app. You need the free SF Symbols app, a vector editor, and Xcode.
Open the SF Symbols app and find an existing symbol whose visual complexity is close to what you want. Choosing a similar donor makes the math of weights and margins easier.
For a simple shape, export a simple symbol. For something with fine detail, export a denser one so the proportions translate well.
Select the symbol, then use the app's export option to produce a template file. The export is a vector template that contains guides and weight references.
Keep the file somewhere you can open it in your vector editing tool of choice. This template is your canvas.
When you open the exported template, you will see reference rows and guide lines. These define the margins, baseline, and cap height your symbol must respect.
The template typically includes multiple weight references so your symbol can match different font weights. At minimum you draw the primary weight, and ideally you provide the lightest and heaviest as well.
There are also guides that show where the symbol should sit relative to text. Staying inside these guides is what keeps your icon aligned with system symbols at runtime.
Treat the guides as hard constraints. If your art spills outside them, your symbol will look misaligned next to labels.
Replace the donor artwork in the appropriate layer with your own vector shapes. Keep paths clean, closed, and simple, since overly complex art renders poorly at small sizes.
Design for clarity at a small point size first. A symbol that reads well in a tab bar will almost always read well when scaled up.
Match the visual weight of system symbols. Your strokes and fills should feel like they belong in the same family as Apple's icons, not heavier or thinner.
If you are supporting multiple weights, adjust the art in each weight reference so the heavy version is genuinely heavier and the light version genuinely lighter. This is what makes the symbol respond correctly to font weight.
Export your edited file back out in the same template format the app produced, keeping the layer and guide structure intact. Do not flatten or rename the structural layers.
The naming and grouping inside the file are meaningful. Xcode reads them to understand which paths correspond to which weights and rendering layers.
If you broke the structure while editing, Xcode may reject the symbol or render it incorrectly. When in doubt, re-export the template fresh and redo your edits more carefully.
Validate the result by reopening it in the SF Symbols app if possible, which can flag structural problems before you ever reach Xcode.
In Xcode, open your asset catalog and add a new symbol image, then drag in your custom symbol file. The asset catalog has a dedicated symbol image type for this.
Give the asset a clear name, for example `brandLogo` or `customCompass`. This name is how you will reference it in code.
Xcode will show a preview and may surface warnings if the symbol structure is off. Address any warnings before moving on.
Keep custom symbol names distinct from Apple's system names so it is obvious in your codebase which symbols are yours.
Crucially, custom symbols use a different initializer than system symbols. In SwiftUI you reference them by asset name without `systemName`.
Image("brandLogo")
That is the same call you use for any asset catalog image, but because it is a symbol template it now supports weight, scale, and rendering modes.
Image("brandLogo")
.font(.title)
.symbolRenderingMode(.hierarchical)
.foregroundStyle(.blue)
In UIKit, use `UIImage(named:)` for custom symbols rather than `UIImage(systemName:)`. Mixing these up is a frequent source of nil images.
Place your custom symbol next to real text at several Dynamic Type sizes. Confirm it scales and aligns the way a system symbol would.
Test it in light and dark mode, and with any rendering modes you intend to use. Hierarchical and palette modes only behave well if your layers are set up correctly.
Check it in the actual UI locations you plan to use it, such as a tab bar, a button, and a list row. Tab bars in particular punish symbols that are too detailed.
Iterate on the artwork if anything looks heavy, misaligned, or muddy. Getting a custom symbol to feel native often takes a couple of refinement passes.
Custom symbols match the system style but they are still your responsibility to maintain. Apple will not update them as the design language evolves, unlike built-in symbols.
Multicolor and advanced layering require deliberate layer setup in the template. If you only need a single-color glyph, keep it simple and avoid that complexity.
Remember the broader limitation: SF Symbols, custom or not, only solve iconography. You still compile, sign, and submit the app through Xcode and the Apple Developer Program.
For authoritative, current guidance on template structure and supported features, rely on Apple's official SF Symbols resources rather than memory, since the format and capabilities evolve across releases.
Once you have a few custom symbols, naming discipline keeps the project readable. Pick a consistent prefix or convention so custom symbols are easy to spot in code.
A name like `brand.logo` or `customCompass` signals intent and avoids colliding with Apple's namespace. Never reuse a system symbol name for a custom asset.
Group related custom symbols in the asset catalog so designers and engineers can find them quickly. A flat pile of dozens of assets becomes hard to manage.
If several symbols share a visual family, keep their templates together in source control alongside the exported assets. Future updates are far easier when the editable templates live next to the shipped versions.
No. Export a template from the SF Symbols app using a donor symbol that resembles your target, then replace the artwork inside that template so it keeps the correct metrics.
Use Image("assetName") with the asset catalog name, not Image(systemName:). The systemName initializer is only for Apple's built-in symbols.
Yes, if you set up the layers correctly in the template. Single-color symbols work with monochrome and hierarchical; palette and multicolor need properly separated layers.
Ideally yes. Drawing at least the primary, lightest, and heaviest weights lets your symbol respond to font weight the way system symbols do.
No. Custom symbols are yours to maintain. Only Apple's built-in symbols evolve automatically with the system design language.