Monday, June 10, 2019 [Tweets] [Favorites]

SF Symbols

Apple:

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.

Ryan Jones:

These SF Symbols are so so clean.

Eli Schiff:

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.

Marc Edwards:

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.

Joshua Emmons:

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.

Wil Shipley:

There’s a macOS app for SF Symbols but...also macOS is the only platform where SF Symbols aren’t supported.

That is...poor.

Mark Munz:

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. 😞

Jeff Nadeau:

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.

Benjamin Mayo:

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’.

Benjamin Mayo:

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.

Austin Tooley:

Weird. In a session earlier today an Apple engineer used the envelope symbol for a login UI.

Kyle Howells:

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.

Wil Shipley:

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.”

Chuck Toporek:

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. :)

Howard Oakley:

Although these look the business, they take us into a morass which is almost worse than not having them at all.

JP Simard:

That was quick! A Swift Package providing type-safe accessors to iOS 13’s SF System images 🚀

Matt Diephouse:

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 typos

Those 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.

Marc Edwards:

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.

Marc Edwards:

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.

Marc Edwards:

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.

2 Comments

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.

Sören Nils Kuklau

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.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment