SFSafeSymbols alternatives and similar libraries
Based on the "Image" category.
Alternatively, view SFSafeSymbols alternatives based on common mentions on social networks and blogs.
10.0 8.4 L2 SFSafeSymbols VS SDWebImageAsynchronous image downloader with cache support as a UIImageView category
9.7 0.0 L3 SFSafeSymbols VS FastImageCacheiOS library for quickly displaying images while scrolling
9.2 2.1 L1 SFSafeSymbols VS PINRemoteImageA thread safe, performant, feature rich image fetcher
9.2 0.0 L3 SFSafeSymbols VS AlamofireImageAlamofireImage is an image component library for Alamofire
8.9 0.0 L4 SFSafeSymbols VS NYTPhotoViewerA modern photo viewing experience for iOS.
8.1 1.3 SFSafeSymbols VS TinyCrayonA smart and easy-to-use image masking and cutout SDK for mobile apps.
8.1 1.4 L5 SFSafeSymbols VS Lightbox:milky_way: A convenient and easy to use image viewer for your iOS app
8.0 5.2 SFSafeSymbols VS MetalPetalA GPU accelerated image and video processing framework built on Metal.
Twitter Image Pipeline is a robust and performant image loading and caching framework for iOS clients
6.5 0.0 SFSafeSymbols VS PaparazzoCustom iOS camera and photo picker with editing capabilities
5.8 3.7 L5 SFSafeSymbols VS Imaginary:unicorn: Remote images, as easy as one, two, three.
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of SFSafeSymbols or a related project?
Idea & Features • Supported Versions • Installation • Usage • Contributing • License • Issues • Pull Requests
Idea & Features
At WWDC 2019, Apple announced a new library of icons that came included with that year's new operating system versions. To browse them, there's a dedicated Mac app called SF Symbols. However, developers still have to copy the name of a symbol and reference it unsafely, resulting in code like this:
It didn't take long until first ideas came up to make these icons accessible in a safe way using a framework. And this is just the basic idea behind
- ... you can be sure your symbol code won't crash due to typos or symbol availability issues. This is because all symbols are tested via a CI (on the latest iOS & tvOS versions and also some earlier OS versions).
- ... lookups in the SF Symbols app (e. g. about available layersets, available localizations & the look of the symbol) are no longer needed because every symbol is documented in code.
- ... multiple SF Symbols versions are supported at the same time (via utilization of the
@availabilityflag). Each symbol is only made available on those platform versions where Apple says it's available.
- ... renamed symbols can be detected easily (via a deprecation notice which suggests the use of the new name at the same time).
The following SF Symbols versions are currently supported:
|SF Symbols Version||iOS Version||macOS Version||tvOS Version||watchOS Version|
SFSafeSymbols can be installed via the Swift Package Manager (recommended), Carthage or CocoaPods.
Supported platforms are
tvOS (11.0+) and
watchOS (4.0+), although the actual functionality is of course only accessible starting with
tvOS 13.0 and
Swift Package Manager (Xcode-integrated)
To integrate SFSafeSymbols using the Xcode-built-in SPM, choose
Swift Packages →
Add Package Dependency. Enter the following url:
https://github.com/SFSafeSymbols/SFSafeSymbols and click
Next. When asked about the version, leave the preselection and click
Next. In the following step, select
SFSafeSymbols as the package product and click
Swift Package Manager (standalone)
To integrate using the standalone version of Apple's Swift Package Manager, add the following as a dependency to your
.package(url: "https://github.com/SFSafeSymbols/SFSafeSymbols.git", .upToNextMajor(from: "4.0.0"))
"SFSafeSymbols" as a dependency of the target in which you want to use it, run
swift package update.
Add the following entry to your Cartfile:
github "SFSafeSymbols/SFSafeSymbols" ~> 4.0.0
Add the following entry to your Podfile:
pod 'SFSafeSymbols', '~> 4.0.0'
All the system symbols are accessible via the
SFSymbol type. They are named similar to Apple's names, but use a lower camel case style and prefix names with leading numbers with a
c.circle ~> SFSymbol.cCircle e.circle.fill ~> SFSymbol.eCircleFill 11.circle.fill ~> SFSymbol._11CircleFill
A SF Symbol
UIImage can now be initialized using the
SFSymbol type. This image is already unwrapped, so you get a
UIImage instead of a
UIImage(systemSymbol: .cCircle) UIImage(systemSymbol: SFSymbol.eCircleFill) UIImage(systemSymbol: ._11CircleFill, withConfiguration: /* Some UIImage.Configuration */)
A SF Symbol
SwiftUI.Image can also be initialized using the
Image(systemSymbol: .cCircle) Image(systemSymbol: SFSymbol.eCircleFill)
There are also
Label("MyText", systemSymbol: .cCircle) Label(LocalizedStringKey("my.text"), systemSymbol: SFSymbol.eCircleFill)
... and an initializer for
UIApplicationShortcutIcon(systemSymbol: .cCircle) UIApplicationShortcutIcon(systemSymbol: SFSymbol.eCircleFill)
... and finally also an initializer for AppKit's
NSImage(systemSymbol: .cCircle) NSImage(systemSymbol: SFSymbol.eCircleFill, accessibilityDescription: "some.description")
SF Symbols can come with multiple different localizations.
SFSafeSymbols exposes localization the following way:
Implicit localization: When using an
SFSymbol, it gets automatically localized to the user's current locale - nothing to do on your part. This behavior is managed by Apple's system implementation of SF Symbols.
SFSafeSymbolslets you access a symbol's localized versions as follows:
// 1. Static localization: let a = SFSymbol.character.ar // corresponds to "character.ar" let b = SFSymbol.character.zh // corresponds to "character.zh" let c = SFSymbol.character.rtl // doesn't compile: "character.rtl" doesn't exist // a, b have type SFSymbol // 2. Dynamic localization: SFSymbol.character.availableLocalizations // [.ar, .he, .hi, .ja, .ko, .th, .zh, .zhTraditional] let a = SFSymbol.character.localized(to: .ar) let b = SFSymbol.character.localized(to: .rtl) // a, b have type SFSymbol?
Static localization only exposes the localizations which are actually available, so you cannot accidentally localize a non-localizable symbol.
Dynamic localization, in contrast, is useful when dealing with an array of
SFSymbols which all have different available localizations.
Attention: Serializing and deserializing
SFSymbols currently makes them lose their explicit static localization information. Dynamic localization information will still be retained.
Contributions are very much welcome! See CONTRIBUTING.md for more information.
*Note that all licence references and agreements mentioned in the SFSafeSymbols README section above are relevant to that project's source code only.