EFQRCode: Stylized QR Code Generation and Recognition in Pure Swift

What EFQRCode Solves for Apple Platform Developers

Most QR code libraries treat the code as a data payload with a fixed visual form. EFQRCode takes the opposite position: the code is an image asset that happens to be scannable. The README describes it as a "lightweight, pure-Swift library for generating stylized QRCode images with watermark or icon, and for recognizing QRCode from images." That framing explains the API shape. Generation accepts a style parameter, and that style can carry a static image, an animated image sequence, or a transparent background. The library targets iOS, macOS, watchOS, tvOS and visionOS, and it is built on CoreGraphics, CoreImage and ImageIO rather than on a bundled C library. For an app that already renders everything through Apple's graphics frameworks, that matters: there is no separate binary to audit and no bridging layer to keep in sync. The audience is Swift developers building consumer-facing apps where a QR code appears inside a designed screen, not in a terminal or a print pipeline.

How the Generator and Recognizer Are Structured

The public surface is split into two types. EFQRCode.Generator takes a string payload and a style, and exposes conversion methods such as toImage(width:) and toGIFData(width:). EFQRCode.Recognizer takes a CGImage and returns an array of strings, because a single image can contain more than one code. The README's recognition example makes this explicit: it prints the count and then iterates with enumerated() over the results. The generator's style parameter is where the visual work happens. The README shows a style of .image with nested params, and inside that an image of .static or .animated. Animated input carries both the frames and their delays, which is what allows the output to be a GIF. Exportable types are listed by category: static output covers NSImage, UIImage, PDF, PNG and JPEG; animated output covers APNG, GIF, SVG, MOV, MP4 and M4V. That is a wider export set than most Swift QR libraries offer, and it is the main reason the animated path exists at all. Note what the README does not describe: error correction levels, encoding modes, mask selection, or quiet zone control. Those knobs are either absent from the documented API or left to the DeepWiki link.

Installing EFQRCode with CocoaPods, Carthage or Swift Package Manager

All three package managers are supported, and the README gives a version constraint of 7.0.3 for each. With CocoaPods, add the pod to your Podfile and run the install command. The README shows the constraint with the optimistic operator, so you will receive patch and minor updates within the 7.x line.

pod 'EFQRCode', '~> 7.0.3'

$ pod install

With Carthage, the README instructs you to install the tool through Homebrew, add a line to your Cartfile, run the update command, and then drag the built framework into your Xcode project.

$ brew update
$ brew install carthage

github "EFPrefix/EFQRCode" ~> 7.0.3

With Swift Package Manager, add the package to the dependencies array of your Package.swift. The README uses upToNextMinor rather than upToNextMajor, which is a stricter constraint than the CocoaPods line and worth noticing if you expect minor-version updates to arrive automatically.

dependencies: [
    .package(url: "https://github.com/EFPrefix/EFQRCode.git", .upToNextMinor(from: "7.0.3"))
]

A First Real Use: Generate a QR Code with an Overlaid Image

After importing the module, the shortest path to a styled code is to construct a generator with an image style and convert it to a bitmap. The README's static example passes a payload string and a style whose image is a static CGImage with allowTransparent set to true, then calls toImage(width:) at 180 points and reads the resulting cgImage.

import EFQRCode

let generator = try? EFQRCode.Generator("https://github.com/EFPrefix/EFQRCode", style: .image(
    params: .init(image: .init(image: .static(image: UIImage(named: "WWF")?.cgImage!), allowTransparent: true)))
)
if let image = try? generator?.toImage(width: 180).cgImage {
    print("Create QRCode image success \(image)")
} else {
    print("Create QRCode image failed!")
}

Both the initializer and toImage are throwing calls, and the README wraps them in try?. That is a design choice with a cost: a failed generation and a nil generator collapse into the same else branch, so you cannot tell a bad payload from a rendering failure without catching the error explicitly. For recognition, the flow is the reverse. You supply a CGImage and receive a string array.

