SF Symbols personalizados: o template variável e as três fontes obrigatórias

A Apple distribui mais de 6.000 SF Symbols e o app SF Symbols é gratuito, mas a maioria dos apps acaba precisando de um ícone que a Apple não tem: uma marca, um glifo específico de domínio, uma ação personalizada que não se encaixa no vocabulário do sistema. O caminho certo é criar um SF Symbol personalizado em vez de soltar um SVG estático, porque os SF Symbols personalizados herdam a maquinaria do sistema de graça: escalam com Dynamic Type, participam de animações Symbol Effects, renderizam nos quatro modos de renderização, alinham-se com a tipografia SF Pro e respeitam configurações de acessibilidade sem código por app. SVGs estáticos não participam de nada disso.

Este post percorre o workflow contra o template variável do app SF Symbols, introduzido no SF Symbols 3 na WWDC 2021¹. O enquadramento é “quais são os três designs-fonte obrigatórios e por quê”, porque o formato do template é a parte estrutural do workflow que a maioria dos designers e engenheiros perde na primeira vez. Versões subsequentes do SF Symbols (4, 5, 6, 7) estenderam o formato do template com cor variável, transições de magic replace, suporte a gradientes e efeitos de animação, mas a estrutura central de três fontes do template variável tem se mantido estável desde o SF Symbols 3.

TL;DR

• SF Symbols personalizados começam a partir de um template exportado do app SF Symbols (File > Export Template, ou ⌘E)². O template é um SVG com guias definidos pelo sistema para dimensionamento e um design de símbolo placeholder para substituir.
• O template variável requer apenas três designs-fonte: Ultralight-Small, Regular-Small e Black-Small. O app SF Symbols interpola as 24 variações restantes (3 escalas × 9 pesos) automaticamente³.
• A compatibilidade de path é o requisito estrutural: cada path deve ter o mesmo número de pontos de ancoragem, o mesmo ponto inicial e a mesma direção em todas as três fontes. Sem isso, a interpolação produz glifos malformados.
• Símbolos personalizados suportam todos os quatro modos de renderização (monochrome, hierarchical, palette, multicolor) e a estrutura de camadas (primary, secondary, tertiary). O painel rendering inspector do Symbol Editor atribui subpaths às camadas.
• Entrega final: adicione o arquivo do símbolo ao Xcode como um Symbol Image Set no asset catalog. O SwiftUI o referencia através de Image(_:) com o nome do símbolo; o sistema cuida do resto.

O template variável

O SF Symbols 3 (WWDC 2021) introduziu o template variável³, um único arquivo SVG que captura três designs-fonte e a partir do qual o app SF Symbols gera a grade completa de 27 variações. As três fontes são:

• Ultralight-Small. O peso mais leve, a menor escala.
• Regular-Small. O peso intermediário, a menor escala.
• Black-Small. O peso mais pesado, a menor escala.

O app usa essas três para interpolar as outras 24 células (Ultralight-Medium, Regular-Medium, Black-Medium, Ultralight-Large, Regular-Large, Black-Large, além dos pesos intermediários em cada escala). A interpolação é automática desde que os paths-fonte tenham estrutura compatível.

Antes do SF Symbols 3 introduzir o template variável, símbolos personalizados exigiam que todas as 27 variações fossem desenhadas manualmente. O template variável reduziu isso para 3 + interpolação, o que é a diferença entre um esforço de design administrável e um que mata o projeto.

O requisito de dados compatíveis

A interpolação de path exige que os três paths-fonte descrevam a mesma forma na mesma ordem²:

• Mesmo número de pontos de ancoragem. Um quadrado em peso Regular com 4 âncoras deve ter 4 âncoras em Ultralight e em Black, mesmo que a curvatura visível seja diferente.
• Mesmo ponto inicial. A primeira âncora do path deve estar na mesma posição conceitual (por exemplo, sempre o canto superior esquerdo) em todos os três pesos.
• Mesma direção. Todos os três paths percorrem a forma na mesma ordem (sentido horário ou anti-horário).

Falhar em qualquer um desses produz artefatos de interpolação: dobras, sobreposições erradas, traços faltando. O app SF Symbols expõe alguns deles (a prévia da variante mostra o resultado da interpolação), mas problemas sutis só se manifestam no asset final exportado.

O workflow pragmático é projetar Regular-Small primeiro, depois derivar Ultralight reduzindo a largura do traço e Black aumentando a largura do traço sobre o mesmo esqueleto de path. Cada derivação preserva a contagem de âncoras, o ponto inicial e a direção por construção. Projetar cada peso de forma independente produz problemas de compatibilidade que demoram mais para depurar do que refazer a construção.

O workflow

Cinco passos do conceito ao asset funcional:

1. Encontre um símbolo existente similar

