SF Symbols
SF Symbols provides a set of over 1,500 consistent, highly configurable symbols you can use in your app. Apple designed SF Symbols to integrate seamlessly with the San Francisco system font, so the symbols automatically ensure optical vertical alignment with text for all weights and sizes. SF Symbols are available in a wide range of weights and scales to help you create adaptable designs.
[…]
SF Symbols come in nine weights—from ultralight to black—each of which corresponds to a weight of the San Francisco system font. This correspondence lets you achieve precise weight matching between symbols and adjacent text, while supporting flexibility for different sizes and contexts.
These SF Symbols are so so clean.
One thing that no one has noticed is that these icons for SF Symbols have “Ink Traps” since they’ll be used for print and not UI.
And if they’re used for UI, that’s a major major failure.
If this is the quality we can expect, it’s going to be difficult to recommend SF Symbols for anything other than rough prototypes.
I believe the icons looking blurry is inherent in the technique, and near impossible to work around, even for icons we make ourselves. I guess I’m sticking with PNGs for everything.
It’s worth noting those issues are extremely easy to see from a normal viewing distance on device.
“206 – Introducing SF Symbols” is unexpectedly deep. Apple baked a ton of thought and flexibility into symbols. Defintiely go back and check it out if you’ve missed it.
There’s a macOS app for SF Symbols but...also macOS is the only platform where SF Symbols aren’t supported.
That is...poor.
As Mac developer, I have to write UIKit-based app just to get SF Symbols on Mac (even with SwiftUI)? Apparently.
With SF Symbols, no matter what they say, Apple is basically giving 🖕to AppKit.
Native (AppKit) Apps will now be second-class on their own platform. 😞
AppKit already caches raster renditions of vector images generically. It would be great to expose symbols on
NSImage, but there are some prerequisites to work out before that can happen.
SF Symbols has some frustratingly restrictive rules for certain glyphs. E.G Safari uses the open book icon to mean ‘Bookmarks’, but Apple won’t let a third-party app use it to mean anything other than ‘Apple Books’.
Every phone icon in the SF Symbols set is reserved to exclusively mean Apple’s Phone app. All envelopes are for Apple Mail only. Seems dumb.
Weird. In a session earlier today an Apple engineer used the envelope symbol for a login UI.
No one is actually going to pay any attention to these usage restrictions. Apple itself didn’t in the SwiftUI demo.
Using the “video.fill” symbol (which says only to use for FaceTime) to show the demo conference room had video conferencing support.
Apple: “Here are 𝘧𝘪𝘧𝘵𝘦𝘦𝘯 different symbols all of which may 𝗼𝗻𝗹𝘆 refer to Apple’s Phone app. Why fifteen instead of just one? Because what you want in buttons that refer to a single app is 𝘷𝘢𝘳𝘪𝘦𝘵𝘺.”
“If you need to illustrate the concept of a phone but not the ‘Phone’ app, please use any of a hundred free icons on https://thenounproject.com that look very much like these but are slightly different and users won’t know the difference because 15 varieties come with the system.”
Thing I tried: Many of the SF Symbols are also Unicode, which means you can target them on the web, with
font-family: -apple-system;in your CSS. So cool. :)
Although these look the business, they take us into a morass which is almost worse than not having them at all.
That was quick! A Swift Package providing type-safe accessors to iOS 13’s SF System images 🚀
I really hope that Apple revisits the SFSymbols API and chooses to provide compile-time constants instead of just strings.
That would:
1. Let Apple use @available to add/deprecate symbols
2. Aid discoverability of icons
3. Let the compiler catch typosThose seem like big wins.
Update (2019-06-12): Elliott Pogue:
The clipping is definitely a bug. Re: the pixel grid... I don’t think Apple gives a high priority to pixel precision anymore. For instance, my 2018 15” MBP was set to 1680x1050 by default, not the true 2x 1440x900.
Yep, and that’s such a poor choice for the default display scaling. Combined with SF Symbols, you’re getting double damage. With Project Catalyst, triple. I don’t understand these choices. It makes their hardware look terrible.
A very quick comparison GIF with some pixel snapped icons. It worries me that Apple are going to trash the quality of their icons across all their platforms in a single move.
Update (2019-06-18): Marc Edwards:
iOS 13 beta 2 didn’t improve SF Symbol quality. I think there’s two separate issues: The clipping, which is fixable. And, the blurriness, which is not fixable while continuing to use the same technique.
[…]
There’s also a third issue: The method required for authoring icons is incredibly manual, requiring a file per icon. That’s just not how anyone building a library of icons for an app or design system should be working. Everything should be as automated as possible.
[…]
They’re built to a 100pt font grid that doesn’t match any pixel size I am aware of.
Yep, that that undoes a lot of the good work of the hardware teams, plus these things are cumulative. SF Symbols + Project Catalyst + MacBook Pro display scaling means a vector icon is rendered with fractional offsets, bitmap scaled by 77%, then bitmap scaled again.
Update (2019-07-18): Marc Edwards:
Are SF Symbols still bad? Yes. Here’s a comparison between Calendar and Safari in iOS 12 vs iOS 13. Stylistic choices aside, the iOS 13 icons are a smudgy mess.
SF Symbols as a concept is funadamentally broken. Icons can not be as high quality as previously. This affects all system icons, across many OSs. I expect more from Apple.
There’s zero chance we’ll be using SF Symbols for icons as they currently stand.
Update (2019-08-22): Julian Schiavo:
Stuff like the bookmark icon is no longer restricted to use to refer to Apple Books
2 Comments RSS · Twitter
You quoted Mark Munz: "Native (AppKit) Apps will now be second-class on their own platform. 😞"
I guess the conclusion is that AppKit is _not_ native (anymore). It's just a compatibility framework, like Carbon.
I guess the conclusion is that AppKit is not native (anymore). It’s just a compatibility framework, like Carbon.
I really don’t think we got a clear message on that.
It could equally be argued that Catalyst is the Carbon-like temporary bandaid, and the long-term approach is SwiftUI, which in turn will work on top of AppKit on macOS.
As for SF Symbols, I don’t see the big benefit over something like Font Awesome or the zillion other options. The carrot is them being Apple’s blessed icons, but it comes with the stick of restrictive usage guidelines.
