dagronf/QRCode: a QR code generator and detector for Apple platforms

A vector-friendly QR code generator, not a barcode toolkit

The scope here is narrower than the word QR might suggest. This is a library for one symbology, QR codes, and it does two jobs: generating them and detecting them. What it does not attempt is to be a general barcode component covering EAN, UPC, Code 128, Aztec or PDF417.

Within QR codes, the feature list is wide. The library supports Swift, SwiftUI and Objective-C, ships through Swift Package Manager and is CocoaPods compatible, and supports all error correction levels with a configurable quiet zone. Output is not limited to a bitmap: it can produce images, scalable PDFs, scalable SVGs and CGPath paths, and the design is configurable, with a logo that can be added to the code, configurable fill styles in solid, linear gradient and radial gradient, and a configurable corner radius.

That combination is the reason to pick this over writing the encoding yourself. A QR code drawn as a CGPath can be filled with a gradient and rounded at the corners, which is exactly the branded code that most apps want and which is awkward to do with a raster image. The Examples/ directory in the tree shows the range in practice, with separate folders for a logo background, a linear gradient, a negated variant, an off-pixels style, a 3d demo and an LCD effect, each with its own index and sample output.

The stated reason for the library existing is blunter than a feature list: it is nice to have a simple drop-in component for displaying a QR code, and it is nice to have your app look great. For a library, that is a fair statement of scope.

Two products, split so the camera permission stays optional

The packaging decision is the most instructive thing in the library. Generation lives in a product called QRCode, and video detection lives in a separate one called QRCodeDetector. The documentation explains why: video detection requires your app to have an NSCameraUsageDescription defined, along with an AVFoundation dependency, and if you are putting the app on the App Store you may not want that for an app that does not need it.

The usage instruction is correspondingly blunt. For QR code generation, link against QRCode. For QR code video detection, link against QRCodeDetector. In your own source, Swift imports it as `import QRCode`, and Objective-C uses `@import QRCode;`.

The detection side is described as basic QR code video detection, via importing QRCodeDetector, and the feature list scopes it as basic. That is the honest word to use when planning: this is a way to scan codes from a camera feed, not a barcode analysis framework with multi-format support and a full decoder API.

The live display support is a separate concern from detection. The library provides drop-in live display for SwiftUI, for NSView on macOS and for UIView on iOS and tvOS, so a code can be shown in a running view rather than only exported as a file. The Demo/ directory reflects that split, with separate demos for a QRCodeView, a ShareLink, a CocoaPods test, SwiftUI demos and a Watch app, which lines up with the library's claim to cover watchOS as well.

Generating a code is a document object with several output formats

The API starts with a document type. In Swift you construct a QRCode.Document from a UTF-8 string, and that object then produces whichever representation you need:

let doc = try QRCode.Document(utf8String: "This is the content")

// Create a CGImage 
let cgImage = try doc.cgImage(dimension: 400)
// Create a PNG image
let pngData = try doc.pngData(dimension: 400)
// Create a PDF (scalable content!)
let pdfData = try doc.pdfData(dimension: 400)
// Create an SVG (scalable content!)
let svgData = try doc.svgData(dimension: 400)
// Create a CGPath
let path = try doc.path(dimension: 400)

Every call takes a dimension, and every call is throwing, so failures are handled rather than swallowed. The distinction the code makes is the one that matters for real use: pngData gives you a fixed-size raster, while pdfData and svgData are described as scalable, and path gives you a CGPath you can fill yourself. The Objective-C path mirrors it through an initialiser that takes the content string, an error correction level, an engine and an error pointer.

The fact that the same document produces all of these means the encoded payload is fixed once and the presentation is chosen later. That is what makes it practical to build a design screen where the user picks a gradient or a logo and the underlying code never changes, since the error correction level and payload stay as they were while the rendering varies.

Adding the package, and the linker flag that will crash you without it

Swift Package Manager is the documented route, and the dependency is declared in Package.swift:

.package(url: "https://github.com/dagronf/qrcode.git", from: "20.0.0")

The badge row in the project header gives the deployment targets the library supports: macOS 10.13 and later, iOS 11 and later, tvOS 13 and later, watchOS 6 and later, and macCatalyst 1.0 and later. The Swift version badge reads 5.4, with Objective-C 2.0 and SwiftUI 2.0 and later also listed, so the library spans the whole range of Apple toolchains rather than requiring the newest one.

The one thing to get right is the linker. The documentation is emphatic about it: because QRCode supports Objective-C at its core, using it in Xcode automatically handles this, but if you are not linked against the Objective-C library you will receive crashes during runtime. The requirement is that the OTHER_LDFLAGS build setting contains -ObjC.

For projects that generate their Xcode configuration from a manifest, the documentation gives the shape of the setting using Tuist as the example:

settings: Settings(
   base: [
      "OTHER_LDFLAGS": "-ObjC"
   ],
   ...
)

This is the kind of detail that costs an afternoon if you hit it blind, and the project puts it in the documentation for exactly that reason. The CocoaPods route exists too, with a pod-compatible badge and a dedicated CocoaPods test under Demo/.

A repository with a docs site, an SPI manifest and no releases

The repository layout is that of a project with substantial documentation rather than a bare library. At the top level there is a Documentation/ directory, an Art/ directory holding images used in the README, an Examples/ directory, a Demo/ directory, Sources/, Tests/, scripts/, a Package.swift manifest and a.spi.yml file.

The.spi.yml is worth noting for a specific reason. SPI is the Swift Package Index, a registry for Swift packages, and the manifest is what makes a package discoverable there. Combined with the SPM and CocoaPods badges and the top-level Package.swift, the distribution story is the conventional one for an Apple-platform library, and it means you can add the dependency either by URL or by package name depending on your setup.

There are no GitHub releases. The version you get is the one you pin in Package.swift, and the example pins from 20.0.0, meaning the dependency floor is a 20.x release. There is no changelog in the top-level listing to track what changed between versions, and the last push to the repository was on 2026-06-16, so the working tree is the only place where recent work is visible.

The MIT licence file sits at the root. For a library that you will link into an app, MIT is a permissive choice, with the light obligation of keeping the copyright notice in distributions, and the licence text is in the repository if you need the exact terms.

Where QRCode is the wrong dependency

The first limitation is symbology coverage. If the product requirement is a scanner that must read EAN barcodes on retail packaging, a Code 128 label on a shipment, or an Aztec code, this library does not help. The detection side is scoped as basic QR code video detection, and there is no mention of a multi-format decoding API anywhere in the documentation. A team that has to accept arbitrary barcodes needs a different library, or the CoreImage detector that ships with the platform.

The second is platform reach. Every listed deployment target is an Apple platform, and the toolchain is Xcode, Swift Package Manager or CocoaPods. There is no Linux or Windows build path and no server-side rendering story, so a backend that needs to produce a QR code as part of a document pipeline cannot use this.

The third is the camera permission coupling, which the project handles well but cannot remove. Even though the detection code is a separate product, pulling it in means your app bundle needs an NSCameraUsageDescription and an AVFoundation dependency, and the library will not decide that for you. If your app is already camera-free and you add a scan feature, you have changed your privacy surface and your App Store review story. The separation means the choice is yours to make, but the cost is not zero.

The fourth is versioning discipline. With no published releases and no changelog, pinning from 20.0.0 as the example does means you take whatever 20.x the resolver picks, and you have no release notes to read when something changes. That is manageable, and it is the price of a project that ships source rather than artefacts.

Editorial conclusion

QRCode fits an Apple-platform app that wants a QR code rendered as a vector, tinted with a gradient, branded with a logo, or displayed live inside a SwiftUI view, and the fact that the core is Objective-C means it drops into mixed codebases without a rewrite. It is the wrong choice for a project that needs QR plus other barcode formats, for a server-side or cross-platform pipeline, or for a team that cannot accept a separate camera usage description and AVFoundation dependency in its app bundle. Before adopting it, add the SPM dependency at version 20.0.0, check that the Objective-C library is linked and that OTHER_LDFLAGS contains -ObjC, and confirm the macOS 10.13 and iOS 11 deployment targets match your project, since the last push to the repository was on 2026-06-16 and there are no published releases to version against.

Frequently asked questions

Official sources

1. dagronf/QRCode on GitHub
2. Issues
3. License: MIT
4. README