A biblioteca do app SF Symbols tem mais de 6.000 símbolos. Encontre um estruturalmente similar ao seu conceito (um círculo-com-conteúdo, um quadrado-com-overlay, uma linha-com-decoração). O caminho de exportar o template usa a geometria de um símbolo existente como ponto de partida.

2. Exporte o template

File > Export Template… ou ⌘E. Escolha “Variable” como tipo de template. O resultado é um arquivo SVG com os três pesos-fonte do símbolo dispostos, além da geometria de referência mostrando a cap height, a baseline e as margens visuais que o SF Symbols usa para alinhar com o texto SF Pro.

3. Substitua os paths do template

Abra o SVG em um editor vetorial (Sketch, Figma, Illustrator, Affinity Designer, Inkscape). As camadas nomeadas do template contêm os três designs-fonte. Substitua cada um pelo seu design personalizado preservando os nomes das camadas e o alinhamento de cap-height/baseline.

O requisito de compatibilidade de path importa aqui: projete cada peso a partir do mesmo esqueleto de path, variando a largura do traço ou o peso de preenchimento em vez de redesenhar. O workflow “duplicar e modificar” das ferramentas vetoriais é o caminho de menor resistência.

4. Re-importe e verifique

Arraste o SVG modificado de volta para o app SF Symbols. O app gera as 27 variações e as exibe na grade de variantes. Inspecione cada combinação de peso-e-escala em múltiplos níveis de zoom; artefatos de interpolação geralmente aparecem em pesos intermediários que não são imediatamente óbvios.

Para símbolos com múltiplos elementos visuais (um corpo mais um badge, um círculo mais uma forma interna), abra o painel rendering inspector e atribua subpaths a camadas (primary, secondary, tertiary). As atribuições de camadas determinam como o símbolo renderiza nos modos hierarchical, palette e multicolor.

5. Adicione ao Xcode

Arraste o arquivo do símbolo (.svg exportado do SF Symbols) para o asset catalog do Xcode. O Xcode o trata como um Symbol Image Set. Referencie a partir do código:

Image("MyCustomSymbol")
    .symbolRenderingMode(.hierarchical)
    .foregroundStyle(.tint)

Image(_:) (sem o parâmetro systemName:) carrega do asset catalog. Os mesmos comportamentos de .symbolRenderingMode, .foregroundStyle, .symbolEffect e Dynamic Type que funcionam em símbolos do sistema funcionam em símbolos personalizados, desde que o símbolo tenha sido autorado corretamente.

Modos de renderização e estrutura de camadas

Os quatro modos de renderização que o SF Symbols expõe funcionam da mesma forma em símbolos personalizados e em símbolos do sistema⁴:

• Monochrome. Cor única (foregroundStyle). O modo mais simples e o mais comum.
• Hierarchical. Cor única, opacidade variável por camada. Camadas definidas no painel rendering inspector recebem opacidades pré-definidas; o desenvolvedor aplica um tint e obtém hierarquia visual automaticamente.
• Palette. Cor explícita por camada. O desenvolvedor passa múltiplos argumentos foregroundStyle; cada camada recebe o seu.
• Multicolor. Cores fixas definidas pela Apple por camada. Para símbolos personalizados, as cores são as que o designer atribui na configuração Multicolor do Symbol Editor.

A estrutura de camadas é o que faz hierarchical, palette e multicolor funcionarem. Um símbolo personalizado sem atribuições de camada colapsa todos os paths na camada primary; o símbolo ainda renderiza em monochrome mas não produz hierarquia visual nos outros modos. Reserve tempo para atribuir camadas no painel rendering inspector para qualquer símbolo que se beneficie de profundidade.

Falhas comuns

Três padrões dos logs de falha de símbolos personalizados:

Violações de compatibilidade de path. O problema mais comum. Um símbolo que “fica bem em peso Regular” mas produz pesos intermediários com glitches quase sempre tem um problema de compatibilidade de path. Diagnóstico: abra a grade de variantes do app SF Symbols, olhe as variantes de peso intermediário; se mostrarem dobras ou traços que não correspondem à interpolação esperada, um dos três paths-fonte viola a compatibilidade.

Baseline ou cap height desalinhada. Símbolos projetados sem respeitar a guia de baseline do template ficarão desajeitados ao lado do texto. O sintoma visual: o símbolo aparece muito alto ou muito baixo quando colocado inline com Text estilizado em .body. Solução: use a geometria de referência do template; posicione o centro óptico do símbolo no ponto médio da cap-height.

Sem atribuições de camadas. Um símbolo com estrutura interna rica (múltiplos elementos visuais) mas sem atribuições de camadas renderiza corretamente apenas em monochrome. Apps que selecionam modo hierarchical ou palette veem saída plana. Solução: abra o painel rendering inspector e atribua cada subpath a uma camada (primary para a forma principal, secondary para acentos, tertiary para detalhe terciário).