if let testImage = UIImage(named: "test.png")?.cgImage {
    let codes = EFQRCode.Recognizer(image: testImage).recognize()
    print("There are \(codes.count) codes")
}

The README notes that the array exists because one image may contain several codes. If you need to run this against a live camera feed rather than a stored image, the README does not cover that path; you would be converting frames to CGImage yourself.

Where EFQRCode Is the Wrong Choice

The library is Apple-only. If your QR code is produced by a backend service, a web front end, or a Flutter or React Native layer, EFQRCode cannot help you, and the CoreGraphics dependency means it never will. The README's own inspiration list points at a Python project and a JavaScript project, which is an implicit acknowledgement that the same visual ideas exist outside Swift. A second limitation is documentation depth. The README covers installation, a static generation example, an animated generation example, and an export format list. It does not document error correction levels, the maximum payload size, how the style interacts with scannability, or what happens when the overlay covers too much of the code. For a library whose entire premise is visual modification of a machine-readable symbol, the absence of guidance on the scannability trade-off is the gap a reviewer should flag first. A third case: if you need to decode from a live video stream with frame-level control, the Recognizer's image-in, strings-out interface gives you no hook for that, and the README offers no streaming example.

EFQRCode Against Apple's Own CoreImage Filters

The obvious alternative inside the same ecosystem is CoreImage's CIQRCodeGenerator and CIDetector, which ship with the platform and require no dependency at all. The difference in approach is that the CoreImage filters give you a raw matrix of black and white modules and nothing else. Any watermark, icon, rounded module, or gradient is work you write yourself. EFQRCode wraps that same underlying graphics stack and adds the styling layer plus the multi-code recognition convenience. The trade is dependency surface against code you would otherwise maintain. If your requirement is a plain black-and-white code at a fixed size, the built-in filters are sufficient and EFQRCode adds nothing but a version constraint. If your requirement is the animated GIF output or the icon overlay shown in the README examples, the built-in filters leave you writing a compositing pipeline, and EFQRCode is the shorter path. Outside Apple platforms, the README's own credits point to sylnsfar/qrcode in Python and CPunisher/react-qrbtf in JavaScript, both of which target the same stylized-output idea for different runtimes.

Maintenance, Licence and Upgrade Cost

The repository is not archived, and the last push was on 2026-03-03. The most recent release listed is 7.0.3 from 2025-08-02, with 6.2.2 released the same day and 6.2.1 dating to 2023-03-06. That release pattern suggests the 6.x line was closed out alongside the 7.x line rather than being abandoned mid-stream. The README's installation snippets all pin to 7.0.3, and the repository carries a CHANGELOG.md at the top level, so version-to-version changes are traceable without reading commit history. The licence is MIT, which permits use in closed-source applications and requires only that the copyright notice and permission notice be preserved; this is a description of the licence text, not legal advice, and you should read LICENSE in the repository if your organisation has specific requirements. The upgrade cost is concentrated in two places. First, the Swift Package Manager constraint in the README uses upToNextMinor, so moving between minor versions is a deliberate edit to Package.swift rather than an automatic resolution. Second, the package manifests are versioned: the repository ships Package.swift alongside [email protected] and [email protected], which means older toolchains resolve a different manifest. Check which one your toolchain selects before assuming the README's dependency line applies unchanged.

Editorial conclusion

Adopt EFQRCode if you are shipping a Swift app on Apple platforms and need stylized generation or in-image recognition without leaving the platform's own graphics stack. Skip it if you need a cross-platform QR stack, a server-side generator, or documented control over error correction and encoding internals. Before committing, verify that the version you resolve through CocoaPods, Carthage or Swift Package Manager matches the module and API shape of the 7.0.3 examples, and check that your deployment targets meet the stated minimums: iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0 and visionOS 1.0.

Frequently asked questions

Official sources

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