SwiftIcons puts twelve icon fonts behind one Swift API, at the cost of shipping every ttf

The problem is twelve separate font dependencies

The README states the motivation in one sentence: you do not have to download different libraries to include different font icons.

That is a real and common problem in iOS development. Every icon font comes as its own pod or framework, each with its own naming conventions, its own unicode range, its own licence file and its own way of being applied to a UIView. A team that ends up with FontAwesome for a legacy screen, Ionicons for a new one and Material icons somewhere else has three dependencies and three integration styles.

SwiftIcons merges twelve of them behind one Swift API: Dripicons, Emoji, FontAwesome, Icofont, Ionicons, Linearicons, Map-icons, Material icons, Open iconic, State face icons, Weather icons and TypIcons.

The licence is MIT, the primary language is Swift, and the homepage is ranesr.github.io/SwiftIcons. The topic tags name the sets it bundles, including fontawesome, ionicons, material-icons, dripicons, icofont, linearicons, map-icon, open-iconic, state-face and weather-icons, and the ttf tag names the packaging format.

The requirements listed are iOS 9.0+ and Xcode 8, and the CocoaPods badge says Swift 5.0. That combination of an ancient minimum deployment target with a recent Swift version tells you the library has been kept compiling while the ecosystem moved on around it.

One call per UIKit type, with colours and stacking

SwiftIcons supports a set of UIKit objects, and the README lists them: UIImage, UIImageView, UILabel, UIButton, UISegmentedControl, UITabBarItem, UISlider, UIBarButtonItem, UIViewController, UITextfield and UIStepper.

The call shape is consistent. You name the font type and then the icon within it, and the library resolves the character.

import SwiftIcons

UIImage.init(icon: .emoji(.airplane), size: CGSize(width: 35, height: 35))

// Icon with colors
UIImage.init(icon: .emoji(.airplane), size: CGSize(width: 35, height: 35), textColor: .red)
UIImage.init(icon: .emoji(.airplane), size: CGSize(width: 35, height: 35), textColor: .white, backgroundColor: .red)

For UIImageView the same icon goes through a setIcon method rather than an initialiser.

import SwiftIcons

// Setting icon to image view
imageView.setIcon(icon: .weather(.rainMix))

// Icon with colors
imageView.setIcon(icon: .mapicons(.amusementPark), textColor: .white, backgroundColor: .blue, size: nil)

The stacked icon initialiser is the more interesting one, since it composes a background icon with a foreground icon and lets you control the relative size.

import SwiftIcons

// Stacked icons with bigger background
UIImage.init(bgIcon: .fontAwesomeRegular(.circle), topIcon: .fontAwesomeRegular(.square))

// Stacked icons with smaller background
UIImage.init(bgIcon: .fontAwesomeSolid(.camera), topIcon: .fontAwesomeSolid(.ban), topTextColor: .red, bgLarge: false)

The bgLarge flag is what distinguishes the two arrangements, and passing a size along gives you a custom overall dimension.

The pattern is worth naming: the icon is a font glyph, so colouring is a text colour and a background colour rather than a tint of a bitmap. That is why the API takes textColor and backgroundColor rather than tintColor.

The UILabel case is the one no asset library covers

The UILabel support is the feature that distinguishes this library, because it does something the other icon APIs cannot.

A label can be given an icon with prefix and postfix text around it, so the icon is part of the text run rather than a separate view.

import SwiftIcons

// Setting icon to label
label.setIcon(icon: .ionicons(.paintbrush), iconSize: 70)

// Icon with colors
label.setIcon(icon: .googleMaterialDesign(.rowing), iconSize: 70, color: .white, bgColor: textColor)

// Icon with text around it
label.setIcon(prefixText: "Bus ", icon: .linearIcons(.bus), postfixText: " icon", size: 20)

And you can colour the prefix and postfix separately from the icon, and give the surrounding text its own font.

import SwiftIcons

// Icon with color & colored text around it
label.setIcon(prefixText: "Medal ", prefixTextColor: .red, icon: .ionicons(.ribbonA), iconColor: .red, postfixText: "", postfixTextColor: .red, size: nil, iconSize: 40)

That last example is the capability that matters. A badge like a medal icon followed by red text is a single label with one layout pass, and it reflows with dynamic type because it is text. Doing the same with an icon view means a container view, a constraint, and the usual work of making it behave under text size changes.

The README frames this as no more image icons any more, and the label case is where that claim pays off.

The library also distinguishes different font types for each of the sets, which the usage table enumerates: dripicons, emoji, fontAwesome, icofont, ionicons, linearIcons, mapicons, googleMaterialDesign, openIconic, state, weather and TypIcons. Each carries the version of the upstream set it was generated from, from Dripicons 2.0 and Ionicons 2.0.1 through FontAwesome 5.1.0 and Material icons 2.2.0.

Three installation paths, and fourteen font files