O que esse padrão significa para apps iOS 26+

Três conclusões.

1. Use SF Symbols personalizados, não SVGs brutos, para ícones in-app. O workflow de símbolo personalizado é trabalho real de engenharia, mas a integração com o sistema (Dynamic Type, Symbol Effects, modos de renderização, acessibilidade) compensa o custo para qualquer ícone que viva na UI a longo prazo. SVGs estáticos são adequados para assets de marketing pontuais, não para UI central.

2. Projete a partir de um único esqueleto; varie o peso do traço, não a estrutura do path. Violações de compatibilidade de path são o modo de falha estrutural. O processo de design defensivo é começar com um peso (Regular-Small), derivar Ultralight reduzindo o traço e Black aumentando o traço a partir da mesma geometria de path. A compatibilidade se mantém por construção.

3. Atribua camadas explicitamente para qualquer símbolo que se beneficie dos modos de renderização. Um símbolo que renderiza apenas em monochrome é um símbolo que abre mão de metade do sistema SF Symbols. O painel rendering inspector leva minutos; o resultado são símbolos que participam de modos hierarchical, palette e multicolor lado a lado com símbolos do sistema.

O cluster completo do Apple Ecosystem: App Intents tipados; servidores MCP; a questão de roteamento; Foundation Models; a distinção LLM entre runtime e tooling; três superfícies; o padrão de fonte única de verdade; Two MCP Servers; hooks para desenvolvimento Apple; Live Activities; o contrato de runtime watchOS; internals do SwiftUI; o modelo mental espacial do RealityKit; disciplina de schema do SwiftData; padrões de Liquid Glass; shipping multi-plataforma; a matriz de plataformas; Vision framework; Symbol Effects; inferência Core ML; adoção da API Writing Tools; Swift Testing; Privacy Manifest; acessibilidade como plataforma; tipografia SF Pro; padrões espaciais visionOS; Speech framework; migrações SwiftData; focus engine do tvOS; internals do @Observable; protocolo Layout do SwiftUI; sobre o que me recuso a escrever. O hub está na Apple Ecosystem Series. Para contexto mais amplo de iOS com agentes de IA, veja o iOS Agent Development guide.

FAQ

Preciso do app SF Symbols, ou posso criar símbolos personalizados de outra forma?

O app SF Symbols é a ferramenta oficial e a única que produz símbolos personalizados validados e compatíveis com a App Store. Ferramentas de terceiros e conversores online existem mas produzem SVGs que podem ou não satisfazer os requisitos do formato do template. Para apps em produção, use o app SF Symbols.

Posso criar símbolos personalizados no Windows?

O app SF Symbols é exclusivo do macOS. Você pode editar o template SVG exportado em qualquer plataforma com um editor vetorial, mas os passos de exportação e re-importação exigem macOS. A maioria dos times tem pelo menos um designer no macOS que pode lidar com esses passos; workflows de times remotos passam o arquivo SVG via controle de versão ou armazenamento compartilhado.

Como suporto .symbolEffect em um símbolo personalizado?

A maioria dos symbol effects funciona automaticamente se a estrutura do símbolo for bem formada: bounce, pulse, scale e os demais se aplicam ao símbolo independentemente de sua origem. A transição de conteúdo .replace precisa que o símbolo de-origem e o símbolo de-destino tenham estruturas compatíveis (contagens de camadas similares, forma geral similar). O post Symbol Effects do cluster cobre o vocabulário de efeitos em detalhe.

Qual a diferença entre um Symbol Image Set e um Image Set comum no Xcode?

Um Symbol Image Set importa o template completo do símbolo (todas as 27 variações) e os expõe através do pipeline de renderização do SF Symbols. O símbolo escala com Dynamic Type, participa dos modos de renderização e funciona com .symbolEffect. Um Image Set comum é um recurso raster ou SVG estático que não participa de nada disso. Use Symbol Image Set para SF Symbols personalizados.

Como símbolos personalizados lidam com visionOS e watchOS?

Da mesma forma que símbolos do sistema: renderizam nos tamanhos esperados pela plataforma (small para watchOS, large para visionOS), participam dos recursos de acessibilidade da plataforma e respeitam as convenções de cor e efeito da plataforma. A autoria do símbolo personalizado é única; o comportamento cross-plataforma é automático. Os posts Apple Platform Matrix e padrões espaciais visionOS do cluster cobrem as considerações por plataforma.

Qual o impacto na revisão da App Store?

Nenhum. SF Symbols personalizados são revisados de forma idêntica a outros assets do Asset Catalog. As diretrizes de estilo visual (não imitar padrões de UI da Apple, não violar marcas registradas) se aplicam a símbolos personalizados como se aplicam a outras artes personalizadas; fora isso, o processo de revisão os trata como assets de imagem padrão.

Referências