# SVGKit: native SVG rendering on Apple platforms through Core Animation > SVGKit is a Cocoa framework for rendering SVG files natively on iOS and macOS using CoreAnimation, fast because it converts SVG into native layers rather than rasterizing. It installs five ways from a dragged framework to Swift Package Manager, ships iOS and macOS demo projects with hit detection and animation, and lives on the 3.x development branch with the last release tagged in 2021. **SVGKit/SVGKit** — Display and interact with SVG Images on iOS / OS X, using native rendering (CoreAnimation) - Repository: https://github.com/SVGKit/SVGKit - Stars: 4,581 · Forks: 1,123 - Language: Objective-C - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/svgkit-svgkit ## Native rendering, not an image decode SVGKit is a Cocoa framework for rendering SVG files natively, described as fast and powerful, and the word native carries the architecture, display and interaction happen through CoreAnimation, converting SVG geometry into CALayer trees rather than drawing the file once into a bitmap. The difference shows up exactly where the demo points, zoom and pan stay crisp because layers re-render at the new scale, and tap detection works per shape because the layers are real view hierarchy objects. The library is Objective-C at its core, with Source holding the implementation and the wiki carrying additional information and links. The default branch on GitHub is 3.x, described as the current in-development branch with the latest changes, fixes and features, automatically selected as default when visiting the project page. ## The demo as the first test Getting started is a demo run rather than an install, open Demo-iOS.xcodeproj and run it on simulator or device, try different SVGs, zoom and pan, and hit the Animate button on the Monkey sample, then tap the images to see bounding-boxes and hit detection, with the caveat that the Debug button might need pressing first. The troubleshooting advice that follows is the project's most practical sentence, if you have any problems building the library and embedding it in your app, compare your build settings to the Demo-iOS build settings, because if something's different, it's probably the problem. A separate Demo-OSX.xcodeproj exists for the Mac, letting users browse the same SVG files through the two view types to check compatibility, and a Demo-Samples directory holds the SVG files the demos consume. ## Five install options, with a preferred one The installation section lists three main options and then keeps going, a numbered list that acknowledges reality. Dragging the built framework into the project is marked preferred and recommended, CocoaPods and Carthage follow, then the static library drag-and-drop with manual build settings, then Swift Package Manager through Xcode's Add Packages with the repository URL. The note on the static library explains why it survives in the list, it is the backwards-compatible manual install that always works if you have problems with CocoaPods, Carthage or the framework. The framework option's own caveat is equally candid, frameworks are the preferred way to use libraries in Xcode but this is a new feature, it might have bugs, so the recommendation comes with an escape hatch attached in the same section. ## The framework path, and the frameworks it needs The preferred route is four steps, open SVGKit-iOS.xcodeproj, build once, expand the Products folder in the Project Navigator, and drag SVGKit.framework into the app project. The may-need list of Apple frameworks follows, CoreText, CoreImage, libxml2.dylib, QuartzCore, CoreGraphics and UIKit, the dependency set that reveals the implementation, libxml2 parsing the SVG source, CoreText handling text, and the rest rendering. A third-party framework, CocoaLumberjack for logging, ships in the 3rd-party-frameworks folder with iOS, tvOS and other variants to drag in, with the reminder to embed it under Target, General, Embedded Binaries. The same framework list repeats in the static library instructions, the fixed set the library genuinely needs rather than optional extras. ## Package manager configs, verbatim For CocoaPods the Podfile line is: ``` pod 'SVGKit' ``` with the recommendation to pin the development branch: ``` pod 'SVGKit', :git => 'https://github.com/SVGKit/SVGKit.git', :branch => '3.x' ``` and Carthage's Cartfile mirrors the pattern: ``` github "SVGKit/SVGKit" ``` ``` github "SVGKit/SVGKit" "3.x" ``` Both recommendations date their advice, October 2018 pointing at the 3.x branch, which says something about how long 3.x has been the future, and Swift Package Manager support arrives through a Package.swift at the repository root, making the five install options cover every era of iOS dependency management. ## The static library ritual, in ten steps The static library option is a ten step ritual the README preserves in full, build the SVGKit-iOS target, find the libSVGKit .a file in Products, show it in finder, go up one folder, select the Debug-universal or Release-universal folder, drag the .a file and the usr folder into the project with copy files checked, add the -ObjC flag to Other Linker Flags, set the compiler version, and link all the Apple frameworks. A build script automates building all versions of the library at once into a single fat file, referencing a Stack Overflow answer for the technique's lineage. The ten steps are a museum of pre-framework iOS dependency management, and their survival in the README is deliberate, this is the install that always works when the modern ones fail. ## macOS since 2.1, and the SwiftUI gist macOS support arrived in version 2.1.0 in autumn 2018, using nearly the same API as iOS, including the SVGKFastImageView and SVGKLayeredImageView view classes, plus SVGKImage.NSImage to export an SVG layer to a bitmap image. The two view classes encode the rendering tradeoff, fast image view flattening for performance and layered view preserving the layer hierarchy for interactivity, and their names appear in both platform sections. The recipes section links the original author's blog posts from 2012 and 2013 on usage, recipes, scaling and the core architecture, with the honest caveat that some APIs have changed slightly since they were written, and a more recent gist demonstrates using SVGKFastImageView in SwiftUI, the bridge into the current era of Apple development. The release tags are old, 3.0.0 in April 2021 after 2.1.0 in 2018 and 2.0.0 in 2016, with the last push on 2026-09-21 keeping the 3.x branch moving. ## Conclusion Use SVGKit when an Apple platform app must display SVG assets interactively, zooming, panning, hit detection on shapes, and rasterized PNG fallbacks are not good enough, since native layer rendering keeps vectors crisp at any scale. Choose a Swift-native SVG library if the project is pure Swift and minimal, or decode SVGs at build time if the assets never change. Before adopting, compare your build settings to the demo project's when integration fails, as the project itself advises, prefer the framework drag-and-drop install with the static library fallback for package manager trouble, and check the versions wiki since the 3.x branch is the default but the last tagged release is 3.0.0 from 2021. ## FAQ ### What is SVGKit? SVGKit is a Cocoa framework for rendering SVG files natively on iOS and macOS using CoreAnimation, converting SVG into native layers so zoom, pan and per-shape hit detection stay crisp and interactive. It is Objective-C based, supports SwiftUI through SVGKFastImageView, and installs via framework drag-and-drop, CocoaPods, Carthage, a static library or Swift Package Manager. ### How do you install SVGKit in an Xcode project? The preferred route builds SVGKit-iOS.xcodeproj once, then drags SVGKit.framework from the Products folder into your app. Alternatives are pod 'SVGKit' with CocoaPods, github "SVGKit/SVGKit" with Carthage, Swift Package Manager via Add Packages, or the static library with manual build settings, which the project keeps as the fallback that always works. ### Does SVGKit support macOS? Yes, macOS support was added in version 2.1.0 in autumn 2018 with nearly the same API as iOS, including SVGKFastImageView, SVGKLayeredImageView and SVGKImage.NSImage for exporting an SVG layer to a bitmap. A Demo-OSX.xcodeproj project demonstrates the two view types. ## Sources - [Issues](https://github.com/SVGKit/SVGKit/issues) - [README](https://github.com/SVGKit/SVGKit/blob/3.x/README.md) - [Releases](https://github.com/SVGKit/SVGKit/releases) - [SVGKit/SVGKit on GitHub](https://github.com/SVGKit/SVGKit) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/svgkit-svgkit