Installation goes through CocoaPods, Carthage, or a manual copy, and the manual copy is where the design becomes visible.

For CocoaPods, the Podfile entry is short.

target 'YourProject' do
    use_frameworks!
    pod 'SwiftIcons', '~> 3.0'
end

Carthage takes a Cartfile line.

github "ranesr/SwiftIcons" ~> 3.0

And the manual route is described as copying all the files from the Source folder, which links to a directory listing that is the clearest statement of what this library is.

- SwiftIcons.swift
- Dripicons.ttf
- Emoji.ttf
- FontAwesomeBrands.ttf
- FontAwesomeRegular.ttf
- FontAwesomeSolid.ttf
- Icofont.ttf
- Ionicons.ttf
- Linearicons.ttf
- MapIcons.ttf
- MaterialIcons.ttf
- OpenIconic.ttf
- Stateface.ttf
- WeatherIcons.ttf
- TypIcons.ttf

Fifteen files, one Swift source and fourteen font files. FontAwesome is split into three because it ships in three weights, so that is one set becoming three payloads.

The manual instructions then tell you to check to import all ttf files in the project, under Project, Target, Copy Bundle Resources. That step is easy to miss and the failure mode is silent: a font that is registered in the app but not bundled renders as a missing glyph rather than a crash.

The library reference documentation is at cocoadocs.org for the pod. The repository root holds SwiftIcons.swift and the fonts under Source, plus a SwiftIcons.xcodeproj directory, a SwiftIconsApp directory and SwiftIconsTests, and a docs directory and resources directory. There is also a Package.swift at the root, so Swift Package Manager support exists in the tree even though the README documents only CocoaPods, Carthage and manual installation.

Where SwiftIcons is the wrong choice

The first limitation is the binary size, and it is the reason most teams should not reach for this. Fourteen font files ship with the library, and every one of them is bundled into your app whether or not you use a single glyph from it. A Material Icons file is a megabyte of glyphs, and the app pays for all of it.

The second is that the icon sets are frozen. The usage table records the upstream versions the fonts were generated from, and FontAwesome at 5.1.0 and Material icons at 2.2.0 are old. Newer versions of those sets are not in this library, so a team that wants a specific recent icon has to obtain it another way, and then it is back to managing font dependencies, which is what the library exists to avoid.

The third is that it is iOS and UIKit only. The listed objects are all UIKit types, the requirements are iOS 9.0+ with Xcode 8, and there is no SwiftUI or multiplatform support mentioned anywhere.

The fourth is the maintenance signal. The last push to the repository was on 2026-09-11, but the newest tagged release is 3.0 from 2019-11-04, with 2.3.2 in December 2018 before that. The repository is not archived, so the code is not abandoned, but it is well past the point where a new app would pick it as its default.

The fifth is the alternative that now exists. An iOS app in 2026 has SF Symbols, which is a system font covering a large slice of what these sets offer, with no bundle cost at all. For many projects the correct answer to an icon need is SF Symbols plus one bespoke icon font, not twelve.

How it compares with SF Symbols and a single icon font

Two alternatives cover most of the ground, and they differ in what they cost you.

SF Symbols is built into iOS. It is a font, which means it is colourable, scalable, available at any weight and dynamic type aware, and it costs your app nothing because it is on the device. The limitation is coverage. There is no reasonable SF Symbols equivalent for a brand-specific glyph or for the thousands of pictographic icons in the larger sets, and the library the README mentions as the inspiration for its own state face icons is itself a set of flag and country glyphs.

A single icon font is the other option. You add FontAwesome or Ionicons and you get one dependency with one integration style, one font file, and the icons in that set at their current version. What you give up is the typed API across sets, the stacked icon initialisers and the label prefix and postfix trick.

SwiftIcons is worth it when the icon diversity is real and the label trick matters. A dashboard that mixes a weather glyph, a map pin, a payment brand mark and a social logo is exactly the case where one library with a typed API beats four dependencies. It is not worth it when you need four icons, because the alternative costs one font file instead of fourteen.

The CocoaPods version constraint is worth noting too, because it shows the age of the API surface. The Podfile asks for SwiftIcons at 3.0 and the badge advertises Swift 5.0 support, so the library compiles against a Swift version from 2019. Whether it builds cleanly under a current toolchain depends on the Swift version in your project, and that is the first thing to check before committing to it.

Editorial conclusion

SwiftIcons fits an iOS project that already ships several icon fonts and wants one typed API over them, or that needs the icon-as-text trick, where an icon is inserted into a label between prefix and postfix text, which no asset-based icon library does. It does not fit a project starting from zero, because SF Symbols covers most needs without a font file, and it does not fit an app with a strict size budget, since every set in the library is bundled. Before adopting, check whether the icons you actually need exist in the one set you would otherwise have added, and if you take the library, verify in your build what the fourteen bundled ttf files cost your binary.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. ranesr/SwiftIcons on GitHub
4. README
5. Releases